[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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