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

On Thu, Apr 6, 2017 at 4:58 PM, John Levine <johnl@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
>

-- 

[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com
+1.415.793.5783