> [mailto:[EMAIL PROTECTED] On Behalf Of Charles Lindsey > Sent: Wednesday, July 11, 2007 6:18 AM
> > On Jul 10, 2007, at 2:15 PM, Hallam-Baker, Phillip wrote: > > > >> I would like to discuss the downgrade attack certainly. We have to > >> address the attack either by solving it or by explaining it in the > >> security considerations. > >> > >> Doug's statement above is not correct though. A recipient > ONLY looks > >> at the policy record if it does not find an acceptable > signature record. > >> That means: > > Eh? A recipient can look at a policy record whenever he sees > fit to do so, and for whatever reason. This is true, in particular the verifier might well find it more efficient to pull a policy record before checking the signature. But an authenticated signature always dominates policy according to the specification. > > E) The message has a signature by a Third-Party domain. If all you are doing is spam control a signature from an accountable third party is sufficient and you would not need to check policy. If bank of america sends a message to the list where it gets munged and resigned that is going to be acceptable at some level. If we want the ability to insist on being able to distinguish this case we will need to do a lot more. I would much prefer to wait till a recharter. In particular I think it will be much easier to do that type of policy after the email infrastructure has made accomodation to DKIM. > F) The signer seemed to be unrelated to the > From/Sender/Whatever headers; > > G) The signature covered an "unusual" selection of headers; That would be another example of not sufficient. > H) There were several signatures, of which some passed and > some failed; Failed signatures are ignored. > A Policy Record might well clear up some (probably not all) > of such cases. > Moreover, experience will throw up new scams that the Bad > Guys will invent, and so it may become necessary to add new > kinds of information to Policy records that we have not even > thought of yet. So, to that extent, their notation needs to > be extensible. Some of which will be something DKIM needs to deal with, some will not. Phill _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
