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 PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 24, 2006 9:39 AM > To: Hallam-Baker, Phillip; [EMAIL PROTECTED] > Cc: [email protected] > 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 PROTECTED] on behalf of > Hallam-Baker, Phillip > Sent: Mon 10/23/2006 5:29 PM > To: Stephen Farrell > Cc: [email protected] > 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 PROTECTED] > > Sent: Monday, October 23, 2006 5:07 PM > > To: Hallam-Baker, Phillip > > Cc: [email protected] > > 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
