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

["MH Michael Hammer (5304)" <[e-mail]>]

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:[e-mail]] 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:[e-mail]] On Behalf Of Peter Goldstein
Sent: Friday, April 7, 2017 8:34 AM
To: John Levine <[e-mail]<mailto:[e-mail]>>
Cc: dmarc <[e-mail]<mailto:[e-mail]>>; Vladimir Dubrovin <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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