Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
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
>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
>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
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
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
