[ietf-dkim] Moving on to ADSP - removing i= value dependence

[Douglas Otis]

On Mar 12, 2009, at 6:24 AM, MH Michael Hammer (5304) wrote:
> From: Douglas Otis, Mar 11, 2009 7:40 PM
>> On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote:
>>>
>>> If the DKIM-Signature header field does not contain the "i=" tag,  
>>> the verifier MUST behave as though the value of that tag were  
>>> "@d", where  "d" is the value from the "d=" tag.
>>
>> A signature lacking an i= value defaults to the d= value, but this  
>> does not represent a From email-address!   As someone said, domains  
>> do not write emails, which leaves the "on-behalf-of" identity  
>> *undefined*.
>
> Whether i= or d=, when I go to look for the ADSP record I'm only  
> looking at the RHS of the address. Therefore, what does it matter if  
> a signature lacking an i= defaults to d=? Logically, unless I have a  
> constraining g value and even then (note well): <key g definition  
> elided >

> Domains sign mail. Unless you can show that every user has access to  
> creating/modifying the keys in DNS. You have provided nothing that  
> shows there is an issue.

Is this agreement with removing dependence upon the i= value?

>>> There is nothing special about a DKIM signature missing an i=  
>>> filed. One simply uses the d= field. Seems pretty straight forward  
>>> to me.
>>
>> Why must an i= value only represent a From email-addresses when  
>> present, when it is equally okay for the i= value to be omitted?   
>> When a DKIM public key imposes a g= restriction, the i= value MUST  
>> contain the restricted local-part or the DKIM signature WILL NOT be  
>> valid.
>
> So what's the problem? Do you expect domains publishing an ADSP  
> policy to intentionally not provide an i= value and include a g=  
> value?

The original motivation for ADSP imposing i= value dependence was in  
hope of causing non-From-g-restricted-signatures to be rejected.   
Ironically, few domains will double-sign exceptions to ADSP's  
requirement that i= values must matching against a From email- 
address.  In effect, this inhibits both the intended use of the i=  
value and ADSP.  If few domains use ADSP, few receiving MTA will  
reject messages on the basis of non-From-g-restricted-signature non- 
compliance with ADSP.

When MUAs annotate using Authentication-Results headers, non-From-g- 
restricted-signatures represent less risk since MUAs can still  
determine the intended identity, whether the identity is the list- 
manager as Sender or the From header.  Currently, ADSP dependence upon  
the i= value may require inclusion of a DKIM signature where the i=  
value is omitted, which can not be done by a non-g-restricted- 
signature.  If non-From-g-restricted-signatures represent a  
significant risk, they should be considered invalid by the base  
specifications!

> I admit that there will always be some people who will screw things  
> up regardless of how careful a framework is constructed and how many  
> warnings and cautions are provided...... so what? It's kind of like  
> publishing an SPF record that consists of only "-all" and then  
> complaining that people are not accepting your mail.

By removing i= dependence, an ADSP assertion of "all" could then mean  
_all_ messages are signed.  This reduces mistakes and keeps things  
simple, while also eliminating possible double signing requirements.

>> It will be evident to an MUA whenever a restricted local-part does  
>> not match against a From header.  It should also be safe for an MUA  
>> to annotate signed headers that match against the i= value, but not  
>> those that do not match, such as when the i= value is omitted or it  
>> omits everything but the d= value.  In such cases, just the domain  
>> might be annotated.
>
> And where is the problem? Go do the lookup against the d= domain.  
> That is what the default is. Notwithstanding the g tag constraint,  
> this works fine thank you very much.

In order to exclude non-From-g-restricted-signatures, all i= values  
that do not match against the From header must currently be double  
signed.  This additional requirement is a problem when few wish to  
double sign otherwise perfectly valid DKIM signatures.

>> In either case, the i= value (on-behalf-of identity) might become  
>> declared as being opaque and thus defined as not representing a  
>> specific email-address.  When the i= value is declared opaque, no  
>> email-address should be annotated, even when it happens to match  
>> against the i= value.
>
> Conflating layers. Just because DKIM base considers it an opaque  
> value does not mean that ADSP must consider it an opaque value. By  
> choosing to publish an ADSP record one is at least indicating that a  
> receiver (again excepting the g tag case you specified with no i=  
> present - a quite artificial construct that should fail) should look  
> at the RHS of the string called an RFC2822From email address.

ADSP records are not checked when there is a valid Author Signature.   
An Author Signature IS a DKIM signature!  If i= values are always  
declared opaque, rather than conditioning opacity on not matching  
against a signed header email-address, then g-restricted-signatures  
will become a meaningless mechanism.  Security must be reviewed in  
light of this mechanism being made meaningless.

>>>> Since the ADSP draft is already internally in conflict on this  
>>>> point, a simple solution would be to drop the i= value  
>>>> requirement in ADSP.
>>>
>>> I see no conflict.
>>
>> Oops.  This has been corrected off-list since version 6.  Section  
>> 3.2 now states Author Signature.  Well, Section 3.2 will need to  
>> change back to Author Domain if or when i= value dependence is  
>> removed.
>>
>> By removing the i= dependency from ADSP, the assertions of "all" or  
>> "discardable" could then apply to any DKIM signature by the domain.
>
> As I have written multiple times (and I'm getting tired of  
> repeating), while simply using d= works fine for me, using i= can  
> make deployment easier for quite a few domains without any  
> significant downside other than causing some people to get ruffled  
> feathers that DKIM base considers the i= string opaque for it's  
> purposes and ADSP imposes a constraint (for those domains which  
> choose to publish ADSP records) with regard to checking against the  
> RFC2822From email address (RHS).

ADSP is not independent of DKIM.  Removing ADSP dependence on the i=  
value enables acceptance of non-From-g-restricted-signatures.  This  
will not affect any sub-domain convenience, nor will it lead to  
exploits that can not be mitigated through refusal of non-From-g- 
restricted-signatures or use of Authentication-Results headers.

-Doug