Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

[Federico Santandrea <[e-mail]>]

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
> [e-mail] <mailto:[e-mail]>:
>
>> 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
>