I agree that to avoid downgrade attacks there has to be a way to mark a
key as obsolete in the DNS, meaning: "don't use this key if you know
what this means". But I don't see a need to explicitly put another
algorithm name in the field.
For example, let's say an obsolete record can be marked with just "o=1"
to say it should only be considered by legacy verifiers who don't know
better. A new resolver would only consider keys that are NOT marked as
obsolete, and ignore the others. So if a message is only signed with
keys marked as obsolete (downgrade scenario), legacy verifiers would
pass, while new ones wouldn't.
Another thought:
If we want to put a meaningful value in this new field, I think it would
be more useful to make it the time since when the key was obsoleted,
this would allow for mail dated before that moment (which was correctly
signed only with then-not-obsolete keys) to pass verification. This
should be optional, so one could choose if he rather have some valid
mail fail verification, or risk some invalid back-dated mail pass
verification.
--
Federico
On 07/04/2017 11:06, Vladimir Dubrovin wrote:
Without marking the published key as obsolete, downgrade attack is
possible, because attacker can still use a weaker key to spoof
signature.
пятница, 07 апреля 2017г., 02:58 +03:00 от John Levine
jo...@taugh.com <mailto:jo...@taugh.com>:
1. produce 2 different DKIM-Signatures with 2 different selectors:
slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA
Of course.
2. add an additional field to either selector1 DKIM DNS record
(need to consult RFC if it's allowed) or to DKIM-Signature with
selector1 (it's allowed but probably is not enough to protect
against downgrade) to indicate the selector is legacy-only, e.g.
o=sha512/eccp256 to indicate this selector should be ignored if
verifier supports sha-512 and
eccp256.
No. If the verifier is smart enough to understand new algorithms, it
is smart enough to figure out which signature to prefer. Also keep
in mind that the legacy crypto is sha256/rsa1024 which is plenty
strong for the forseeable future.
R's, John
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
