On Jun 4, 2009, at 3:46 PM, Jon Callas wrote:
On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote:
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
Again, forgive me, Doug, but what is the issue that's not being
discussed? I genuinely don't understand what you're trying to say.
I don't mean to put words in your mouth, but are you saying
describing this use case:
* Sender puts a key K_1 into the DNS. K_1 is of algorithm A_1, but
the DNS entry does not note this fact.
* Sender creates an email E_1 that is signed with K_1 and sends it
to Receiver.
* Attacker creates a key K_2 that is of algorithm A_2.
First assume there is a _real_ transition to different DKIM algorithms
sporadically occurring. Perhaps based upon being targeted by bot-net
resources.
An attacker spoofs a K_2 signature referencing a sender's K_1 key.
Due to the lack of key assertions, the reference creates an appearance
that the signature might be "unverifiable" rather than "invalid" or
"spoofed".
* Attacker creates an email E_2 that is forged from sender, and
signed with K_2, but refers to the DNS entry for K_1. Attacker sends
this email to Receiver.
The attackers know recipients have found _some_ signatures are not
supported by their provider. Due to the lack of key assertions,
attackers will not need to use untrusted key domains, or to only spoof
the domains using new algorithms.
* Receiver verifies E_1 and accepts it as having a valid signature.
This is normal, expected DKIM operation.
Recipients now see many spoofed unverifiable signatures, in which some
are legitimate messages. They may even be aware of the situation in
the news. Being able to confirm whether the purported signer employs
a new algorithm would reduce the level of this type of spoofing, since
it would work against only a few select domains, of which many
recipients may not care about, or might know how to identify through
some other means, such as selected pass-phrases. One might also
expect that transitioning legitimate signers could offer utilities to
confirm their signature whenever a provider might not.
* Receiver verifies E_2 and accepts it has having a valid signature.
This is erroneous behavior because it was verified with A_1 despite
having been generated by A_2.
Again, this issue is about algorithm agility. A means to transition
while avoiding confusion. When a domain becomes targeted, it might
become necessary to abandon widely adopted algorithms.
Is this the scenario you're describing as being undiscussed?
No.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html