On Jun 4, 2009, at 11:34 AM, Jon Callas wrote: > > On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote: > >> The basic question is simply this: is it sufficient to list the key >> algorithm in the header? I don't see a plausible attack, so I'm >> okay with that. But let's at least have the debate based on facts. > > It is in fact sufficient to list the key algorithm in the header. > > Let us suppose for the sake of argument that the DNS contained an > undifferentiated bag of bits. There is no plausible attack against > that. You can't lie to someone and get them to get a false > positive. Or to phrase that another way, if you could do it, then > there's a Best Paper award waiting for you at the next CRYPTO and > you'll be catapulted into the limelight for your crypto-fu. It would > likely also be a new fundamental result in core mathematics, as well.
This non-issue overlooks the intended goal of the k= parameter within the key that is not being discussed. When is it safe to decide algorithm agility is not improved by assertions that allow senders to explicitly indicate their supported the algorithm which may differ form an unverifiable DKIM signature? Clearly, such messages should be outright rejected, whereas the alternative would require the recipient to wonder why the signature failed. What problem might be created when this feature remains as currently defined? Why are we going over this again? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
