-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jun 4, 2009, at 5:00 PM, Douglas Otis wrote:
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".
But signatures are a mathematical operation that ultimately come down
to comparing two numbers to see if they are equal.
They're either equal (valid) or not equal (invalid). There isn't a
third state.
Within the framework of DKIM, there are other ways you can get to an
invalid signature. For example, if I pull K_1 from the DNS, the
signature is invalid because the key is gone. If I pull a key, all the
messages I signed go instantly (modulo TTL, etc.) invalid.
But the only way the condition you describe can happen is for there to
be a failure of cryptography in ways that are nearly completely
unimaginable.
I say that because first of all, keys are of different sizes. You
aren't going to cross-sign an ECC key to an RSA key because the
signature isn't going to be right even with basic things like its
size. You'll never confuse a 256-bit EC signature with a 2048-bit RSA
signature. And if you do, then the software is so broken that you
might as well ask what we do here if someone writes a DKIM
implementation that always verifies a signature, even if it's bad. In
that case, the software has a very bad bug.
If you look at key type where K_1 and K_2 are the same type, you're
effectively saying, let's assume that the public key cryptography is
completely broken. (Or again, there's some massively stupid error in
the software.)
While it is not outside the realm of possibility that some major form
of cryptography will get a massive break to it, it is highly unlikely
to be overnight. And no matter how it happened, there are bigger
issues than DKIM. Sure, it's in trouble, but so is every SSL cert out
there.
But that doesn't necessarily mean that the key type flag should go.
There's a much better reason to keep it, which I'll describe here:
The flag is there are part of the rough consensus we got when we
finished DKIM Base. Because it represents part of that rough
consensus, the burden should be on the people who want to remove it as
to why it should be removed, not on the people who want to keep it.
There are several purposes the flag serves:
* It provides a consistency check on the keys and the signatures. It
is easier for the software to determine that they've been cross-
threaded if there's a tag, as well as for the administrators. If you
see that a signature that should be working is actually referring to
the DNS for a different type, it will save effort.
* The signature checking mechanism is going to have to error-check the
key parameters anyway, so why not have an easy pre-flighting via the
type check.
* If you consider the case of an attacker who is trying to exploit a
bug in cross-threaded keys, this gives a way for the attempt to easily
be thwarted as opposed to some checks buried deep in the cryptography.
* A lot of what we call trust is the users believing in the software.
Despite the fact that it is indeed essentially impossible for there to
be a cryptographic error, crypto is hard to understand. Look at how
ill-understood the SHA1 issues are. This is an easy way to give
explainable, understandable warm fuzzies to administrators everywhere,
and as I said above, it even simplifies error-checking and makes it
more reliable.
There, that's a much better set of reasons to keep it.
Jon
* 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
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFKK4FDsTedWZOD3gYRAh3iAKCvpotUvjE6ggfznTUfk7Gn/jDCMACgvQF5
z83mzbqLxfPWa3ghpLaokqY=
=UTqr
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html