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 <jo...@taugh.com<mailto:jo...@taugh.com>>
Cc: dmarc <dmarc@ietf.org<mailto:dmarc@ietf.org>>; Vladimir Dubrovin 
<dubro...@corp.mail.ru<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 
<jo...@taugh.com<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