ietf-dkim
[Top] [All Lists]

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

2006-10-23 14:40:46
I don't think that we are re-opening anything here.

I am not proposing to re-open base or to place any algorithm identifiers in the 
policy record. In fact quite the opposite. My reading of the requirements as 
written is that they suggest that the policy record should enumerate the 
acceptable signature algorithms. That is the opposite of what I want.

My position is that every key record, by its very existence indicates an 
acceptable signing profile.

Where we disagree is that I believe that it is necessary for the policy 
language to specify that multiple signatures are present meeting different 
selector matching criteria.


This is not a repeat of any closed issue since the response each time in the 
past has been 'this is not currently in scope because it is policy'. Ergo the 
issue cannot be closed because it was never open. 
 

The requirement is that the policy language be able to state:

"There is a signature present of type A" AND "There is a signature present of 
type B".

If a verifier finds a signature present that is 1) valid and 2) meets their 
security requirements the message is considered to be authentica and no further 
checking is required.

Where a difference is made is in the behavior when a signature is found that 
does not meet the verifier's security requirements, either because the 
algorithm is unsuported (upgrade attack) or because the algorithm is considered 
compromised (downgrade attack). In these cases the verifier MUST pull the SSP 
record even though a signature is present because the signature that is present 
is not one that the verifier can use.


Since we will not be specifying compromised algorithms initially the only code 
path that requires implementation is what to do when you have a signature 
present that you do not support. We absolutely do need to have a mechanism that 
allows the verifier to know that it should expect there to also be a signature 
that it can use.

The spec is broken without this. 



-----Original Message-----
From: Stephen Farrell 
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] 
Sent: Monday, October 23, 2006 5:07 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Comments on 
draft-ietf-dkim-ssp-requirements-02.txt


Hi Phill,

Before we get into the wording of the latest ssp-reqs, can we 
try to figure out whether this is really different from the 
set of similar *closed* issues on base?

I am not at all clear why such flags are useful in SSP, given 
that we have rough consensus that they are not needed for base.

As I see it:

1. The current WG consensus for base is that its up to each 
recipient to decide for itself which algorithms it considers 
acceptable.

2. The current WG consensus (I think) is that SSP need not be 
used when a signature that the recipient considers "good" is 
present. (I.e.
I see no consensus for a position that SSP MUST be used even 
if what the verifier thinks is a good signature is present.)

Given 1 & 2 above, I just don't see the point of algorithm 
transition information in SSP since no-one will read it who 
might act on it.

Please also expliticly explain why this is not simply 
revisiting some *closed* issues on base.

Thanks,
Stephen.





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