Subject: RE: [ietf-dkim] Re: 1368 straw-poll :

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 10:42:44 -0800

> [mailto:[email-masked]] On Behalf Of EKR

> I'm sure I'm going to regret wading in here, but...
> 
> We have two algorithms, A and B. Let's stipulate that B is 
> stronger than A. Now, the sender can have three policies: 
> send A (SA) Send B
> (SB) and send A+B (SAB). The receiver can similarly have 
> three policies, accept A (RA), accept B (RB) and accept A or B (RAB).
> 
> If you cross these you get the following matrix:
> 
>                  Sender
>              SA    SB    SAB
>          RA   A     X      A
> Receiver RB   X     B      B
>          RAB  A     B     AB

You are conflating the signing policies and the advertisement of key records. 

The whole point here is that you can solve the problem by having a signing policy that is sufficiently expressive to describe what you do. The above matrix works as you point out.

The matrix that fails is:

S 'I sign everything'

We have cases KA KB KAB for advertises Keys A, B, A and B.

There are three states of interest in the matrix:
    V   - Receiver is able to verify the signature
    ?   - Receiver is unable to verify the sender's signature
    X   - Receiver is unable to verify compliance with the signer's policy
              despite being able to verify the signer's signature

                        Sender
                  S(KA)  S(KB)  S(KAB)
             RA     V      ?       X
   Receiver  RB     ?      V       X
             RAB    V      V       V

The problem is the appearance of the X results as soon as the sender advertises multiple keys. As soon as the key B is advertised an attacker can create spoof messages that appear to comply with the policy.

Reiterating arguments that apply to BASE is to miss the point. Policy is not Base or else it would be in Base. The only reason to do policy is to provide features that are out of scope for base. 

> Because implementations are supposed to ignore signatures 
> they can't verify, the only context in which downgrade 
> attacks matter is if the sender is implementing SAB and the 
> receiver is implementing RAB.

The downgrade attacks disappear here because you are assuming that the policy allows you to say what it needs to say.

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 10:54:09 -0800

> [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Monday, February 26, 2007 12:30 PM
> To: [email-masked]
> Subject: [ietf-dkim] Re: 1368 straw-poll :
> 
> Michael Thomas wrote:
> >> been deprecated.  To permit a graceful transition, both the 
> >> deprecated algorithm (whatever that might be) and some shiny new 
> >> algorithm must now be included with the message.  Once 
> your verifier 
> >> adopts the shiny
> 
> [ Two valid signatures in the message ]
> 
> Wasn't this always the transition plan? The only crucial 
> point is that the Selector associated with the "weaker" 
> signature has to tell the verifier to expect the presence of 
> "stronger" signature.

Actually you would need to have the information in both records, otherwise I can 'sign' a message with forged B in the expectation that you don't know how to verify.

So the policy/key records become something like 

_Policy.example.com   TXT "DKIM"
K1._keys.example.com  TXT "v=sijfhwiuhyfiuh a=rsasha1 also=k2._keys.example.com"
K2._keys.example.com  TXT "v=weroiu23498y23 a=rsasha256 also=k1._keys.example.com"

OK that is indeed an additional way to do it.

The plus side is that it avoids the need to read the policy record at all.

The minus side is that you have more complexity in the key records and in particular the key records are now expressing policy. It also means adding features to the key record (not an issue for me but is for some).

At this point though we are discussing the requirement which simply addresses the question of whether you need to be able to express the information at all not where it is organized.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Feb 2007 11:01:05 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Monday, February 26, 2007 1:11 PM
> To: EKR
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Re: 1368 straw-poll :
> 
> In my view, it doesn't matter if its A, B, AB, XYZ or weaker or 
> stronger.   It is about expectations.
> 
> if S says I only sign with A, then R should not see 
> signatures with B, X or Y.

I don't think anyone has suggested that semantic.

The semantic suggested here is 'I always sign with A', this says nothing about B.

The problem is that when you advertise a key record for B you are in effect saying 'I might sign with B'.

If your policy only allows you to state 'I always sign' and the receiver is unable to support B (inevitably the case for some verifiers on day 1 of a transition) then in that case the policy can be interpreted as 'I always sign with B' which is equivalent to 'I always sign with an algorithm you don't know how to verify' 

That could well be the signature policy for some signers, but most signers will in a transition sign with A and with B and all that is being said here is that the policy language should be expressive enough to state this.