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

[John Levine]

In article <363edd8b-2654-4d81-ad41-d355599d3...@att.com> you write:
>-=-=-=-=-=-
>Right now we require support for two types of keys: a weak one (sha1) and a 
>strong one (sha256).

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

>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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

>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: ...

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Vladimir Dubrovin]

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 пишет:
>> Without marking the published key as obsolete, downgrade attack is
>> possible, because attacker can still use a weaker key to spoof
>> signature.
>
> 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
>
>>
 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.


-- 
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

Without marking the published key as obsolete, downgrade attack is 
possible, because attacker can still use a weaker key to spoof 
signature.


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




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.


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Fri, Apr 7, 2017 at 8:33 AM, Peter Goldstein  wrote:

> 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.
>

As John said, DCRUP could do this.


> 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.
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[MH Michael Hammer (5304)]

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:dmarc-boun...@ietf.org] 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

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:dmarc-boun...@ietf.org] On Behalf Of Peter Goldstein
Sent: Friday, April 7, 2017 8:34 AM
To: John Levine mailto:jo...@taugh.com>>
Cc: dmarc mailto:dmarc@ietf.org>>; Vladimir Dubrovin 
mailto:dubro...@corp.mail.ru>>
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.

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
[https://t.yesware.com/t/d51e63df483c4f1bf32b47229814ba3f3b13fe44/32a480a2a05d0065fe5ce922b6d2d032/spacer.gif][http://t.yesware.com/t/d51e63df483c4f1bf32b47229814ba3f3b13fe44/32a480a2a05d0065fe5ce922b6d2d032/spacer.gif]

On Thu, Apr 6, 2017 at 4:58 PM, John Levine 
mailto:jo...@taugh.com>> wrote:
>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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Terry Zink]

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:dmarc-boun...@ietf.org] On Behalf Of Peter Goldstein
Sent: Friday, April 7, 2017 8:34 AM
To: John Levine 
Cc: dmarc ; Vladimir Dubrovin 
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.

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
[https://t.yesware.com/t/d51e63df483c4f1bf32b47229814ba3f3b13fe44/32a480a2a05d0065fe5ce922b6d2d032/spacer.gif][http://t.yesware.com/t/d51e63df483c4f1bf32b47229814ba3f3b13fe44/32a480a2a05d0065fe5ce922b6d2d032/spacer.gif]

On Thu, Apr 6, 2017 at 4:58 PM, John Levine 
mailto:jo...@taugh.com>> wrote:
>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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article <30f3baa9-f13b-91b4-c931-a2fb68582...@diennea.com> you write:
>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.

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

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

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.


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


R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

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.




Scott


On 04/06/2017 07:55 PM, John Levine wrote:

In article  you write:

This may be of interest to this group, as there isn't an active DKIM WG
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





Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Peter Goldstein]

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

On Thu, Apr 6, 2017 at 4:58 PM, John Levine  wrote:

> >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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>



-- 


[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

pe...@valimail.com
+1.415.793.5783
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John R Levine]

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.



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.


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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[HANSEN, TONY L]

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  on behalf of Vladimir Dubrovin 

Date: Friday, April 7, 2017 at 10:24 AM
To: Scott Rose , "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 <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://to

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

[Vladimir Dubrovin]

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
>>> To: Scott Rose 
>>>
>>>
>>>
>>> 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
>>>
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>>
>> -- 
>> Vladimir Dubrovin
>> @Mail.Ru
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladim

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

[Scott Rose]

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


On 04/06/2017 07:55 PM, John Levine wrote:

In article  you write:

This may be of interest to this group, as there isn't an active DKIM WG
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


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

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



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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



--
Vladimir Dubrovin
@Mail.Ru


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Federico Santandrea]

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
jo...@taugh.com :


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



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Vladimir Dubrovin]

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  jo...@taugh.com :

>>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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

>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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article  you write:
>This may be of interest to this group, as there isn't an active DKIM WG 
>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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Brandon Long]

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 
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
>
> 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
> To: Scott Rose  
>
>
>
> 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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
>
> --
> Vladimir Dubrovin
> [image: @Mail.Ru]
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Vladimir Dubrovin]

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.
>
> 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
> To: Scott Rose 
>
>
>
> 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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


-- 
Vladimir Dubrovin
@Mail.Ru
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc