Subject: RE: [ietf-dkim] Base issue: multiple linked signatures

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 26 Dec 2006 17:24:58 -0800

I don't quite see what the objective is here.

There is a lot of information that a sufficiently dedicated client might infer from multiple signatures made by the same signer but I am not sure that there is much value to be gained unless particular multiple signature practices are in widespread use.

Multiple signatures made by different signers are an entirely different matter, in a store and forward world there will always be the possibility of damage occuring. But all we need for the purposes of spam control is one trusted party that volunteers to be held responsible.

Equally multiple signatures of the same content under different signature algorithms are useful to allow transition from a legacy signature algorithm to a stronger one.

If the purpose of the signature is for debugging the sending path rather than for accepting responsibility then I think we are talking about something that is beyond base.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of EKR
> Sent: Tuesday, December 26, 2006 7:08 PM
> To: Paul Hoffman
> Cc: DKIM Mailing List
> Subject: Re: [ietf-dkim] Base issue: multiple linked signatures
> 
> Paul Hoffman <[email-masked]> writes:
> 
> > At 3:43 PM -0800 12/26/06, EKR wrote:
> >>I don't know what's being proposed here, but as a technical matter 
> >>it's not really the case that you can't individually insulate each 
> >>header from breakage without doing a separate signature for 
> each one. 
> >>Rather, you could simply include digests for the header 
> value in the 
> >>header specification, i.e.,
> >>
> >>    DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
> >>       c=simple; q=dns/txt; i=@eng.example.net;
> >>       t=1117574938; x=1118006938;
> >> 
> h=from=<digest-value>:to=<digest-value>:subject-<digest-value>
:date=<digest-value>;
> >>       ...
> >
> > This is actually less information than the z= tag, which 
> says what the 
> > value was when signed.
> 
> Yes, that's true, so even without this optimization it's not 
> true that you need to a separate signature for each header.
> 
> That said, this representation is more compact, so it's a tradeoff. 
> 
> It also doesn't come with this restriction:
> 
>        Verifiers MUST NOT use the header field names or copied values
>        for checking the signature in any way.  Copied header field
>        values are for diagnostic use only.
> 
> But of course that restriction could be relaxed.
> 
> -Ekr
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Dec 2006 07:35:43 -0800

On Dec 26, 2006, at 5:24 PM, Hallam-Baker, Phillip wrote:

> There is a lot of information that a sufficiently dedicated client  
> might infer from multiple signatures made by the same signer but I  
> am not sure that there is much value to be gained unless particular  
> multiple signature practices are in widespread use.

The vast majority of email is spam.  It will not take much to cause  
DKIM verification to be switched off once a common practice of using  
multiple signatures offers a means to hide.  There are millions of  
new domains added every day.  The current DKIM spec in section 4  
recommends damaged signatures not be removed.  This means a good  
actor might leave dead signatures in messages.  The current mindset  
then assumes the signing-domain and the email-address being added are  
within the same domain.

The continuing assumption that the email-address domain and the  
signing-domain are one-and-the-same also demands an unmanageable  
exchange of private-keys or the delegation of domains.  While this  
requirement places greater control into the hands of major providers,  
this does absolutely nothing in helping abate abuse, just the  
opposite.  It would also raise costs associated with the use of  
domains not provided by the email-provider.  Added administration and  
costs will mean that DKIM is not a scalable solution for email.  A  
minor change can make a world of difference in this regard.

-Doug