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
