Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

From: Ondřej Surý <[email-masked]>
Date: Sun, 19 Jul 2020 09:52:39 +0200

I just want to point out, that I am certainly not overthinking this with my implementors hat.
The RFC and code-point puts pressure on the DNS vendors to actually implement this
„because there’s RFC“. The whole reason for standardization is that there’s interoperatibility
between the implementations - and just giving the code points without implementing this
hardly fulfills that requirement.

Sure, I can ignore the new GOST code point in BIND 9, but that becomes harder when
either one of the other open source implementations or one of the big DNS silos will actually
do the implementation.

So, it’s definitively not „just giving the code point“, it has implications for some of us.

Ondrej
--
Ondřej Surý (He/Him)
[email-masked]

> On 18 Jun 2020, at 17:36, Jim Reid <[email-masked]> wrote:
> 
> I think we’re over-thinking this. Just issue new code point(s) for the new algorithm(s) and be done with it.
> 
> IMO there’s no need for the WG or the IETF to make any statements about the suitability of the underlying crypto used for optional signing and validation. That’s largely a matter for those who use these algorithms. Higher-level concerns about the crypto’s suitability should only come into play whenever an algorithm is a MUST/SHOULD recommendation in a standards-track RFC.
> 
> Maybe we need an RFC6895-like process for maintaining this IANA registry, like we have for RRtype codes?
>

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2020 11:25:33 -0400

>hardly fulfills that requirement.

I thought that in situations like this, the reason to assign the code
point is so that other people don't use it for something else.

ECC-GOST has been number 12 for a decade. I don't get the impression
it's widely implemented, but has it caused any problems?

---

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Jul 2020 17:38:38 +0000

On Sunday, 19 July 2020 07:52:39 UTC Ondřej Surý wrote:
> I just want to point out, that I am certainly not overthinking this with my
> implementors hat. The RFC and code-point puts pressure on the DNS vendors
> to actually implement this „because there’s RFC“. ...

i'm going to want to be able to validate signatures generated in russia by 
russians of russian dns zones. so my pressure on my implementors will not be 
because there's an RFC, but rather, because there are keys and signatures.

(i've dropped my .su domain, but i may get another some day, so it's possible 
i will want to be able to generate signatures using russian crypto, also.)

in other words i'm agreeing with ondrej on this -- it's a standard not just a 
code point reservation.

the thing we live on is round.

-- 
Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Jul 2020 21:09:26 -0400 (EDT)

>> to actually implement this „because there’s RFC“. ...

If we are talking about Nation State ciphers, the pressure is on them to
submit code to get it supported. Whether it is in openssl or bind or
what not.

> the thing we live on is round.

Indeed. As much as I also want to limit the number of algorithms because
most Nation States ones will never see real deployment, we cannot really
prevent them from trying to get a real deployment.

If someone from Europe or North America would come up with another
algorithm, I'd be more tempted to say no than if Russia or China
would come to ask for one.

Paul