Oh come on. We're done on that issue. Let's at least try
make progress please. You suggested it. The WG chose not
to do that. That's all.
S.
Douglas Otis wrote:
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
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html