ietf-dkim
[Top] [All Lists]

[ietf-dkim] summarizing my understanding of the errata discussion & a proposal

2009-02-04 02:04:39
Tony, Dave, and John,

Thanks for your patient explanations. Particularly you, Dave. You did quite a number of rounds with me in private. To summarize what I understand (or misunderstand), the fundamental issue with this erratum is that the text surrounding i= in RFC 4741 does not sufficiently warn people as to the limits of its use. Dave's message on January 9th probably stated it best as follows:

The fact that there are serious, knowledgeable folk who declare it is the d= tag and other, equally serious and knowledgeable folk who declare that it is the i= tag, and that there are substantial numbers of each means that we have a real
and basic problem:

           The community does not currently have consensus about
           where to find the one value that is DKIM's output!

The concern seems to arise out of insufficient sternness in the informational note for i=:
       INFORMATIVE DISCUSSION: This document does not require the value
           of the "i=" tag to match the identity in any message header
           fields.  This is considered to be a verifier policy issue.
           Constraints between the value of the "i=" tag and other
           identities in other header fields seek to apply basic
           authentication into the semantics of trust associated with a
           role such as content author.  Trust is a broad and complex
           topic and trust mechanisms are subject to highly creative
           attacks.  The real-world efficacy of any but the most basic
           bindings between the "i=" value and other identities is not
           well established, nor is its vulnerability to subversion by
           an attacker.  Hence reliance on the use of these options
           should be strictly limited.  In particular, it is not at all
           clear to what extent a typical end-user recipient can rely on
           any assurances that might be made by successful use of the
           "i=" options.

Here, the consumer of this information, the verifier, is warned against making use of i=. However, what we are now saying is that practical deployment experience requires a stronger warning; that absent additional information from the signer that is not exposed by this specification, verifiers SHOULD NOT rely on i= as any sort of identity, because the value may not be present or stable.

My two questions:

  1. Why not just say that in the erratum?  It has the advantage of
     being very concise, requiring no additional terminology, and even
     better, no additional FLAs.  It also clearly meets the parameters
     for an erratum.
  2. Is the above statement actually true?  Do we have practical
     experience that shows that i= is either unstable or unused?  Can
     someone talk to that point?

One remaining point of discussion:

While the confusion arises between d= and i=, what verifiers do with a valid signed message is still up to them. They could take input from various header fields if they wish (and some assuredly do and will).

Comments?

Regards,

Eliot
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html