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