I'll stick t o inline comments at the risk of this getting confusing. > -----Original Message----- > From: Jim Fenton [mailto:[email protected]] > Sent: Tuesday, January 06, 2009 8:20 PM > To: MH Michael Hammer (5304) > Cc: John L; [email protected] > Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp > > Hi, Mike...comments inline: > > MH Michael Hammer (5304) wrote: > > > >> -----Original Message----- > >> From: Jim Fenton [mailto:[email protected]] > >> Sent: Tuesday, January 06, 2009 6:10 PM > >> To: MH Michael Hammer (5304) > >> Cc: John L; [email protected] > >> Subject: Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp > >> > >> It really applies to the implementation of the checker, and not to the > >> publication of ADSP records. > >> > >> At the risk of repeating myself, here's an example of when it's > >> important. Suppose the ietf.org mailing list manager signs its mail > >> using [email protected]. The IETF Chair sends a message to the list, > >> using From: <[email protected]>. I contend it would be bad for the > >> > > mailing > > > >> list manager signature to be confused with an author signature. > >> > >> > > > > But in terms of the receiving domain checking, why would they make a > > distinction from an ADSP perspective? The question at hand is whether > > all email from a particular (sub) domain is signed. If a domain is > > making this type of assertion, then it is looking at ietf.org and > > shouldn't really care whether the user is chair@ or i...@. If you are > > asserting that one might be signed and the other not then I think there > > is an issue. If you assert that both are signed but the signatures might > > be different (within the same domain but with different selectors for > > example then I'm going to say fine because if ietf.org asserts it signs > > all mail then it still works. It is the domain that is important, not > > the user part for the all assertion. > > > > Suppose that ietf.org asserts an ADSP record but doesn't require > signatures on incoming messages, even from its own domain (there's no > requirement that they do). Someone spoofs a message from > [email protected], which is of course unsigned. The message coming out of > the list looks like it has an author signature. I have a problem with > that. >
If ietf.org is willing to put it's signature on the spoof message I would assert that it has a DKIM problem more than an ADSP problem. Either the message has a valid signature or it does not. If there is a valid signature then ietf.org is claiming responsibility. If it doesn't have a valid signature....then not so much. If ietf.org is sending out spoofed messages spoofing a "from" then it has a problem regardless of whether it DKIM signs, uses ADSP or does anything else.. > In this situation, we could require that the mailing list manager not > apply a signature if it might be confused with an author signature, but > then there's no way for it to apply a signature representing the list. > > Then perhaps ietf.org should reconsider whether or how it DKIM signs, whether it is a suitable candidate for ADSP and how it manages it's lists. By DKIM signing ietf.org is claiming responsibility for the mail - good bad or indifferent. If it fixes the problem quickly and otherwise it has a good reputation then it maintains it's reputation. If it consistently signs problem mail then it may lose it's reputation. > >> This example involves the use of local-parts, but one could also come > >> > > up > > > >> with (somewhat more contrived) examples where the mailing list manager > >> is at lists.example.com and some users are at users.example.com. If > >> > > the > > > >> keys are published in the example.com domain (d=example.com) and i= > >> isn't being used, it isn't possible to distinguish author signatures > >> > > and > > > >> list signatures. > >> > >> > > > > Distinguish to what purpose Jim? > > > > Either they are signed or they aren't signed from an ADSP perspective. > > If distinguishing at this granularity is important then publish ADSP for > > lists.example.com/DKIM sign for that domain (d=) and publish ADSP for > > users.example.com/DKIM sign for that domain (d=). The author signatures > > are clearly distinguished from the list signatures. > > But they are all domain signatures. If you go back and look at the discussion that took place before I suggested the name Author Domain Signing Policy, I pointed out that authors don't sign, domains do (unless an author also has control of DNS for a domain). > > The d=/i= distinction was originally created to simplify key management > by domains having many subdomains, in that they could publish the keys > in a parent domain (d=) while signing for a subdomain (i=). You're > basically suggesting that we abandon that optimization so that we can > use the d= domain rather than the i= domain for ADSP. I'm too tired to wade back through the list to find the discussion that included statements from receivers that for the most part the finer granularity desired by some senders was not necessarily useful from the receiver perspective. I'm not going to argue with receivers. I sign email with DKIM because it helps them identify legitimate mail from our domains vs the spoofed mail. For my use case I try to keep it as simple as possible. Other than hypotheticals I haven't heard any implementers on the sending side indicating this is an issue. I can only speak from my experience which is 5 domains with roughly 750 million signed emails in the past year. > Remember that the lookup address for ADSP is always the domain of the > From address (users.example.com) and not the d=domain. In this > situation ADSP records for lists.example.com and for example.com would > never be referenced. > d=users.example.com d=lists.example.com You look at the lack of optimization. I look at where you are going and wonder why someone with lots of subdomains is going to turn to ADSP in the first place. I sign for sub.sub.sub.domain.com but I don't sign for sub.sub.domain.com but I sign for sub.domain.com but I don't want to publish ADSP for this. I sign and I want to publish ADSP discardable for sub.sub.sub.domain.com. I think I know where and how I send email but I'm not really sure. Right. This is not an organization that is a suitable candidate for publishing ADSP. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
