Objections so far * The approach is dated (not fast prime rigid) and the randomness isn't established to be rigid. * DNSSEC requires a single algorithm for interop * The code points are 8 bit and thus scarce * We should do Curdle first.
I am opposed to Brainpool for all the above and in addition, I am opposed because the biggest problem with ECC has been too many choices. If people are given one choice, they will do it. If they have two then they will probably do both. With ECC we were given 16 choices by NIST and then the same again from Brainpool and a few other folks. So what a lot of people did was to conclude ECC wasn't mature enough to implement right now and adopted a wait-and-see approach. Brainpool was a good idea at the time it was proposed but the world moved on and the effort is counterproductive now. Since ACME and Lets Encrypt have been proposed, we can hopefully get away from the bogus idea that the mission of DNSSEC was 'free' certs. The utility of DNSSEC lies in being able to sign and distribute security policy information so that applications can achieve 'secure on first contact' security rather than 'secure after first contact'. For that to work, DNSSEC has to be using the same set of algorithms that the applications are using. The other area we might potentially leverage DNSSEC is to allow encryption of the initial exchange in a TLS/2 by putting a 'host key' in the DNS. This would allow the SNI and certificate exchanges to be encrypted. For this to be practical, DNSSEC and TLS have to converge on the same algorithm and curve.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
