Subject: [ietf-dkim] We are actually disagreeing on the point of policy Was RE: 1368 straw-poll

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Feb 2007 05:48:28 -0800

> [mailto:[email-masked]] On Behalf Of John R Levine

> Wearing, as usual, my receiver hat, I still don't see any 
> reason to be interested in random senders' opinions about the 
> relative merits of various algorithms.
> 
> Like I said before, let's say someone publishes SSP saying 
> sha256 is deprecated and rot13 is shiny and new.  What should 
> I do with that info?
> 
> Assuming we agree that it's stupid and I should ignore it, 
> how am I supposed to tell stupid deprecation advice from 
> non-stupid deprecation advice?

I don't know who you think is saying that but it isn't me.

The sequence of events hypothesized is:

1) Sender determines that the existing algorithm is deprecated
2) In response to (1) sender prepares to support an additional signature algorithm
3) In order to support (2) sender publishes an additional key record for the new algorithm

4) Mallet starts sending bogus messages with forged signatures purporting to be under the new key

5) Receivers that have not yet upgraded to support the new algorithm are unable to determine that the messages with forged signatures are inconsistent with the signer's policy.

The receiver is not required to accept the belief that the existing algorithm is deprecated. 

Again, the point is that if we are going to have a policy mechanism at all then the policy mechanism must be designed in a way that prevents an attacker circumventing it. 

'I sign all messages' allows the receiver to draw useful conclusions if and only if the receiver is capable of processing every single key record specified by the signer.

'I sign all messages with a key record in group X' allows the receiver to draw useful conclusions if and only if the receiver is capable of processing every single key record specified by the signer *in group X*.

The first fails in the five year period one might expect to elapse while a new algorithm is being deployed and an old one is phased out. The second does not.

The disagreement raised here really have nothing to do with the 1368 issue. The objections being raised to changing SSP can all be made against SSP and the concept of policy. If you don't get the 1368 objection its because you either have a different idea of what policy for or you don't believe that there is a point to policy.

It is axiomatic here that specifying a policy language will modify the processing of messages as described in base and that policy will include concepts that are out of scope for base. Otherwise we would be done.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Feb 2007 14:10:39 +0000

Hi Phill,

> 5) Receivers that have not yet upgraded to support the new algorithm are unable to determine that the messages with forged signatures are inconsistent with the signer's policy.

I think that that is clear. However, what do you say to the fact that
anyone can produce a message with a bad signature that does adhere to
such a policy? (By looking up the policy or copying a real example.)

Given that problem I really don't see what the receiver can confidently
do with such a message that differs from handling a totally unsigned
message. Can you provide some examples?

Thanks,
S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2007 06:47:43 -0800

> 3) In order to support (2) sender publishes an additional key record for the new algorithm

    what is the h= in the selector?

> 5) Receivers that have not yet upgraded to support the new algorithm are unable to determine that the messages with forged signatures are inconsistent with the signer's policy.

    If there is h=newalg in the selector, the receiver will reject
    Mallet's signature if it uses oldalg. This is true regardless
    of whether the receiver is upgraded or not.

	Mike