On Aug 2, 2006, at 3:12 PM, Hallam-Baker, Phillip wrote:
NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK.
As far as Bob is concerned the email is in compliance with policy
so he has to accept the message as being compliant with the
signature policy even though it is not.
On this I tend to agree with you. However, until someone
demonstrates a chronic non-catastrophic scenario, it would appear few
want to go through the exercise. From an overhead standpoint, the
announcement that prevents the downgrade attack of a deprecated
version, algorithm, or query method could be included within the key
supporting the element declared as deprecated. Once both the sender
and verifier have upgraded, this would immediately thwart a downgrade
attack. When the verifier has not upgraded, it would act a warning.
Both policy and key are found in DNS, so this limits the value having
this announcement in policy, rather than in the key that must be
acquired. Depending upon how policy is used, it may not be acquired
for every message. However the sender can control whether the key is
acquired. Although the list of possible weak points is not complete,
version could act as a catch-all.
The selector mechanism is a simple fix.
I tend to agree with John, the selector mechanism seems overly
complex. Perhaps a convention of right-hand labels within the
selector, or adoption of the r= mechanism could simplify this
somewhat. The r= mechanism also has the advantage of not impacting
key management, which should also simplify when and where it gets
applied.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
