Subject: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Feb 2009 20:42:26 +0100

Dear all,

As I had mentioned in a previous email[*], my understanding of the 
concerns raised by Dave and others is that there is insufficient clarity 
(I originally used the word sternness) in the warnings about the use of 
i=, with respect to its stability and presence.  My greatest concern 
with Dave's draft is we would be using a hammer where a fly swatter is 
needed.  Definition of additional terms, while perhaps providing more 
precision, does not necessarily make for ease of reading.  People know 
what they know, and they generally do NOT like to have to learn new 
terminology in order to get the job done.  Getting right down to the 
point in as few a sentences (and terms) as possible makes the reader's 
life easier, even if the language is somewhat less precise.  The gold 
standard, of course, is whether the corrective text will sufficiently 
avert interoperability problems.

All of this having been stated, here are the precise ;-) changes I 
propose to RFC 4871, by way of errata:

On Page 20, Section Section 3.5, definition of i=,

OLD:

    i=  Identity of the user or agent (e.g., a mailing list manager) on
        behalf of which this message is signed (dkim-quoted-printable;
        OPTIONAL, default is an empty Local-part followed by an "@"
        followed by the domain from the "d=" tag).  The syntax is a
        standard email address where the Local-part MAY be omitted.  The
        domain part of the address MUST be the same as or a subdomain of
        the value of the "d=" tag.

NEW:

    i=  Identity of the user or agent (e.g., a mailing list manager) on
        behalf of which this message is signed (dkim-quoted-printable;
        OPTIONAL, default is an empty Local-part followed by an "@"
        followed by the domain from the "d=" tag).  The syntax is a
        standard email address where the Local-part MAY be omitted.  The
        domain part of the address MUST be the same as or a subdomain of
        the value of the "d=" tag.  Absent additional external
        information outside of the context of g=, verifiers MUST treat
        the Local-part contents as opaque strings.

OLD:

        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.

NEW (additional text at the bottom):

        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.  Implementations should not rely on the
            presence of this value or its stability.

I hope this clearly states concerns mentioned within this group in the 
fewest additional words.  This having been said, this is a proposal, and 
I would welcome improvements.

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Feb 2009 12:22:13 -0800

On Feb 10, 2009, at 11:42 AM, Eliot Lear wrote:

While cleaner than the errata Dave Crocker is proposing, this still  
changes the definition of the i= parameter intended to represent the  
identity on whose behalf the signature was added.  It is not  
reasonable to assume the i= represents a colliding namespace where the  
i= value must be considered undefined.  This type of definition  
permits the deceptive use of the i= value and is no benefit.

Perhaps rather than:

> Absent additional external information outside of the context of g=,  
> verifiers MUST treat the Local-part contents as opaque strings.

Change to:

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.  Otherwise, the content of the  
i= value may represent a token for on whose behalf the message was  
signed, where any subdomains below the d= domain as well as the local- 
part may not reference valid email-addresses for the domain.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 10 Feb 2009 20:23:54 -0800

I agree with Eliot's overall approach of clarifying the use of i= in
this way, but have some suggestions on the text, inline:

> On Page 20, Section Section 3.5, definition of i=,

It looks like you have added a sentence here.  Were there other changes
I missed?

Added:
>         Absent additional external

My suggestion (in place of the added sentence):

In the absence of external assertions to the contrary, verifiers MUST
not assume that the i= value corresponds to an email address; both the
Local-part of the value and any "subdomain" of the d= value that appears
are significant only to the signer.

>             presence of this value or its stability.

The second through fifth sentences of this paragraph (from "Constraints"
through "strictly limited") seem to be making a point about trust.  It's
fairly simple:  like everything else in the DKIM-Signature header field,
i= is an assertion by the signing domain; if you trust the signing
domain, you can decide to believe the i= assertion.  But the whole point
that the verifier MUST NOT depend on the i= value in the absence of
other information makes this moot.

So I would rewrite the (entire) paragraph as follows:

INFORMATIVE DISCUSSION:  This document does not require the value of the
"i=" tag to match an identity in any message header fields.  Although
its syntax might suggest otherwise, the "i=" value need not be in the
same name space as an email address.  External assertions made outside
the scope of this specification may in certain cases signify that the i=
value does in fact correspond to an email address or subdomain.  In many
cases, the i= tag will not be present in the DKIM-Signature header field
at all; it is not required unless the signing key restricts the signing
identity or identities via its g= value.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Feb 2009 10:35:43 -0800

On Feb 10, 2009, at 8:23 PM, Jim Fenton wrote:

> Added:
>>        Absent additional external information outside of the  
>> context of g=, verifiers MUST treat the Local-part contents as  
>> opaque strings.
>
> In the absence of external assertions to the contrary, verifiers  
> MUST not assume that the i= value corresponds to an email address;  
> both the Local-part of the value and any "subdomain" of the d= value  
> that appears are significant only to the signer.

While caution is commendable, going to this extreme is detrimental.   
Use of the i= parameter to affirm email-addresses of the domain in  
signed header fields will now require an undefined semaphore.  ADSP  
does not represent a good solution since ADSP is not suitable for  
many, if not most, domains and only corresponds with the From header.   
The fix for ADSP for conflicts is to include a signature without an i=  
value.  In essence, calling the i= value opaque without other  
assertions permits what should be viewed as an extremely poor  
practice.  When someone is using a token for the i= value that  
collides with their real email-address space within the same message,  
they are in a small, perhaps nonexistent, minority.

Such use would be fairly deceptive after all.  Since such use is  
deceptive, rather than warning against i= values without finding some  
new and undefined semaphore, it would be safer and less disruptive to  
warn against the colliding of token and real namespace within the same  
message.  Both of these spaces are under the control of the domain and  
are easily isolated since tokens are not constrained to just nine  
digits.  Why burden DKIM with yet another mechanism without an  
apparent necessity, and where future problems are better resolved by  
SHOULD NOT allow token namespace to collide with real email-addresses  
within the same message.

Would it really be preferable to have an o= tag with a value "real" or  
"token" included within the DKIM signature? Or is a new header REALLY:  
i=<>  needed?

Where do you see a solution being found?  What would be the  
repercussions of just saying within an Errata or some deployment  
document:

	The DKIM signature SHOULD NOT allow any i= value token namespace to  
collide with real email-addresses within the same message?

-Doug