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 <dmarc-boun...@ietf.org> on behalf of Vladimir Dubrovin <dubro...@corp.mail.ru> Date: Friday, April 7, 2017 at 10:24 AM To: Scott Rose <scott.r...@nist.gov>, "dmarc@ietf.org" <dmarc@ietf.org> 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: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> To: Scott Rose <scott.r...@nist.gov><mailto:scott.r...@nist.gov> 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.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc