Serves me right for having this thing on "digest" mode all this time, and missing all the fun. Apologies, therefore, if my reply/replies here break threaded viewers, and certainly covers a few points that have probably been resolved, but I'd like to put my opinion out there for-the-record even if it's late.
First, some specific replies: On Mon Jan 26 04:22:17 PST 2009, Tony Hansen said: > I strongly support working on a 4871bis >>and<< moving DKIMbase forward > to Draft Standard as part of that. +1, although it looks like we've got rough consensus already on that particular point anyway. On Mon Jan 26 13:24:45 PST 2009, J.D. Falk said: > Also, +1 to Suresh's suggestion of a use cases document. Wouldn't this be appropriate for the deployment document? On Mon Jan 26 09:06:08 PST 2009, SM said: > In my opinion, the draft is more than an erratum. I'm still fence-sitting on my opinion about this, having read the entire thread to date. As an implementor I've always been interested in making available a vector of information about the signature, not just the value of "d=" or "i=" since there are lots of possible local policy decisions. The API we produced also allows the caller to obtain things like the value of "s=", "l=", canonicalizations used and other relevant parameters. Thus, changing from having a single identifier to many doesn't phase me much. I'm also not swayed in terms of working group procedure to either side. On one hand, I believe an erratum should only be things like correction to ABNF or typographical errors, so the addition of this much text seems to exceed such boundaries. On the other, the proposed changes merely formalize some concepts and attempt to provide clarity to the output question, rather than introducing anything that's truly new. I suspect most working groups that feel such correction is needed just go directly to the "bis" concept. But that's probably just weak precedent, not required procedure. Forced to choose, I guess I would agree that this fits as an erratum, but not comfortably; I certainly agree that it's pushing some probably-unwritten boundaries. Perhaps the IESG might do well to consider if this is really an issue and, if so, propose amended guidelines. On Mon Jan 26 18:58:39 PST 2009, Tony Hansen said: > I don't think this idea meets the criteria that the i= value represents > the > > Identity of the user or agent (e.g., a mailing list manager) on > behalf of which this message is signed ... > > My reading of this is that you can have a 1-to-1 mapping between the i= > value and the user/agent's identity, and you can have an N-to-1 mapping, > but you can't have a 1-to-N mapping. "good", "bad" and "suspect" do not > represent the identity. +1. If there's some data the signer wishes to express about the message that's not an identity, it's a candidate for a new (as-yet-unpublished) DKIM tag. This is safe; a verifier that knows about the unpublished tag can make use of it, and those that don't are required by RFC4871 to ignore it. If the idea becomes popular, it's a candidate for inclusion in some "bis" draft. I don't really like the later-proposed idea of overloading, using "[email protected]", i.e. encoding the annotation as a (likely fake) subdomain of the signing domain. We made the thing extensible, so let's extend it if there are good reasons to do so. Jim Fenton also made remarks in support of this idea. On Tue Jan 27 13:21:51 PST 2009, Jon Callas said: > It's trivial to make a new header for the stable identifier and have > that be in the list of headers signed. Although many will squawk about yet-another-bloody-identity-header, and it would require some pretty thorough definition work, I'd support this. On Tue Feb 10 12:22:13 PST 2009, Doug Otis wrote: > When the i= value exactly matches an email-addresses contained within > signed header fields, it is reasonable to assume this value is > representative of this email-address. -1. I believe that has to be communicated explicitly out-of-band by the signer, and implementors of basic DKIM should not be encouraged to make such conclusions based on heuristics. On Wed Jan 28 12:06:56 PST 2009, J.D. Falk wrote: > That kind of signing would prevent using i= for social networking, > because even if Grandma pays for the account (and thus the user_id > roughly identifies her), drunken Uncle Ernie lives in the basement and > sponges off her AOL subscription, and they'd both have the same i= > value. Dude, I really need to party with your family. I've learned so much about them from ietf-dkim. ===== Now, for some general comments: Overall, I agree with the need to clarify the d=/i= issue, although I have no operational experience which makes this urgent. I therefore agree with the content of the -02 erratum draft. I'm still looking over Eliot's proposal to see if it achieves the same goals in less text. I don't agree that use of "opaque" is confusing, although I am experienced with data structures and in that context its use is quite appropriate. Someone else might not be. If we are to presume the draft is mainly geared toward implementors (and I think that's reasonable), I don't think it needs to be changed. We could bounce the text off a few uninvolved coders (or non-coder messaging geeks) to see if it makes their eyes cross or not. But to cite Jim's specific example, "opaque" means "unintelligible", which is appropriate in this context; the verifier isn't supposed to be able to make sense of the local-part-bit of an "i=" value. Whenever we come up with a way "i=u...@domain" might be useful to certain signers or applications as an argument in favour of supporting such, we must also consider how the spec, when modified to lend that support, can be abused. As with most other mail security work to date, there's very little a legitimate signer can do which a spammer or phisher can't do (or won't try). I'm not sure this concept got due consideration earlier in these discussions. I would support the addition of a new key or signature tag which is an indication by the signer to the verifier that the local-part-looking-bit is stable, thus asserting that it is safe to use for identifier-specific (e.g. user-specific) reputation assessments. One could also add such a tag which indicates that the local-part-looking-bit is something authenticated with SMTP AUTH, or something that appears in the local user database, or similar. There's nothing beneficial here to an attacker; it (presumably) takes a while to build up a positive reputation but not long to go from zero to something negative, so they don't stand to gain in the short term much by making such assertions. I'd be happy to drive the WG editing of such a draft if there's rough consensus to do so. I agree that DKIM saying the local-part-looking-bit of "i=" is opaque, and then ADSP (which is an add-on, as someone pointed out) attempting to assert value about it, isn't a contradiction. A signer wishing to participate in ADSP is free to turn "i=" into a stable e-mail address so that it can match From: if that's what ADSP requires. In the same way, UDP defines a transport mechanism while DNS specifies the format of its payload. That said, I wouldn't be adverse to adding some kind of notation to a "bis" draft that later specifications based on DKIM might attempt to impose semantics, and implementors should make themselves aware of those. A few minor nits about the -02 draft: 1. Introduction - contains a reference to RFC5871, which should be RFC4871 - change "to clearly define" to "to define clearly" - change "and specifies and their relationship" to "and specifies their relationship" 9. RFC4871 Section 3.5 The DKIM-Signature Header Field - change "for an introduction of a message" to "for the introduction of this message" 10. RFC4871 Section 3.5 The DKIM-Signature Header Field - change "...to an individual user name within their domain" to "...to an individual user name within its domain" 12. RFC4871 Section 3.9 Relationship Between SDID and UAID - change "Hence reliance on... " to "Hence, reliance on..." -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
