ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] The (really) latest SSP draft

2007-10-19 16:22:51

On Oct 19, 2007, at 2:27 PM, Jim Fenton wrote:

Douglas Otis wrote:

On Oct 19, 2007, at 8:46 AM, Jim Fenton wrote:

4871 indeed uses a broad notion of "responsibility". However, in the case where the signing address is the same* as some other header field, such as 2822.From, I don't see how a signer can be responsible for a message that uses its own address without an implied claim that the address is correct.

* "same" meaning that the i= address is either the identical, or that the i= address has the same domain if i= has no specified local part.

It would be a bit more accurate to use the term "signing domain", rather than "signing address". An address (the i= parameter) is optional, after all.

The parameter is optional, but if absent, the signing address (what i= represents) takes the default value of the d= parameter (preceded by an @). There is always a signing address. I get tired of typing "i= (or d= in its absence)" every time I talk about i=, since this is in the specification, but every time I don't spell this out very explicitly I need to write a clarifying message.

When an i= parameter defaults, only the signing domain is specified. Here the term "signing domain" always applies without explanation. In addition, there is no such thing as a "signing address". This implies a process that does not exist.

Someone might consider an email-address within a message's header matching an i= parameter (default or otherwise) as having been verified based upon this term "signing-address" rather than "signing- domain". This is _not_ how the base specification has been written, nor is this in agreement with even an Informational Discussion describing use of the i= parameter.

Quote from the base specification Informative Discussion:

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.

The optional i= parameter represents the identity of the user or agent (e.g., a mailing list manager) on who's behalf the message was signed. The base specification makes no statement that this optional parameter SHOULD NOT be applied when the user or agent identity has not been validated. (See the informative note about whether the i= parameter can be trusted.) Without a stipulation that the i= parameter MUST BE validated, and exactly which validation mechanisms must be used within the base specification, it would be a significant change to assume inclusion of the i= parameter thereby confers responsibility to validate identities onto signing domains. There are also cases where the i= parameter can not be applied, such as when the signing domain is within a sub-domain of the identity, or when the identity is within another domain. Would you envision the blocking of messages which did not include the i= parameter containing the local-part?

The validation of the local-part of i= is that it must (wildcard) match the value of g=, if present, in the key record. An agent in possession of a private key that does not constrain the local part (no g= in the key record, or g=*) is one that is trusted by the domain to take responsibility for any message on behalf of any address in the domain. So the i= parameter is already validated.

The domain is responsible for messages it sends, with or without a DKIM signature. Adding a DKIM signature allows messages retransmitted on their behalf to be identified as having been sent by that domain. A DKIM signature makes no strong statement regarding whether email-addresses within a message will have been validated in some undefined fashion. You appear to be claiming otherwise. This seems to be rather dangerous and wishful thinking. Don't oversell what DKIM provides.

The cases you cite: signing domain is within a subdomain of the identity, or when the identity is within another domain, are intentional. example.com should not be taking responsibility for messages on behalf of bigbank.com. If it has a legitimate reason to do this, it is delegated a key by bigbank.com and signs as that domain.

I would not envision (and can think of absolutely no reason to) blocking messages without an i= parameter specifying a local-part. The ability to specify i= without a local-part was done for a reason.

Including a local-part within an optional parameter does not have a clear, well defined requirement. Any reasons or requirements for include the i= parameter has been specified with "mights" and "mays". Hence the i= parameter SHOULD NOT be relied upon. It is also wholly improper to declare the i= parameter as the signing entity. The signing entity is the d= domain. Refer to the signing entity as the signing domain.

-Doug






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