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 PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Hallam-Baker, Phillip > Sent: Thursday, July 27, 2006 3:47 PM > To: Paul Hoffman; [email protected] > 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 PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman > > Sent: Thursday, July 27, 2006 2:26 PM > > To: [email protected] > > Subject: [ietf-dkim] I sign nothing / only only 3rd party / > some mail > > > > At 2:00 PM -0400 7/27/06, <[EMAIL PROTECTED]> 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
