Murray Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Tuesday, June 02, 2009 4:18 AM
To: Eliot Lear
Cc: Russ Housley; dcrocker(_at_)bbiw(_dot_)net; DKIM WG
Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Eliot Lear wrote:
... you do not see a benefit in stating the algorithm in the key
record when it has already been stated in the header, that perhaps there
is some nebulous potential downgrade attack. Is that right?
Yes.
And it's not "the" algorithm in the DNS record; it's a list of possible
algorithms. The list does not help the receiver know which algorithm
is used for a particular message.
I'm neutral on dropping k= from key records, but I would also volunteer that
"k=rsa" doesn't really tell me much when the published key is an RSA key. It
would be pretty amazing to me for some other key mechanism to come into
common use which would actually work with RSA functions, so incompatibility
will take care of this anyway.
So if a=rsa-sha256, then the key I get from issuing a query based on s= and
d= will be an RSA key, or it will fail to verify. What k= offers is somewhat
redundant except for the fact that I can avoid the crypto overhead if I can
detect early on that it won't work anyway.
The main reason I can tell is that if you get k=megadeath, you'll not bother to
try to run the rsa verify on the message. If we drop k= and then latter add it
back
in because rsa is botched, the verifier will then have to go through the motions
of doing the rsa verify (possibly exposing programming errors too) since it
won't
know about the resurrected k= (or whatever it might be in the future).
Seems like a bad idea to me. It's not like k= is hurting anything.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html