Subject: [saag] code points for brainpool curves for DNSSEC

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

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: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Dec 2015 18:10:04 +0000

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

I am strongly opposed.  DNSSEC has no opportunity to "negotiate"
algorithms.  For DNSSEC, we do need strong algorithms, but the
*fewer* the better.  Fragmenting the DNS by algorithm would be a
very poor outcome, as would forcing every domain to publish
"kitchen-sink" DNSKEY RRsets.

IMHO we already have too many DNSSEC algorithm ids (some of which
are not that strong and should be deprecated), however once the
CFRG curves are standardized, these IMHO should be the *only* ones
to get new DNSSEC algorithm ids, and some of the older ones need
to start being phased out.

    https://www.ietf.org/mail-archive/web/saag/current/msg06808.html

-- 
	Viktor.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Dec 2015 21:22:59 +0100

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

Interesting that unimplemented state-sponsored crypto is pushed through
while widely deployed academic crypto is delayed year after year.

Allow me to suggest that draft-schmidt-brainpool-dnssec is at least not
published before the EdDSA-based DNSSEC documents are published, as
doing so would conflict with the ongoing IETF-process around setting up
the Curdle WG and getting the DNSSEC EdDSA documents published.

/Simon

---

From: Brian Smith <[email-masked]>
Date: Wed, 9 Dec 2015 10:31:15 -1000

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

Perhaps first we should establish some consensus regarding the concerns
raised in http://bada55.cr.yp.to/brainpool.html. In particular, the authors
of that web page have convinced me the whole principle behind
Brainpool-using randomness to remove doubt on the trustworthiness of the
curve parameters--is at odds with the actual results.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Yoav Nir <[email-masked]>
Date: Wed, 9 Dec 2015 23:06:06 +0200

Hi, Simon

> On 9 Dec 2015, at 10:22 PM, Simon Josefsson <[email-masked]> wrote:
> 

Nothing is getting pushed through here, unlike the GOST case. You, me and anyone can write a draft for DNSSEC signatures by XOR-ing the RR with the string “ROT-13” repeated as many times as necessary and submit it to the RFC editor just as the Brainpool people did. We would get the same result: the document would be sent to the IESG for conflict review.

Publishing this draft does not hinder us from publishing an EdDSA draft. There are, however, several good arguments against this:

 1. Victor’s argument: having too many algorithms means that either your resolver supports all of them, or there are some domains that you can’t verify. We don’t want to fragment the secure DNS as that would diminish its value and hurt interoperability, forcing resolvers to revert to the insecure DNS. This hurts the mission of the IETF to make the Internet better.

 2. The IANA registry is 8-bit, making this a scarce resource. It should not be wasted on algorithms that are not likely to see a lot of use.

 3. The Brainpool curves do not offer any advantages over existing signature schemes unless you believe that the NIST curves are back-doored. I haven’t heard any reasonable claim that this is so. EdDSA will provide a performance advantage Brainpool? Not so much.

While I believe, like you and Victor that having DNSSEC signatures using Brainpool is a bad idea, I am not sure if blocking this RFC is the right way for the IETF to discourage this. The goal, though, is laudable.

Yoav

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 09 Dec 2015 22:34:28 +0100

>     https://www.ietf.org/mail-archive/web/saag/current/msg06808.html

I unequivocally agree. See also concerns raised by Simon Josefsson.

Aaron

---

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.

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Dec 2015 15:27:35 +0900

> try follow up on the saag list if you can.

does the ietf have a chutzpah award?

what viktor said

randy

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 10 Dec 2015 10:15:51 +0100

I have nothing to add to what Ólafur wrote below. I agree with his statement.

   Patrik

On 10 Dec 2015, at 1:33, Ólafur Guðmundsson wrote:

> Stephen,
>
> Sorry for being so blunt below.
>
> The document totally content free as to why this makes any sense in an operational context.
> DNSSEC algorithms should not be given out lightly as there is a significant COST to deploy support for each additional algorithm.
>
> While I strongly support having better ECC algorithm that the currently specified curves, adding a new ones SHOULD take place via a performance oriented process.
> Thus I strongly advocate that this publication be held up until we can compare this curve with other curves being proposed.
>
> Background I'm currently fighting an multifaceted battle to have various entities adding support for ECDSAP256, specified over 3 years ago.
>
> Adding and deploying a new DNSKEY algorithm does not just require changes to
> -- DNS servers, libraries and resolvers.
>
> That is just the top of the iceberg,  but also to
> -  DNS provisioning systems, DNSSEC signing systems, DNS testing tools, - user interfaces for registrars, hosting providers, third party DNS operators, CDN's,  etc.
> - TLD and ccTLD policy documents, EPP implementations, plus in some cases security evaluations,
> - not to mention firewalls, network monitoring tools ....
> and number of other things I had no idea existed and majority of which is not maintained anymore.
>
> There are only so many times that one can get everyone's attention to upgrade DNS stuff, thus requiring the change process to be run should not be taken lightly.
> If on the other hand if the editors are only interested in vanity algorithm assignment without any deployment then ...........
>
> Olafur
>
>
> On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell <[email-masked]>
> wrote:
>
>>
>>
>>
>> -------- 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,
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2015 09:39:17 +0000

Thanks all, that's sufficient feedback for me to propose to the
IESG that we return a "potentially disrupts, so please do not
publish now" 5742 response so I have proposed that to the IESG.
Additional discussion of reasons to not do this allocation now
may therefore be redundant.

Discussion of what to do in future is still welcome, and if
that doesn't happen I at least will raise the issue on the list
for the in-formation curdle WG. [1]

The text I've proposed is at [2], feel free to suggest edits,
but that can be done offlist.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-curdle/
[2]
https://datatracker.ietf.org/doc/conflict-review-schmidt-brainpool-dnssec/

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 9 Dec 2015 22:33:08 -0200

Stephen,

The document totally content free as to why this makes any sense in an
operational context.
DNSSEC algorithms should not be given out lightly as there is a significant
COST to deploy support for each additional algorithm.

While I strongly support having better ECC algorithm that the currently
specified curves, adding a new ones SHOULD take place via a performance
oriented process.
Thus I strongly advocate that this publication be held up until we can
compare this curve with other curves being proposed.

Background I'm currently fighting an multifaceted battle to have various
entities adding support for ECDSAP256, specified over 3 years ago.

Adding and deploying a new DNSKEY algorithm does not just require changes
to
-- DNS servers, libraries and resolvers.

That is just the top of the iceberg,  but also to
-  DNS provisioning systems, DNSSEC signing systems, DNS testing tools,
 - user interfaces for registrars, hosting providers, third party DNS
operators, CDN's,  etc.
 - TLD and ccTLD policy documents, EPP implementations, plus in some cases
security evaluations,
 - not to mention firewalls, network monitoring tools ....
 and number of other things I had no idea existed and majority of which is
not maintained anymore.

There are only so many times that one can get everyone's attention to
upgrade DNS stuff, thus requiring the change process to be run should not
be taken lightly.
If on the other hand if the editors are only interested in vanity algorithm
assignment without any deployment then ...........

Olafur