At 12:09 PM -0800 2/23/07, Dave Crocker wrote:
Deployment Scenario 7: Cryptographic Upgrade and Downgrade Attacks
In the case that a signer advertises key records for multiple
signature algorithms this may allow an attacker to circumvent an
insufficiently expressive signature policy.
Example:
Legitimate sender advertises key records A, B. Record A describes
a signature key for a widely supported signature algorithm. Record
B describes a signature key for a signature algorithm that is not
generally supported. The senders signature policy says 'I always
sign every message'. The sender always signs messages with
algorithm A (whether algorithm B is used by the legitimate sender
as an additional algorithm or not does not affect the success of
the attack).
Color me confused. I thought we agreed long ago that downgrade
attacks were not an issue for the problem DKIM addresses.
What Phill describes is not a downgrade attack: it is an attack based
on algorithm agility. If we allow multiple algorthims, and not all
the algorithms are the the "MUST implement" level, this attack is
feasible. Every protocol with algorithm agility but not a fixed list
of "MUST implement" algorithms has this issue.
In general, there are myriad ways to break a signed message, to
render the signature invalid. We have chosen not to attempt to
prevent breakage.
Phill's example does not deal with breaking a signed message, nor
rendering a signature invalid.
More basically, we are moving quickly into the morass of requiring
SSP lookups for signed messages, rather than limiting SSP for use
with unsigned messages.
I agree that this is an example of an SSP lookup for signed messages.
I hope it does not mean that we are opening the door for other
purposes. It is also not requiring an SSP lookup; the only time you
care if the message is signed with an algorithm you don't understand
is if you know that they sign all messages. Therefore, you already
did the SSP lookup to find out that information. The algorithm list
would come along with the "I sign everything" information.
Besides the technical hassle of adding overhead, this also means
that current potential adopters of DKIM will see DKIM -base use as
remaining unstable.
Only if you tell them that it is. SSP does not destabilize dkim-base.
And I hope folks do not understimate the danger from this, because
it has already been a point of discussion in industry meetings among
potential adopters.
Fully agree.
There is a very simple distinction we can make:
If a message is signed, then the signature (and associated key
information) speaks for itself. If the organization has constraints
on who is allowed to sign a message or what message they are allowed
to sign, or what algorithms they are supposed to use, then that is a
matter for internal management within the organization. It is not
the job of a public standard to recruit a recipient into enforcing
sender-side internal administrative policies. If an organization
chooses to publish support for a weak algorithm, again, that is
their problem, not the recipient's.
Fully agree.
Hence, SSP should be used for receipt of unsigned messages.
Statements like "I sign everything" and "I send no mail" are
examples.
...and so is "I sign everything with Algorithm A".
--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html