ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: Base: Upgrade indication and protection against downgrade attacks

2006-02-16 09:38:26


Michael Thomas wrote:
If you can't rank algorithms, is there any meaningful concept of a
"downgrade attack"?

Yes. The "you" above is ambiguous though - every one can have their
own ranking, but we cannot all have the same ranking (it seems).

I'm sort of wondering though if Mark's problem here might be just as
easily solved by having a "current"/"next" kind of routine. That is,
only allow two in play at any one time, where < n-1 is deprecated.
Considering that 2822 is not nimble (ie, no ability to negotiate
e2e), is there any real likelihood that a reasonable receiver will
be two versions behind? It sort of strikes me like 40 bit only rc4
ssl: should we even care about such lame receivers?

I think something along those lines might do it. Or else maybe have
the signer flag their "favorite" algorithm's public key, and let
verifiers who don't see one of those signatures be wary if they like.
(But before I'd want us to make such a decision I think we'd need to
spell out the entire signature algorithm agility story - perhaps a
good agenda item for Dallas?)

S.


_______________________________________________
NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>