Subject: RE: [ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-02.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Oct 2006 09:42:02 -0700

> From: Stephen Farrell [mailto:[email-masked]] 
> Hallam-Baker, Phillip wrote:
> > Your restatement of my point misses the point entirely:
> > 
> > IF there is a signature that the recipient can use
> I think you mean "IF there was ever a ..."
> > THEN the recpient should know that there is such a signature
> and s/is such a/was ever such a/
> 
> But why? The consensus we have now is that the recipient 
> alone is able to figure what signatures it can use and that 
> that's enough. You've not explained why this is insufficient 
> (or I'm just even dumber than usual;-).

Stephen,

The missing use case here is that we decide to add to the set of algorithms used by DKIM. Let us imagine that we are proposing a new canonicalization algorithm. We need to have a use case describing this scenario in the requirements document and a statement of the architectural and design requirements that supporting this use case entails. Otherwise we will end up yet again with another IETF specification that requires us to wait for the entire installed base to change before we can deploy.

Consider the following two policies:

	X: "Every email has at least one signature"
	Y: "Every email has a signature of type A and a signature of type B"

Now consider a recipient that only supports verification of signature type A.

Consider the following attack:

	Bogus message with signature of type B.

This message is consistent with policy X, it is not consistent with policy Y. This means that if our policy language can only express policy X it will not be possible to tell the recipient the information it needs to know in order to determine that the message is bogus.

Furthermore as presently specified SSP means that if there is any key record in the domain that specifies a signature algorithm that may not be supported by every recipient it is possible to send forged messages.

The point is that the current policy language does not provide sufficient power to allow a recipient to determine whether there should be a verifiable signature present.

The solution is to adopt the selector contraint mechanism I propose. This allows signers to develop an orderly transition from one algorithm to another whether it be canonicalization, hash or signature without the need to put any information of that type into the policy record.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2006 17:54:13 +0100

Thanks for persevering Phill,

> The missing use case here is that we decide to add to the set of algorithms used by DKIM. Let us imagine that we are proposing a new canonicalization algorithm. We need to have a use case describin…

I agree that post-deployment changes to C14N have been common in
signature schemes, so if there're things we can do to make that
transition easier, that is a good goal.

> This message is consistent with policy X, it is not consistent with policy Y. This means that if our policy language can only express policy X it will not be possible to tell the recipient the info…

Huh? The recipient doesn't support signature type B and will therefore
not consider the message signed. Same as if the message were an unsigned
forgery or a real unsigned message, or has been mangled etc. So I don't
see the benefit in the recipient finding out (via SSP) that the signer
does use B, if the recipient cannot (cryptographically) check that the
message is accompanied by such a signature and not just some random
bits in the correct format.

> Furthermore as presently specified SSP means that if there is any key record in the domain that specifies a signature algorithm that may not be supported by every recipient it is possible to send f…

It is always possible to forge messages. Our job here is to make
it relatively easy to do a good job verifying real ones.

> The point is that the current policy language does not provide sufficient power to allow a recipient to determine whether there should be a verifiable signature present.

That is true, but I don't see it as a problem for the reasons
stated above.

> The solution is to adopt the selector contraint mechanism I propose. This allows signers to develop an orderly transition from one algorithm to another whether it be canonicalization, hash or signa…

Your solution may be fine, but you've still not convinced me
(chair hat off etc.) about this being an SSP requirement.

Maybe others have thoughts on this, having read this thread?

S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Oct 2006 11:07:16 -0700

On Oct 24, 2006, at 9:54 AM, Stephen Farrell wrote:

>> This message is consistent with policy X, it is not consistent  
>> with policy Y. This means that if our policy language can only  
>> express policy X it will not be possible to tell the recipient the  
>> information it needs to know in order to determine that the  
>> message is bogus.
>
> Huh? The recipient doesn't support signature type B and will  
> therefore not consider the message signed. Same as if the message  
> were an unsigned forgery or a real unsigned message, or has been  
> mangled etc. So I don't see the benefit in the recipient finding  
> out (via SSP) that the signer does use B, if the recipient cannot  
> (cryptographically) check that the message is accompanied by such a  
> signature and not just some random bits in the correct format.

There are two elements checked when DKIM_BASE and DKIM_POLICY are  
used to validate incoming messages.  Once multiple signatures bridge  
an algorithm transition, then DKIM_POLICY expressed somewhere can  
remove doubt about which algorithms should be present.  In practice,  
any algorithm transition may take years and may also involve more  
than one alternative.

In cases where there is doubt:

a) the user may be asked to sort through questionable messages,  
rather than having them rejected outright;

b) deprecated signatures may be accepted, when a supported non- 
deprecated signature should have been present;

-Doug