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

[Hallam-Baker, Phillip]

> From: Stephen Farrell [mailto:stephen.farrell at cs.tcd.ie] 
> Hallam-Baker, Phillip wrote:
> >> From: Stephen Farrell [mailto:stephen.farrell at cs.tcd.ie]
> >> Hi Phill,
> >>
> >> Hallam-Baker, Phillip wrote:
> >>> 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.
> >>
> >> 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.)
> > 
> > The two examples you give are entirely different.
> 
> No. I just wasn't clear. My point was that a bad guy most 
> likely doesn't have to lookup policy (via DNS) if he sees a 
> message that conforms - that's enough to derive loads of new 
> messages that do
> (probably) conform to the published policy. I wasn't 
> considering strict replay, only totally bogus messages.
> 
> > Case 2: Policy at Paypal is 'I always sign with at least A'
> > 
> > 1) If any signature under the paypal.com domain is valid 
> the message is accepted.
> > 2) If there is no signature whatsoever the message goes in the bit 
> > bucket
> > 3) If there is no signature with A the message goes in the 
> bit bucket
> > 4) If there was a signature with a key record in A for an 
> algorithm that is not understood then process the message 
> using content filtering.
> 
> Eh..didn't you leave out:
> 
> 5) Everything is policy-conformant, the receiver understands A,
>     but the signature bits are just wrong (since the message is
>     totally bogus).

No, if you have a signature that does not verify you treat it as if it did not exist and reject the message under rule 2.

Treating a message with an invalid signature as if it was unsigned means precisely that. Unsigned messages go to the bit bucket and bogus signatures follow them. The problem that some people seem to be having here is that they have internalized this as 'failed signatures don't matter' which is not the case when you have policy. The whole point of policy is to allow a signer to allow receivers to take a different path when they notice the absence of a signature.

Providing a specified, deterministic path for this processing is vastly better than waiting for receivers to develop heuristics to induce the same information based on the number of legitimate messages they see that carry signatures.


Paypal messages do not get routed through mailing lists so a message with a broken sig is either the result of forwarding (which is checkable), misconfiguration at Paypal (which is unlikely and means bit bucket) or fake (bit bucket).