Re: [DNSOP] [saag] code points for brainpool curves for DNSSEC

[Phillip Hallam-Baker <[e-mail]>]

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.