Subject: [Curdle] Fwd: code points for brainpool curves for DNSSEC

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2015 18:01:00 +0000

-------- Forwarded Message --------
Subject: code points for brainpool curves for DNSSEC
Date: Wed, 9 Dec 2015 18:00:18 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]

Hiya,

The brainpool folks have written an I-D [1] that they are pushing
through the rfc editor's independent stream. [2]

That I-D wants to register code points for using their curves for
DNSSEC.

For documents that come through the independent stream, the IESG
does an RFC 5742 [3] conflict review. The purpose of that review
is to check that the RFC doesn't conflict with ongoing work in
the IETF.

If you have thoughts on this, please let me know before Dec 17th.
I'll forward this to the dnsop, cfrg and curdle mailing lists
to check there too. Apologies if you get >1 copy of this. Please
try follow up on the saag list if you can.

Thanks,
Stephen.

[1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec
[2] https://www.rfc-editor.org/pubprocess/
[3] https://tools.ietf.org/html/rfc5742

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2015 16:41:59 -0500

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.