ietf-dkim
[Top] [All Lists]

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

2006-10-24 10:02:57

Thanks for persevering Phill,

Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] 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.

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.

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.

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

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 signature without the need to put any 
information of that type into the policy record.

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.


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