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

From: Tim Wicinski <[email-masked]>
Date: Wed, 3 Jun 2020 17:07:03 -0400

All,

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.
We are looking for *explicit* support for adoption.

This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 15 June 2020

Thanks,
tim wicinski
DNSOP co-chair

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Jun 2020 17:17:23 -0400 (EDT)

> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis

I support adoption, willing to review and contribute txt.

Note, the DS in the example in section 4.1 seems to be using 5 as
the assigned number, but this should probably be a TBA2 for now :)

Unless, an early code point has already been assigned, and looking
at the iana table the next available value is indeed 5 :)

Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jun 2020 19:28:21 -0400

> We are looking for *explicit* support for adoption.

I support adoption.

Some background:
The authors of this has asked me to AD sponsor it, but I felt it was much
better to have it progress through the normal IETF / DNSOP process, and so
I asked them to bring it here, but my support for adoption should be viewed
like any other...

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Brian Dickson <[email-masked]>
Date: Wed, 3 Jun 2020 19:24:56 -0700

> We are looking for *explicit* support for adoption.
I support adoption, and am willing to review.

Brian

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 4 Jun 2020 11:47:21 +0300

Hello,

> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/

Being a co-author of this draft, I support adoption.

-- 
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 4 Jun 2020 11:51:04 +0300

Dear Paul,

> at the iana table the next available value is indeed 5 :)

Thanks for your support!

I had to define some values to provide relevant examples,
and 5 for digest is mentioned in the "IANA Considerations" section.

-- 
SY, Dmitry Belyavsky

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 15 Jun 2020 22:42:29 -0400

Thom 
As I have before stated in the past, adding new DNSSEC algorithm is bad for interoperability, 
I oppose the adoption of this document unless there are better reasons put forward why this algorithm is better than
the 4 ECC algorithms that have been standardized so far. 
Better in this case could be stronger, faster, better post-quantum resistance etc 

Also I want to point out this last call did not specify track so my opposition is against all tracks, at this point. 

Olafur

> On Jun 3, 2020, at 5:07 PM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> All,
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ <https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/>
>

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 16 Jun 2020 09:52:45 +0200

Hi,

I do not hold as strong position as Olafur here, but I concur that the document
needs much better rationale. There’s no rationale for adopting the new GOST
algorithm at the moment and I would especially like to hear why GOST 2012
should be standardized and EC-KCDSA (Korean) and ECGDSA (German)
should not.

I specifically think that we should only standardize algorithms recommended
by cfrg such as RFC 7748 or RFC 8439 (just example, not applicable).

I consider the previous GOST standardization for DNSSEC to be a fiasco.

I would also ask the WG to require a implementation report before we send
this to WGLC. The support for GOST family of algorithms varies between
the various crypto libraries. I found it problematic for the DNS vendors that
OpenSSL supports the algs only in form of OpenSSL engine, and that said
engine had last release in 2018. The project activity looks fine, but issues
like this[1] don’t exactly fill me with trust, but at least there’s an active maintainer
for the project.

As of the adoption - I am indifferent, the things I mentioned could be done
with or without WG adopting the document, but I think that the document
should not become a RFC (not even Informational) before the items I
mentioned are cleared.

1. https://github.com/gost-engine/engine/issues/91

Ondrej
--
Ondřej Surý
[email-masked]

> On 16 Jun 2020, at 04:42, Olafur Gudmundsson <[email-masked]> wrote:
> 
> 
> Thom
>> The draft is available here: https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/
>>

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 16 Jun 2020 09:54:43 -0400

All

On Tue, Jun 16, 2020 at 3:52 AM Ondřej Surý <[email-masked]> wrote:

> [...]

> this to WGLC.

As chair, this statement -  I can not stress this strongly enough -
determines
even the consideration of a Working Group Last Call.
(I would argue my position on this is stronger than Olafur's).

As chair, I'm very open to having the WG consider and possibly adopt,
technical
work such as this.  I have a *lower* bar for adopting than my co-chairs or
our
Area Director.

As chair, I purposely don't state the intended RFC track during the call
for adoption.
While I disagree with the authors in a percentage of adopted work, I feel
the
WG is very effective at providing guidance, and reasoning.  The chairs
listen
and consider these comments.

As chair, we have a very *high* bar for moving to WGLC.  Implementation
reports
are everything to myself (not speaking for my co-chairs, but I believe they
have
similar feelings).

I had been thinking about the outcome of this call for adoption, and was
going to
have a conversation with my co-chairs and Warren on my thoughts in the next
few
days.  Hearing these thoughts are very useful, and I can't thank you enough.

tim

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 16 Jun 2020 21:49:17 +0300

Dear Ondřej,

As we have different statuses for the algorithm, I don't think the CFRG
adoption is required.

I don't think there are good or bad time periods to adopt nation-wide
crypto profiles. For me, the difference between the GOST profile and
hypothetical Korean or German profile is close to zero, and if anybody
brings such a profile for standardization, I'd like to support it.

As we have different statuses for the algorithms, I don't think the CFRG
adoption is required.

Speaking about the implementation, I'll have to put on the hat of the GOST
engine maintainer. The open-source implementation of the GOST crypto is
available in OpenSSL (as engine), LibreSSL (being the part of the core),
and GnuTLS.

The project activity of the gost-engine is limited by the coordination of
the life circles between the Russian Standard body and OpenSSL. The issue
you refer to is backdated almost two years ago, and I have some (rather
vague, though) plans to make a new release as some improvements worth
backporting appeared recently and some more are expected.

On Tue, Jun 16, 2020 at 10:53 AM Ondřej Surý <[email-masked]> wrote:

> > I oppose the adoption of this document unless there are better reasons
> put forward why this algorithm is better than
> > Also I want to point out this last call did not specify track so my
> opposition is against all tracks, at this point.
> >
> > Olafur
> >
> >
> >
> >

-- 
SY, Dmitry Belyavsky

---

From: Василий Долматов <[email-masked]>
Date: Tue, 16 Jun 2020 22:11:15 +0300

Hello Ondrej,

> 16 июня 2020 г., в 10:52, Ondřej Surý <[email-masked]> написал(а):
> 
> 
> 
I do not think that _standartization_ was a fiasco.
The implementation - definitely was one.

That has an explanation, when RFC5933 was published, soon it was announced that
these algorithms will be superseded by new ones.
So, all implementors prefer not to realize the algorithms which will be defunct in three years 
(as was stated, in reality this intermediate period was prolonged and was more than five years).

Now, the situation is stable and the implementors are waiting for the standard to refer to.
> I would also ask the WG to require a implementation report before we send
I agree that WGLC will require working reference implementation. And we will go for that.
> The support for GOST family of algorithms varies between
> the various crypto libraries.
That problem has been noted also some time ago, and for TLS and IPSEC implementations with
GOST algorithms there is now independent test service provided, which allows to  test implementations
by different vendors for compatibility with current standards (list of RFCs checked is provided there).

When DNSSEC implementation wil go forward it will be added to this independent testbed
to give vendors and developers possibility to check compatibility with the standards,

dol@

---

From: Dick Franks <[email-masked]>
Date: Wed, 17 Jun 2020 08:00:00 +0100

Strength - equivalent to ECDSA p256, assuming no fundamental weakness in
the curve parameters.
The Net::DNS::SEC implementation of algorithm 12 verification involves an
algebraic transformation of ECC-GOST into a mathematically equivalent ECDSA
verification. Unless I am missing something, the same approach appears to
be feasible for GOST R34.10-2012 (256 bit).

Apart from a brief flowering in Verisign DNSSEC Analyser
<https://dnssec-debugger.verisignlabs.com/d1a12n1.rootcanary.net>,
algorithm 12 achieved almost no traction.
Implementers may have been discouraged by the mistake
<https://www.rfc-editor.org/errata/eid3768> in R34.10-2001 test parameters.

But there is also a timeliness issue here.  A GOST R34.10 revision appears
every 11 years or so, and is deprecated 5 years after adoption of its
successor.  Next revision ETA 2023.

The sunset date specified in GOST R34.10-2012 having already passed,
algorithm 12 should be marked N in the DNSSEC Algorithm Numbers
<http://www.iana.org/assignments/dns-sec-alg-numbers> registry.

Dick Franks
________________________

Dick Franks
________________________

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 18 Jun 2020 13:50:36 +1000

> brings such a profile for standardization, I'd like to support it.

I agree with Olafur on this.  The reason we standardize is so that we can have a single - ideally very small - set of algorithms that are widely implemented.  Because you want every one of those algorithms in every implementation.

In a system like the DNS, you can't really limit the people who might need to consume your signature, so the set of acceptable signing algorithms needs to be small.  Ideally you have just two: one that is established, and one that is new; or one using one technique and a backup using a different technique.

TLS has mostly gotten this part right.  We're much closer to the point of having just two in TLS 1.3.  There are a few algorithms that exist to address narrow application domains (IoT, *cough*), but at least you can make a case for TLS deployments in a closed environment.  For that case, TLS allows for codepoint allocation, but avoids an IETF recommendation for those algorithms.  I don't think that DNS needs that same capability; deciding based on whether algorithms are good for global system is the only relevant criterion.

If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I doubt it, but I don't have an opinion), then adoption to replace an existing algorithm would be fine.  That didn't happen last time, so that suggests it would be better for RFC 5933 to be deprecated entirely.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Jun 2020 03:53:55 +0000

ships are passing in the night on this topic. GOST is what the russian 
government has to use for its crypto. if GOST is not a standard, then the 
russian federation's government won't be using DNSSEC, or they'll do it with a 
pirated code point. neither of those is desirable and there's no third way.

IETF has not been ruled by good engineering for many years now. the rule for 
publication of a standards document now is, if you want to do "this thing", 
here is a way to do it interoperably.

even known-bad ideas get consensus sometimes. (including some of mine, fwiw.) 
there is nothing particularly bad about GOST. we cannot hold it back based on 
some long-dead ideal Internet System having minimum complexity.

i'm in favour of adoption, and will review.

vixie

---

From: S Moonesamy <[email-masked]>
Date: Thu, 18 Jun 2020 00:47:20 -0700

Hello,
>This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis

There is the following in Section 1: "Familiarity with DNSSEC and 
with GOST signature and hash algorithms is assumed in this 
document."  I am not familiar with the cryptographic aspects [1] of 
the GOST R 34.11-2012 to perform an adequate review of that standard.

The current draft is well-written.  It probably needs some work 
before it is ready for a Last Call.  I suggest consideration what to 
do about RFC 5933 given that the intended status of the document.

Regards,
S. Moonesamy

1. The Security Area Directors will likely ask whether the document 
was reviewed by the relevant research group.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jun 2020 06:41:50 -0700

On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson <[email-masked]> wrote:

> I agree with Olafur on this.  The reason we standardize is so that we can
> have a single - ideally very small - set of algorithms that are widely
> implemented.  Because you want every one of those algorithms in every
> implementation.
>
> In a system like the DNS, you can't really limit the people who might need
> to consume your signature, so the set of acceptable signing algorithms
> needs to be small.  Ideally you have just two: one that is established, and
> one that is new; or one using one technique and a backup using a different
> technique.
>
> TLS has mostly gotten this part right.  We're much closer to the point of
> having just two in TLS 1.3.  There are a few algorithms that exist to
> address narrow application domains (IoT, *cough*), but at least you can
> make a case for TLS deployments in a closed environment.  For that case,
> TLS allows for codepoint allocation, but avoids an IETF recommendation for
> those algorithms.  I don't think that DNS needs that same capability;
> deciding based on whether algorithms are good for global system is the only
> relevant criterion.
>
> If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I
> doubt it, but I don't have an opinion), then adoption to replace an
> existing algorithm would be fine.  That didn't happen last time, so that
> suggests it would be better for RFC 5933 to be deprecated entirely.
>

largely concur with MT and Olafur.

At a high level, additional algorithms create additional complexity
and interoperability issues. In some cases there are good reasons for
that (for instance, one algorithm is much faster than another),
however that does not appear to be the case here. In the past we were
often quite liberal about standardizing national algorithms but I
believe this was a mistake which created confusion about what
algorithms the IETF actually was encouraging people to use. In
addition to the factors that Martin notes, it created pressure on
implementations to add those algorithms.

I don't see any good argument for the IETF recommending that people
adopt this algorithm, which does not seem to be in any way clearly
superior to EdDSA and which would open the door to us recommending a
proliferation of other national algorithms which also don't seem to
have any real technical advantages. As MT says, the argument for
assigning a code point while not recommending the algorithm seems
weaker here because you want DNSSEC signed data to be universally
verifiable.

My preference would be to not publish this at all, but if it is to
be published, do so in a way that makes clear that the IETF is just
allocating the code point and does not recommend it.

-Ekr

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 18 Jun 2020 09:47:18 -0400

Eric

One of the reasons we've published 8624 was to offer usage recommendations,
and especially this table:

https://tools.ietf.org/html/rfc8624#page-5

I believe I saw that one of the authors mentioned earlier they are looking
to
do a -bis update, to update this table.

(But hear the rest of the message clearly)

tim

On Thu, Jun 18, 2020 at 9:42 AM Eric Rescorla <[email-masked]> wrote:

>> In a system like the DNS, you can't really limit the people who might
>> need to consume your signature, so the set of acceptable signing algorithms
>> If we all agree that GOST is superior to RSA (it probably is) and EdDSA
>> (I doubt it, but I don't have an opinion), then adoption to replace an

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jun 2020 07:09:40 -0700

> do a -bis update, to update this table.

Thanks for the pointer. And I suppose I could live with an Informational
RFC with a  NOT RECOMMENDED entry in this table.

-Ekr

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 18 Jun 2020 10:38:48 -0400

You are welcome Eric.  I've been referring to that table a lot recently,
and I keep forgetting it's not an IANA registry.

Thanks for the Information/NOT RECOMMENDED.

I'm realizing I should chat with the 8624 authors, because if the WG does
end up adopting
this, I'll want to have the table updated at the same time.

tim

On Thu, Jun 18, 2020 at 10:10 AM Eric Rescorla <[email-masked]> wrote:

>> I believe I saw that one of the authors mentioned earlier they are
>> looking to

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Jun 2020 14:47:56 +0000

Why is this WG considering making this document Standards Track instead of Informational? Also, why is the WG considering putting the document in our work stream at all? Can the WG can bring much value to the document itself? We do have lots of other things we are working on.

There is no procedural need for this document to be part of the DNSOP working group. In order for this algorithm to get an algorithm number from IANA, all that is needed is an RFC. National crypto algorithms is one of the common use cases for the Independent Stream in the RFC Series. Suggesting that the authors publish it there will take less time for all of us, will conceivably get it published as an RFC sooner, and fulfills the requirement for them to get their assignment from IANA.

--Paul Hoffman

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 18 Jun 2020 17:59:27 +0300

Dear Paul,

On Thu, Jun 18, 2020 at 5:48 PM Paul Hoffman <[email-masked]> wrote:

> Why is this WG considering making this document Standards Track instead of
> Informational? Also, why is the WG considering putting the document in our
> work stream at all? Can the WG can bring much value to the document itself?
> We do have lots of other things we are working on.
>
> There is no procedural need for this document to be part of the DNSOP
> working group. In order for this algorithm to get an algorithm number from
> IANA, all that is needed is an RFC. National crypto algorithms is one of
> the common use cases for the Independent Stream in the RFC Series.
> Suggesting that the authors publish it there will take less time for all of
> us, will conceivably get it published as an RFC sooner, and fulfills the
> requirement for them to get their assignment from IANA.
>

Unfortunately, Independent Stream is impossible for this document.

This document requires updates to 2 IANA registries:
Domain Name System Security (DNSSEC) Algorithm Numbers
(
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
)
has the "RFC Required" update policy

The 2nd registry
Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
(
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
)
has the "Standards Action" update policy

So it makes impossible to use the Independent Stream process.

-- 
SY, Dmitry Belyavsky

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 18 Jun 2020 18:01:01 +0300

Hi Paul,

> Why is this WG considering making this document Standards Track instead of Informational? Also, why is the
> WG considering putting the document in our work stream at all? Can the WG can bring much value to the
> document itself? We do have lots of other things we are working on.
> 
> There is no procedural need for this document to be part of the DNSOP working group. In order for this
> algorithm to get an algorithm number from IANA, all that is needed is an RFC. National crypto algorithms is
> one of the common use cases for the Independent Stream in the RFC Series. Suggesting that the authors
> publish it there will take less time for all of us, will conceivably get it published as an RFC sooner, and fulfills
> the requirement for them to get their assignment from IANA.

The draft is going to allocate a code point from the "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1). which has a "Standards Action" update policy.

It would be much easier if publication via ISE was possible.

Regards,
Valery Smyslov.

---

From: Joe Abley <[email-masked]>
Date: Thu, 18 Jun 2020 17:01:03 +0200

> Why is this WG considering making this document Standards Track instead of Informational? Also, why is the WG considering putting the document in our work stream at all? Can the WG can bring much v…

I think the question of the value the wg can bring is the important one.

In this case it seems unlikely that dnsop has the expertise to review this document to the depths of the crypto. The degree to which the advice for DNSSEC implementers is clear and unambiguous can surely be assessed without putting it through the working group machinery.

An individual submission will still require conflict review by the IESG and that will involve credible DNS people to express an opinion, so there will no doubt be some familiar faces from dnsop that are still involved in an individual capacity, but I think (as I think Paul infers above) that there is little benefit to adding this to the workload of the wg chairs and AD if we don't expect the document to benefit from corresponding levels of improvement.

For what it's worth if this was to proceed on the individual submission stream and if the authors needed independent reviewers to express an opinion as part of that process I'd happily put my hand up with a DNS perspective. I almost certainly can't help with the crypto.

The question of how dnsop tracks algorithms that exist and whether they are recommended or not is reasonably separate from whether this document should be published, I think.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Jun 2020 15:30:36 +0000

On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky <[email-masked]> wrote:
> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 <https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1>)

I had forgotten that the DS registry is "standards action". This document shows why that was a bad idea.

It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the DS registry "RFC required", like the other DNSSEC-related registries.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Jun 2020 16:34:15 +0100

> On 18 Jun 2020, at 16:30, Paul Hoffman <[email-masked]> wrote:
> 

+1

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Jun 2020 16:36:50 +0100

> On 18 Jun 2020, at 16:01, Joe Abley <[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: Paul Wouters <[email-masked]>
Date: Thu, 18 Jun 2020 12:13:23 -0400 (EDT)

On Thu, 18 Jun 2020, Eric Rescorla wrote:

> I believe I saw that one of the authors mentioned earlier they are looking to 
> Thanks for the pointer. And I suppose I could live with an Informational RFC with a  NOT RECOMMENDED entry in this table.

It would be very strange to introduce a new algorithm as NOT RECOMMENDED.
The weakest I think we should introduce something is as MAY.

The typical cycle of a new algorithm is MAY, SHOULD, MUST, SHOULD NOT,
MUST NOT (where NOT RECOMMENDED is really SHOULD NOT). For a less
successful algorithms it might go as MAY, SHOULD NOT, MUST NOT.

I also feel a little weird doing it as an INFORMATIONAL, but no one
outside the IETF really knows the difference for RFCs anyway.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Jun 2020 12:16:37 -0400 (EDT)

> It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the DS registry "RFC required", like the other DNSSEC-related registries.

I agree.

However, whether it is faster for the document, I don't know. The ISE
stream is currently very slow moving. Perhaps these documents could
flow faster than the two other ISE stream ones I am I'm tracking.

I'm fine with the RFCs being standard track.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jun 2020 09:23:49 -0700

> The weakest I think we should introduce something is as MAY.

The way that TLS has handled this is to have the registries have a column
called Recommended and we just mark things Y or N. This is slightly
different from RFC 2119 language.

It's not that uncommon to have new stuff introduced with Recommended = N.
In fact this is the likely outcome for the GOST cipher suites:
https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Jun 2020 12:36:37 -0400 (EDT)

On Thu, 18 Jun 2020, Eric Rescorla wrote:

> The way that TLS has handled this is to have the registries have a column called Recommended and we just mark things Y or N. This is slightly
> It's not that uncommon to have new stuff introduced with Recommended = N. In fact this is the likely outcome for the GOST cipher suites:

I don't see anything like that mentioned in the IANA Considerations
section? https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7

In fact, the table is specifically missing the Recommended column
required by the IANA Registry.

If we make a consistent decision regarding algorithm recommendations
IETF-wide, than I could agree with your approach. But I would like to avoid
different WGs doing slightly different things. I don't think DNSOP
(or TLS) should decide these things separately.

Perhaps SAAG could publish a generic guidance document on nation state
algorithms and their recommendations?

As a side not, in those Security Considerations I see:

    2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
    reasons for this restriction are that the 0-RTT data is not forward
    secret and is not resistant to replay attacks

It seems that the SHOULD NOT is really a very hard MUST NOT.

As another side note, would be nice to have a link to the IANA sections
updated in the IANA Considerations Section.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jun 2020 09:57:20 -0700

On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters <[email-masked]> wrote:

> > The way that TLS has handled this is to have the registries have a
> column called Recommended and we just mark things Y or N. This is slightly
> > It's not that uncommon to have new stuff introduced with Recommended =
> N. In fact this is the likely outcome for the GOST cipher suites:
> section?
> https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7
>

The relevant text is in 8447: https://tools.ietf.org/html/rfc8447#section-5

   Per this document, a "Recommended" column has been added to many of
   the TLS registries to indicate parameters that are generally
   recommended for implementations to support.  Adding a "Recommended"
   parameter (i.e., "Y") to a registry or updating a parameter to
   "Recommended" status requires Standards Action.  Not all parameters
   defined in Standards Track documents need to be marked as
   "Recommended".

As the GOST draft has an informational header and is not a TLS WG
item, I would expect any registration to have Recommended = N.

> required by the IANA Registry.

That seems like an omission but given the above, I expect IANA can handle
it.

> It seems that the SHOULD NOT is really a very hard MUST NOT.

It's not clear to me if GOST is any different than the existing TLS cipher
suites in this respect, but if not, then I'm not quite sure what the
rationale is here.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Thu, 18 Jun 2020 13:37:45 -0400

I support adoption of the document. To my perspective, holding code point
allocation is likely to result in non allocated code points being used
which represents a higher threat to interoperability than adding an
algorithm.
Standard track and MAY/OPTIONAL status seem reasonable to me

Yours,
Daniel

On Thu, Jun 18, 2020 at 12:58 PM Eric Rescorla <[email-masked]> wrote:

> The relevant text is in 8447:
> https://tools.ietf.org/html/rfc8447#section-5
>
> As the GOST draft has an informational header and is not a TLS WG item, I would expect any registration to have Recommended = N.
>
>
>

-- 
Daniel Migault
Ericsson

---

From: Töma Gavrichenkov <[email-masked]>
Date: Thu, 18 Jun 2020 22:50:26 +0300

Peace,

On Thu, Jun 18, 2020, 8:39 PM Daniel Migault <[email-masked]> wrote:

> To my perspective, holding code point allocation is likely to result in
> non allocated code points being used which represents a higher threat to
> interoperability than adding an algorithm.
>

+1

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Jun 2020 01:01:02 +0000

On Thursday, 18 June 2020 16:13:23 UTC Paul Wouters wrote:
> ...

+1.

-- 
Paul

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 19 Jun 2020 14:20:37 +1000

On Fri, Jun 19, 2020, at 01:30, Paul Hoffman wrote:
> It might be better, and faster, for this WG to adopt a one-paragraph 
> draft that makes the DS registry "RFC required", like the other 
> DNSSEC-related registries.

I think you mean "Specification Required".  RFC required has the same net effect, but the side effect being that you burden the ISE with these requests.

As long as the space of codepoints isn't too small (2^16 is fine), then I see no reason not to allow external publications request a value as long as they don't abuse the privilege.

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 19 Jun 2020 07:44:00 +0200

> As long as the space of codepoints isn't too small (2^16 is fine), then I see no reason not to allow external publications request a value as long as they don't abuse the privilege.

The space for DNSKEY and DS algorithms is one octet, so each of the two
registries has remaining space for around 250 algorithms and thus we
can't be "too wasteful".  Still, I wouldn't expect too many to want a
code point, so perhaps it could be optimistically started and only
restricted if getting too much popularity.

Ref. e.g. https://tools.ietf.org/html/rfc4034#section-5.1

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jun 2020 15:38:05 +0000

On Jun 18, 2020, at 9:20 PM, Martin Thomson <[email-masked]> wrote:
> I think you mean "Specification Required".

I do not.

>  RFC required has the same net effect, but the side effect being that you burden the ISE with these requests.

"RFC required" forces the specification to be stable enough for the ISE (or the IESG, for individual submissions) to approve publication. Using "specification required" means that someone can write an Internet Draft, get the code point, then realize that their draft was wrong due to lack of community review. The result is either:
- Two code points for similarly-named algorithms
- A code point whose definition is a moving target
Using "RFC required" is not perfect (due to errata and RFC updates), but it does mean that there is at least some community review before the code point is allocated.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Jun 2020 09:26:45 -0700

On Fri, Jun 19, 2020 at 8:38 AM Paul Hoffman <[email-masked]> wrote:

> "RFC required" forces the specification to be stable enough for the ISE
> (or the IESG, for individual submissions) to approve publication. Using
> "specification required" means that someone can write an Internet Draft,
> get the code point, then realize that their draft was wrong due to lack of
> community review. The result is either:

Sure. This seems not that desirable, but given that these algorithms are
more or less by definition ones in which there is not that wide interest,
not that big a deal.

I agree that this is undesirable. The registrations should be tied to a
single fixed draft version.

> Using "RFC required" is not perfect (due to errata and RFC updates), but
> it does mean that there is at least some community review before the code
> point is allocated.
>

What's your reasoning for why there needs to be community review before
there is a code point assigned? Would that still apply if the space were
larger?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jun 2020 17:11:40 +0000

On Jun 19, 2020, at 9:26 AM, Eric Rescorla <[email-masked]> wrote:
> What's your reasoning for why there needs to be community review before there is a code point assigned?

Historically, the quality of algorithm descriptions in early drafts has been variable. What the author considers sufficient and obvious, another might not. Also, review gives folks a chance to say things like "your test vectors appear wrong", "having test vectors would be really useful", and so on. 

> Would that still apply if the space were larger?

Yes. Leveraging the fact that the IETF community is in fact a community seems worth the effort to have the references in registries be useful to a new developer a decade in the future.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Jun 2020 10:30:02 -0700

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman <[email-masked]>
wrote:

> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>
> Yes. Leveraging the fact that the IETF community is in fact a community
> seems worth the effort to have the references in registries be useful to a
> new developer a decade in the future.
>

OK. In that case you and I disagree.

My reasoning is that (as above) these algorithms are generally of low
interest and that requiring community review for code point registration
has the result of consuming quite scarce resources in the service of making
the algorithms which are being registered marginally clearer. This opinion
is based on my extensive experience in reviewing code point assignments for
TLS (largely for things like exporters) where one was presented with a long
specification which was embedded in the context of some other protocol and
then one had to make sense of it and determine whether it was
implementable. And because you were actually holding up other people's work
based on that review, there was pressure to complete it. This kind of
experience is why we changed to the current system.

More generally, it seems like there are two primary purposes for code point
registration here:

1. To promote interoperability of the code points
2. To avoid code point collisions

My perspective here is that while interoperability is good, the primary
value here is to avoid collisions. People who wish to have interoperability
will still have the IETF process available to them, but given the large
number of uses of our protocols, I do not believe that it is productive to
make it harder for people to extend them in order to require
interoperability for those who do not believe they need it (or at least do
not believe they need the IETF enforcing it).

-Ekr

---

From: Dick Franks <[email-masked]>
Date: Fri, 19 Jun 2020 19:17:17 +0100

> vectors appear wrong", "having test vectors would be really useful", and so

How does any of that apply?
The algorithm in this case is specified by another standards organisation
and is what it is.
Community review did not find the incorrect test parameters in RFC5832 /
GOST R34.10-2001.

--Dick Franks

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2020 14:39:14 -0400

In article <CABcZeBNT9Wf2HxLDHR=tLod4YVgF-E=uaU7+=9nGLk=[email-masked]> you write:
>the algorithms which are being registered marginally clearer. ...

Sounds like expert review would be more appropriate, so only one
person has to spend cycles deciding whether the spec looks plausible.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Jun 2020 12:05:44 -0700

> person has to spend cycles deciding whether the spec looks plausible.

As I said, even that turns out to be quite a bit of work, depending on what
you think "plausible" means. If you review for "there appears to be
something vaguely formatted like a spec at this location", then sure. If
you mean "is this implementable", let alone secure, then it's pretty far
from easy.

-Ekr

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Jun 2020 17:40:09 -0400

> On Jun 18, 2020, at 11:30 AM, Paul Hoffman <[email-masked]> wrote:
> 

Why ? 

> It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the DS registry "RFC required", like the other DNSSEC-related registries.
You are proposing a bureaucratic solution without thinking about the operational implications of it. 
The hardest part to update in DNS tree right now is uploading DS records to the parents, keeping the list of algorithms down helps avoid operational problems 

Olafur

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Jun 2020 18:04:43 -0400 (EDT)

> The hardest part to update in DNS tree right now is uploading DS records to the parents, keeping the list of algorithms down helps avoid operational problems

On the contrary, lets make that list change every month, so registrars
and registries stop doing weird requirements on DS.

Or advocate for ICANN contractual updates for mandatory CDS support :P

Anyway, nothing of this is related to new algortihms and should not be
conflated with it.

Paul

---

From: Василий Долматов <[email-masked]>
Date: Sun, 21 Jun 2020 18:05:35 +0300

> 19 июня 2020 г., в 21:17, Dick Franks <[email-masked]> написал(а):
> 
> On Fri, 19 Jun 2020 at 18:12, Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> On Jun 19, 2020, at 9:26 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> The algorithm in this case is specified by another standards organisation and is what it is.
> Community review did not find the incorrect test parameters in RFC5832 / GOST R34.10-2001.

In the given case it is worth referring to RFC7091/GOST R34-10.2012
but the statement remains the same.

dol@

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Jun 2020 20:01:59 +0000

As I mentioned earlier, in response to "we need this on standards track" I have produced a very short draft that would remove that requirement:
   https://www.ietf.org/id/draft-hoffman-dnssec-iana-cons-00.txt
It covers both DS records and NSEC3 records, which have similar issues with hash algorithms. It also has an appendix that reflects Ekr's thoughts that maybe this all should be "specification required".

If the WG wants, this short draft could be a WG document.

--Paul Hoffman

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 22 Jun 2020 03:38:59 +0300

Peace,

On Fri, Jun 19, 2020 at 8:31 PM Eric Rescorla <[email-masked]> wrote:
> My reasoning is that (as above) these algorithms are generally of
> low interest and that requiring community review for code point
> registration has the result of consuming quite scarce resources
> in the service of making the algorithms which are being registered
> marginally clearer.

I sort of agree but I can't help wondering if the IETF would then
manage to process the flow of technical erratas, corrections and -bis
documents, which the current community review process is aiming to
avoid.

--
Töma

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Jun 2020 15:42:08 -0700

> If the WG wants, this short draft could be a WG document.

Yes please.
-- 
Wes Hardaker
USC/ISI