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

["HANSEN, TONY L" <[e-mail]>]

Right now we require support for two types of keys: a weak one (sha1) and a strong one (sha256).

Rolling out a new type of key should include requiring signers to ditch the weak sha1 key. But you still have a strong sha256 key to use along with the new key.

Any examples showing compatibility with multiple keys should use a sha256 key in the example and not a sha1 key.

                Tony Hansen

From: dmarc <[e-mail]> on behalf of Vladimir Dubrovin <[e-mail]>
Date: Friday, April 7, 2017 at 10:24 AM
To: Scott Rose <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt


And again: the problem here is not in the signature, it's in key published. If you publish both weak  and strong keys, attacker doesn't need to exploit the stronger key, he can exploit weak key, it doesn't matter if you use the strong one if the weak key is also valid. Attacker will generate single DKIM-Signature by using the comproised weak key. The fact you are ussing the strong one adds nothing to security in this case. There is no way for you to indicate you use the stronger one unless you indicate it with the key itself. So, if you keep the weak key published for compatibility, somehow you must indicate you are using it for compatibility purposes only to prevent verifiers from acepting the messages signed with weak key only if it's not accomplished by a stronger signature.


07.04.2017 15:09, Scott Rose пишет:
On 04/06/2017 05:28 PM, Vladimir Dubrovin wrote:



Hello Scott,

it may be good to cover compatibility issues, because otherwise there are little chances to succeed the older but more compatible protocols in nearest future.  The possible (but probably not the best one) solution is:

1. produce 2 different DKIM-Signatures with 2 different selectors: slector1  with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA
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.

Legacy verifier has valid DKIM-Signature with sha1+rsa
Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA
Something similar was proposed in the DANE WG, but was not included because it isn't up to the sender to tell the receiver which algorithms to support - the receiver (likely) has its own list of approved or preferred algorithms from which to do validation.  Some text could be added to the validation section about how validators should select their strongest preferred algorithm, etc. but not specify "legacy" algorithms unless there is clear consensus to get rid of it for DKIM.

Scott



I can imagine few more ways to resolve compatibility issues, but this one seems to be a simplest.


06.04.2017 20:32, Scott Rose пишет:

This may be of interest to this group, as there isn't an active DKIM WG anymore.  This is my first attempt to produce a draft about defining new digital algorithms for DKIM. I'm trying to keep this short i.e. only define a few IANA registry entries and that's it.

I'm trying to head off a potential issue for organizations that are told to migrate to ECDSA or looking for algorithm agility that doesn't involve using SHA-1.

Comments welcome and needed. Including being told this isn't needed (though I think it might be).

Scott Rose

NIST



-------- Forwarded Message --------
Subject:     New Version Notification for draft-srose-dkim-ecc-00.txt
Date:     Thu, 6 Apr 2017 10:26:43 -0700
From: [e-mail]<mailto:[e-mail]>
To:     Scott Rose <[e-mail]><mailto:[e-mail]>



A new version of I-D, draft-srose-dkim-ecc-00.txt
has been successfully submitted by Scott Rose and posted to the
IETF repository.

Name:        draft-srose-dkim-ecc
Revision:    00
Title:        Defining Elliptic Curve Cryptography Algorithms for use with DKIM
Document date:    2017-04-06
Group:        Individual Submission
Pages:        6
URL: https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dsrose-2Ddkim-2Decc-2D00.txt&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=vFmE9raRTIxbXEak4-hgk9df2r2UPPcPIK83ZW8FXn0&s=u3DO57uO5e3ygApJybATFvH_VvLqa1k1B_y5j3sJ_yI&e=>
Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dsrose-2Ddkim-2Decc_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=vFmE9raRTIxbXEak4-hgk9df2r2UPPcPIK83ZW8FXn0&s=Z2yXtybubR_Eik_riZbZ7FudjvxDt0DB5hyURMsMSdQ&e=>
Htmlized: https://tools.ietf.org/html/draft-srose-dkim-ecc-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsrose-2Ddkim-2Decc-2D00&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=vFmE9raRTIxbXEak4-hgk9df2r2UPPcPIK83ZW8FXn0&s=W7ZKcB1d7zGEbfkjooCgyJHI9KusRYVQCr9HsxZ_fr0&e=>
Htmlized: https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dsrose-2Ddkim-2Decc-2D00&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=vFmE9raRTIxbXEak4-hgk9df2r2UPPcPIK83ZW8FXn0&s=YjPPAFiEEUOOBIzrWP7rlPE2npGrBAwjic-PgiZg7t8&e=>


Abstract:
   DomainKeys Identified Mail (DKIM) uses digital signature to associate
   a message with a given sending domain.  Currently, there is only one
   cryptography algorithm defined for use with DKIM (RSA).  This
   document defines four new elliptic curve cryptography algorithms for
   use with DKIM.  This will allow for algorithm agility if a weakness
   is found in RSA, and allows for smaller key length to provide the
   same digital signature strength.