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

From: Scott Rose <[email-masked]>
Date: Thu, 6 Apr 2017 13:32:27 -0400

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: 	[email-masked]
To: 	Scott Rose <[email-masked]>

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
Status:         https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/
Htmlized:       https://tools.ietf.org/html/draft-srose-dkim-ecc-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00

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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Vladimir Dubrovin <[email-masked]>
Date: Fri, 7 Apr 2017 00:28:10 +0300

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

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.
>
> URL:           
> https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-00.txt
> Htmlized:      
> https://datatracker.ietf.org/doc/html/draft-srose-dkim-ecc-00
>
>
> Abstract:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: Brandon Long <[email-masked]>
Date: Thu, 6 Apr 2017 15:00:24 -0700

We also recently discussed having a new DKIM rfc revision to create a
registry of algorithms and allowed key lengths, so that we wouldn't need to
rev the rfc every time they changed, and also to incorporate into arc,
which will use similar signatures.

Discussed a bit here:
https://www.ietf.org/mail-archive/web/dmarc/current/msg03436.html

Brandon

On Thu, Apr 6, 2017 at 2:28 PM, Vladimir Dubrovin <[email-masked]>
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
> I can imagine few more ways to resolve compatibility issues, but this one
> seems to be a simplest.
>
>
> to migrate to ECDSA or looking for algorithm agility that doesn't involve
> using SHA-1.
>
> To:     Scott Rose <[email-masked]> <[email-masked]>
>
>
>

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2017 23:55:40 -0000

In article <[email-masked]> you write:
>anymore.

At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM
with a new crypto algorithm and/or a more compact key representation
(put the key in the signature and put a hash of it in the DNS.)

Reaction was positive, people told me to write a proposed charter,
which starts here:

https://www.ietf.org/mail-archive/web/dispatch/current/msg06701.html

Also see:

https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2017 23:58:15 -0000

>slector1  with SHA-1 + RSA and selector2 one with  SHA-512 + ECDSA

Of course.

>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

---

From: Brandon Long <[email-masked]>
Date: Fri, 7 Apr 2017 00:28:40 -0700

Should we add more hash algorithms?

Also, I'm very unclear of the benefit of the fp versions, adding nearly 400
bytes per signature to the message seems expensive, and in the arc case, an
extra 800 bytes per hop (nearly doubling the size of each hop) seems like
an odd compromise.  Maybe I'm being silly.

I know that many of the sending providers now provide the DNS directly for
DKIM keys, and so the end user domain only needs to put in CNAMEs, given
the need to rotate keys, that may be the more sane thing than expecting
anyone to routinely copy the large keys into DNS.

Brandon

---

From: Vladimir Dubrovin <[email-masked]>
Date: Fri, 07 Apr 2017 12:06:56 +0300

---

From: Federico Santandrea <[email-masked]>
Date: Fri, 7 Apr 2017 12:18:52 +0200

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
> [email-masked] <mailto:[email-masked]>:
>
>> 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.
>
>  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
>

---

From: Scott Rose <[email-masked]>
Date: Fri, 7 Apr 2017 08:09:23 -0400

On 04/06/2017 05:28 PM, Vladimir Dubrovin wrote:

> are little chances to succeed the older but more compatible protocols 
> in nearest future.  The possible (but probably not the best one) 
> solution is:
>
> 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.
>
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

>> told to migrate to ECDSA or looking for algorithm agility that 
>> doesn't involve using SHA-1.
>>

---

From: Scott Rose <[email-masked]>
Date: Fri, 7 Apr 2017 08:17:11 -0400

Ok - nice to know I'm not the only one thinking this (means I'm not 
totally crazy).  I'm willing to drop my draft and just contribute/review 
this one. There is no reason to have multiple drafts trying to do the 
same thing.

Scott

---

From: Vladimir Dubrovin <[email-masked]>
Date: Fri, 7 Apr 2017 17:24:03 +0300

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 пишет:
>> (it's allowed but probably is not enough to protect against
>> downgrade) to indicate the selector is legacy-only, e.g.
>> verifier supports sha-512 and eccp256.
>>
> 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
>
>

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 7 Apr 2017 15:12:07 +0000

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 <[email-masked]> on behalf of Vladimir Dubrovin <[email-masked]>
Date: Friday, April 7, 2017 at 10:24 AM
To: Scott Rose <[email-masked]>, "[email-masked]" <[email-masked]>
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.

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.

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: [email-masked]<mailto:[email-masked]>
To:     Scott Rose <[email-masked]><mailto:[email-masked]>

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:

---

From: "John R Levine" <[email-masked]>
Date: 7 Apr 2017 11:29:41 -0400

> Should we add more hash algorithms?

As far as I know SHA-256 is still adequate for the forseeable future, but 
I expect the crypto experts will weigh in.  Ditto whether we really need 
three new algorithms since the more ways there are to sign, the more ways 
there are to have broken signatures.  I'd rather pick a single ECC 
algorithm that is mathematically respectable and widely implemented.

> an odd compromise.  Maybe I'm being silly.

This is only to work around the 256 byte TXT provisioning bugs.  If your 
provisioning works, you can keep publishing keys the current way.

I probably could be persuaded that if we're going to tell people to update 
their DKIM and ARC signing/verifying libraries, we should just tell them 
to add ECC crypto and the key length problems go away forever.

R's,
John

---

From: Peter Goldstein <[email-masked]>
Date: Fri, 7 Apr 2017 08:33:40 -0700

John,

Really glad to see this.

Does this initiative include an intention to update the cryptographic
guidance from RFC 6376 sections 3.3 and 3.3.3 ?  The proposed charter
speaks of adding new algorithms, but doesn't discuss deprecating/removing
old ones.

Some specific concerns are:

1. Expressly forbidding RSA keys < 1024 bits in size - While the fact that
some major receivers ignore such keys has made this a de facto standard, it
would be good for the RFCs to reflect best practice here.  And as we saw
with the ARC discussion, using the DKIM spec as a reference can
inadvertently result in new standards supporting known insecure practices.

2. Eliminating SHA-1 - Even at the time of publication RFC 6376 recommended
that signers avoid the use of SHA-1.  Despite this, a simple check of my
inbox shows that quite a few senders - including a number of large,
sophisticated ESPs - still use SHA-1 in preference to SHA-256.  While the
recent developed PDF collision attack against SHA-1 is not entirely on
point, it seems to be further evidence that SHA-1 should not be used.  And
given the widespread support for SHA-256, this seems like it's mostly a
configuration issue for senders.

If these items don't belong in the charter for the new group, do they have
a different natural home for discussion?

Thanks.

Best,

Peter

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: "John R Levine" <[email-masked]>
Date: 7 Apr 2017 11:34:08 -0400

> Ok - nice to know I'm not the only one thinking this (means I'm not totally 
> crazy).  I'm willing to drop my draft and just contribute/review this one. 
> There is no reason to have multiple drafts trying to do the same thing.

No, don't, we can moosh them together.  I don't know much about elliptic 
crypto and could use some advice about which algorithms are widely 
implemented and which are likely to be used for a long time.

>> https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 7 Apr 2017 11:48:22 -0400

> speaks of adding new algorithms, but doesn't discuss deprecating/removing

We haven't decided yet.  I'd think that'd be something DCRUP could 
consider.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 7 Apr 2017 16:26:01 -0000

>mail fail verification, or risk some invalid back-dated mail pass

Good lord, no.  That's why DKIM has key rotation.

R's,
John

---

From: Terry Zink <[email-masked]>
Date: Fri, 7 Apr 2017 18:39:28 +0000

One reason transitions are difficult because of implementation and deprecation ambiguity. If there’s no reason to move other than best practice, then no one will (or not enough will move).

Maybe we can build timelines into the updates. By Jan 1, 2019, receivers SHOULD (MUST?) no longer support the following key sizes or algorithms. That way, if anyone complains that a particular DKIM-signature is not considered valid, we can always say it’s RFC non-compliant.

For example, for supported TLS ciphers, Microsoft Office 365 publishes what algorithms are supported, along with timelines for deprecation: https://technet.microsoft.com/en-us/library/dn569286.aspx. If senders have problems with TLS connections, we point them to that documentation. Not everyone reads the documentation, but it is the way we advertise to the world what we do and don’t support.

--Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Peter Goldstein
Sent: Friday, April 7, 2017 8:34 AM
To: John Levine <[email-masked]>
Cc: dmarc <[email-masked]>; Vladimir Dubrovin <[email-masked]>
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

John,

Really glad to see this.

Does this initiative include an intention to update the cryptographic guidance from RFC 6376 sections 3.3 and 3.3.3 ?  The proposed charter speaks of adding new algorithms, but doesn't discuss deprecating/removing old ones.

1. Expressly forbidding RSA keys < 1024 bits in size - While the fact that some major receivers ignore such keys has made this a de facto standard, it would be good for the RFCs to reflect best practice here.  And as we saw with the ARC discussion, using the DKIM spec as a reference can inadvertently result in new standards supporting known insecure practices.

2. Eliminating SHA-1 - Even at the time of publication RFC 6376 recommended that signers avoid the use of SHA-1.  Despite this, a simple check of my inbox shows that quite a few senders - including a number of large, sophisticated ESPs - still use SHA-1 in preference to SHA-256.  While the recent developed PDF collision attack against SHA-1 is not entirely on point, it seems to be further evidence that SHA-1 should not be used.  And given the widespread support for SHA-256, this seems like it's mostly a configuration issue for senders.

If these items don't belong in the charter for the new group, do they have a different natural home for discussion?

Thanks.

Best,

Peter
[https://t.yesware.com/t/d51e63df483c4f1bf32b47229814ba3f3b13fe44/32a480a2a05d0065fe5ce922b6d2d032/spacer.gif][http://t.yesware.com/t/d51e63df483c4f1bf32b47229814ba3f3b13fe44/32a480a2a05d0065fe5ce922b6d2d032/spacer.gif]

Of course.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 7 Apr 2017 18:58:12 +0000

This was forced by the web browser providers for SHA1. It’s being forced by the PCI DSS standard for use of TLS1.0. So it clearly ispossible.

Mike

From: dmarc [mailto:[email-masked]] On Behalf Of Terry Zink
Sent: Friday, April 07, 2017 2:39 PM
To: dmarc
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

--Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Peter Goldstein
Sent: Friday, April 7, 2017 8:34 AM
To: John Levine <[email-masked]<mailto:[email-masked]>>
Cc: dmarc <[email-masked]<mailto:[email-masked]>>; Vladimir Dubrovin <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

John,

Really glad to see this.

Thanks.

Best,

Peter

Of course.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Apr 2017 20:04:12 -0700

> speaks of adding new algorithms, but doesn't discuss deprecating/removing

As John said, DCRUP could do this.

> inadvertently result in new standards supporting known insecure practices.

I'm not sure about forbidding, but expressly deprecating by removing
mandatory support would certainly be allowed.

> 2. Eliminating SHA-1 - Even at the time of publication RFC 6376
> recommended that signers avoid the use of SHA-1.  Despite this, a simple
> check of my inbox shows that quite a few senders - including a number of
> large, sophisticated ESPs - still use SHA-1 in preference to SHA-256.
> While the recent developed PDF collision attack against SHA-1 is not
> entirely on point, it seems to be further evidence that SHA-1 should not be
> used.  And given the widespread support for SHA-256, this seems like it's
> mostly a configuration issue for senders.
>

Same issue, because the installed base isn't going to update itself quickly
even if we really want it to.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 8 Apr 2017 08:45:04 -0400

> possible, because attacker can still use a weaker key to spoof 

If you know how to spoof a sha256/rsa1024 signature, I know a lot of 
people who would like to talk to you.

Other than that, please review RFC 6376.  Each signing algorithm has a 
separate key -- if you don't trust an algorithm, don't publish a key for 
it.

R's,
John

---

From: Vladimir Dubrovin <[email-masked]>
Date: Sat, 8 Apr 2017 17:30:06 +0300

If you believe sha256/rsa1024 are forever, there is no actual need for
draft-srose-dkim-ecc-00.txt.  The problem is, this need may arrive at
some time, and this time is hardly predictable. There is also possible
there may be the need to roll back ECC and mark it as insecure at some
point of time. So one would expect from the standard:

1. To be compatible with existing implementation to allow to implement
the standard ASAP if required and yet to allow the use of the strongest
up-to-date algorithms
2. To be self updating, to avoid the need to produce the new DKIM
standard each time encryption standards are changing. It may be achieved
by e.g. referencing to IANA TLS SignatureAlgorithm/HashAlgorithm registry.

08.04.2017 15:45, John R Levine пишет:
> separate key -- if you don't trust an algorithm, don't publish a key
> for it.
>
> R's,
> John
>
>>
>>>> (need to

-- 
Vladimir Dubrovin
@Mail.Ru

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2017 19:49:45 -0000

>point of time. So one would expect from the standard: ...

One can expect whatever one wants, but as should be self-evident to
anyone who's read RFC 6376, it's not going to happen.  As Murray
noted, signers put whatever signatures they want on the messages, and
verifiers accept whatever signatures they find acceptable.

If verifiers stop accepting signatures with a weak algorithm it'll be
because they stop accepting them, not because of a "this is a weak
signature" flag.  One of the things DCRUP may do is to recommend that
they stop accepting signatures with SHA-1 hashes or 512 bit RSA keys.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2017 19:51:54 -0000

>Maybe we can build timelines into the updates. By Jan 1, 2019, receivers SHOULD (MUST?) no longer support the
>following key sizes or algorithms. That way, if anyone complains that a particular DKIM-signature is not
>considered valid, we can always say it’s RFC non-compliant.

The IETF historically hasn't done that.  Would would make a difference
is if some of the big gorillas (you know who you are) said you'll stop
accepting weak signatures as of some date, then actually do it.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2017 20:11:10 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-

True, but it's important to note that we don't require anyone to sign
with weak keys. A key record in the DNS can contain "h=sha256" to say
no SHA1 signatures accepted.  I've set my key records like that for
years.

R's,
John