Earl Hood wrote:
On August 18, 2005 at 09:57, Douglas Otis wrote:
1- Employs DKIM
2- Employs DKIM universally
3- Allows TP signing
4- Allows sub-domain TP signing
5- Disallows all TP signing
6- Never sends email
It would seem counter productive to for assertion 5 to be the default
taken as this would greatly discourage larger ISP from universally
signing all outbound mail.
Why sign messages when there will be no value in doing so?
The OA is important here, and automatically signing messages without
explicit permission from the OA is not playing nice.
They might be "not playing nice" or they might just be naive. Maybe
they weren't able to get an answer from the OA domain and wanted to
forward the message anyway rather than queue it -- actually, sending
lots of mail from an OA domain with non-responsive SSP servers might be
an interesting attack.
The question is whether out-of-policy signatures (e.g., disallowed
third-party signatures) are considered indicative of an attack or just
irrelevant. The same for broken (invalid) signatures. Hopefully we
wouldn't have a situation where a message with a broken out-of-policy
signature is considered "better" than a message with an out-of-policy
signature that is intact!
My preference is just to ignore broken and out-of-policy signatures as
if they weren't there at all.
Except, if DKIM signatures were not limited to OA SSP binding, then an
ISP could blindly sign messages, making the assertion, "this what I
got before I sent it out."
Now large ISPs (like Y!) control the domain of their users (the bulk
of their users are under yahoo.com), so defining the proper SSP records
(for 1st-party signing) is not more difficult than defining the signer
public key entries.
For ISPs servicing multiple domains, they should only sign if the
domain owner allows it, creating a 1st-party signing relationship
versus a TP one. Note, domain owner does not necessarily equal
domain administrator.
(Note, any first-party relationship will probably need to have
a legal basis.)
IMO, from the OA perspective, enabling TP signing is bad policy from
a security perspective. OA will not care if other entities sign a
message (for traceability purposes) as long as they are not claiming
a 1st-party association.
I'm confused about this paragraph: "enabling TP signing is bad policy"
but "OA will not care if other entities sign...not claiming a 1st-party
association". A third-party signature doesn't claim a first-party
association, or at least that's my interpretation. The intent of
restricting third-party signatures is to prevent messages signed by
mailing lists and the like (and particularly by attackers posing as
such) from being considered verified if there isn't also a valid OA
signature.
Side Note, I think it would be useful if the OA SSP allowed for
an OA to designate a list of allowable signers.
I'm very concerned about the scalability of the allowable signers list.
There are circumstances where it would be very long. The OA domain
could delegate its _domainkey subdomain, or a subdomain of that, to an
allowed signer; since these signers are probably people "in the email
business" (outsourced email services) anyway, they should be able to
deal with that.
For those where this would matter, then
making the assertion should be required.
You are assuming that a domain owner is aware of DKIM. When DKIM is
deployed, you cannot require all domain owners to set up SSP records
immediately.
I'm confused about who's saying what, apparently. I thought you (Earl)
were advocating a default SSP of "I don't sign anything" which would
require the SSP to be set up at the same time as the selectors.
Exactly. Are you suggesting that the default should be:
(1) Treat any signature from the OA (example.org) with suspicion, or
(2) Treat any signature on a message from the OA with suspicion ?
If it's (2), it means that domains that haven't deployed DKIM that
send through mailing lists to domains that are checking SSP would
have those messages marked as suspicious.
Here the trade-off is rather clear. The restrictions on TP
signatures is related to combating phishing exploits which affect
only a minority of domains. The majority of domains should be
willing to allow their messages to be "spoofed" (third-party
signatures) out of sheer convenience.
There is no "willing" for domains that do not know of DKIM or have
yet to adopt it. DKIM must not facilitate spoofing.
Another view would be for the mailing-list to leave all signed
messages intact. There would then be no added overhead groping for
SSPs. The mailing-list may adopt a convention where new headers
replace the technique of message modification.
The List-* headers are well-defined, but many MUAs probably do
not display them (by default).
Right. If you look at this message, there will be List-Post:,
List-Archive:, List-Help, etc. headers but it still applies a trailer to
the body because it will be seen.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org