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

[Michael Thomas]

Hallam-Baker, Phillip wrote:
>> [mailto:ietf-dkim-bounces at mipassoc.org] 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

    what is the h= in the selector?

> 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.

    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
> 
> 
> 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.