Subject: RE: [ietf-dkim] I sign nothing / only only 3rd party / some mail

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 27 Jul 2006 15:17:07 -0700

Just thought:

You do need 'I sign nothing' since you need to be able to terminate searches for DKIM policy records regardless of whether we use the extended prefix scheme I propose or some variant of tree walking.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Hallam-Baker, Phillip
> Sent: Thursday, July 27, 2006 3:47 PM
> To: Paul Hoffman; [email-masked]
> Subject: RE: [ietf-dkim] I sign nothing / only only 3rd party 
> / some mail
> 
> I sign nothing has to be there in the matrix even if it is 
> implict by the lack of a DKIM policy record. I dislike this 
> form of signaling,  it leads to unpleasant edge cases, better 
> to do it explicitly.
> 
> I don't see the need to specify anything about third parties 
> though. That is a key record attribute, not a top level 
> policy. If someone only signs third party records then they 
> should only have records for third parties.
> 
> 
> The case where I do see a need that is not yet addressed is 
> the ability to say 'I sign everything with this particular algorithm'.
> 
> The reason it is needed is to manage the transition from a 
> weak signature scheme to a strong one. The existence of a key 
> record means only that it is an acceptable signature key. If 
> I am in a transition situation I am going to be double 
> signing with the legacy algorithm and the new one simultaneously:
> 
> Signature: 1.A, RSA-1024
> Signature: 1.B, DSA-2048
> 
> Assume for a moment that the policy record only says 'I 
> always sign' and that RSA1024 has been compromized. The 
> attacker can then perform a downgrade attack by only 
> provising the first signature:
> 
> Signature: 1.A, RSA-1024
> 
> There is no way for the recipient to know that the signature 
> is compromized, there is no way to know that there should be 
> a strong signature in addition.
> 
> Alternatively the attacker might make use of the fact that 
> there are many verifiers that only support the RSA1024 
> algorithm and perform an 'unsupported upgrade' attack:
> 
> Signature: 1.B, DSA-2048
> 
> If the policy record says 'I always sign with DSA2048 AND I 
> always sign with RSA1024) this issue is avoided and the 
> transition can be managed effectively and securely.
> 
> 
> There are two ways that this could be implemented, one is by 
> direct reference to the algorithm, the other is by 
> subselector. In this case I deliberately used key selectors 
> in different subdomains.
> 
> So the statement then becomes something of the form 'I always 
> sign with a key in *.a._domain.example.com' AND 'I always 
> sign with a key in *.a._domain.example.com'.
> 
> 
> I prefer this particular approach as it allows us to 
> establish arbitrary constraints using appropriate key 
> selector management tools. It also allows for the keys to be 
> referenced to an entirely different domain. So for example 
> example.com outsourced their mail provision to pobox.com 
> which signs with a key managed exclusively by PO.Box. This 
> mechanism allows for a redirection to the signature provider 
> key set. I think we can meet a lot of the use case 
> requirements that way.
> 
> I also prefer the selector approach because it neatly 
> partitions all the crypto in the key records. The policy 
> record remains 'crypto blind'. Same goes for c18n algorithms and such.
> 
> Selectors are good stuff.
> 
> 
> Note that in this approach it is necessary to always retreive 
> the policy record in the case that the verifier is uncertain 
> of the security of a particular signature algorithm. I don't 
> think that this is a major concern since it is very rarely 
> the case that there is widespread use of a seriously broken 
> crypto algorithm, we tend to be very very conservative and 
> plan transitions long before they are forced.
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Paul Hoffman
> > Sent: Thursday, July 27, 2006 2:26 PM
> > To: [email-masked]
> > Subject: [ietf-dkim] I sign nothing / only only 3rd party / 
> some mail
> > 
> > At 2:00 PM -0400 7/27/06, <[email-masked]> wrote:
> > >My requirements
> > >
> > >I sign all
> > >I sign nothing
> > >I sign only 3rd party
> > >I sign all and 3rd party
> > >I sign some mail
> > >
> > >
> > >My Policy/Practice
> > >
> > >I sign all - every piece of mail purported to be from me
> > must be signed
> > >
> > >I sign nothing - If mail arrives with a DKIM sig I didn't send it
> > >
> > >I sign only 3rd party - I only act as a signing domain for other 
> > >domains, I don't sign any of my own mail
> > >
> > >I sign all and 3rd party- I sign all my mail and for other
> > parties as
> > >well
> > >
> > >I sign some mail - I sign only mail that I am willing to
> > swear that I
> > >am responsible for
> > 
> > I am completely confused by "I sign nothing" and "I sign only 3rd 
> > party" and "I sign some mail". I don't see the value of 
> those to the 
> > recipient.
> > 
> > "I sign nothing" seems weird. If I have something signed by your 
> > domain, and I cannot get the signing key from your domain, "I sign 
> > nothing" adds no value. The signature is invalid. If an 
> attacker can 
> > inject a DKIM header and a key, he can also suppress the 
> SSP response.
> > 
> > "I sign only 3rd party" has the same attack problem as "I sign 
> > nothing".
> > 
> > "I sign some mail" doesn't tell the recipient anything useful.
> > 
> > What am I missing?
> > 
> > --Paul Hoffman
> > _______________________________________________
> > 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
> 
> 

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