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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 24 Oct 2006 07:00:45 -0700

Your restatement of my point misses the point entirely:

IF there is a signature that the recipient can use
THEN the recpient should know that there is such a signature

If this condition is not met an attacker can perform upgrade and downgrade attacks in which the attacker attaches a bogus signature.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 9:39 AM
> To: Hallam-Baker, Phillip; [email-masked]
> Cc: [email-masked]
> Subject: RE: [ietf-dkim] Comments on 
> draft-ietf-dkim-ssp-requirements-02.txt
> 
> Phillip,
> "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."
> 
> We need to have a policy record that indicates what the 
> receiptient should expect. Im not sure of the requirement 
> that there be a signature that the receiptient can use.
> thanks,
> Bill
> 
> 
> 
> -----Original Message-----
> From: [email-masked] on behalf of 
> Hallam-Baker, Phillip
> Sent: Mon 10/23/2006 5:29 PM
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: RE: [ietf-dkim] Comments on 
> draft-ietf-dkim-ssp-requirements-02.txt
>  
> 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:[email-masked]]
> > Sent: Monday, October 23, 2006 5:07 PM
> > To: Hallam-Baker, Phillip
> > Cc: [email-masked]
> > 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
> 
> 
> 

_______________________________________________
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 15:06:37 +0100

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

> If this condition is not met an attacker can perform upgrade and downgrade attacks in which the attacker attaches a bogus signature.

What's the problem with this attack that differs from the
the attacker just flipping one bit of a real, acceptable
signature? I don't see it.

S.