Subject: [DNSOP] Call for Adoption: draft-hoffman-dnssec-iana-cons

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Dec 2020 11:26:25 -0500

This draft was present at IETF108 and IETF109. There was interest in
adopting this, but I do recall that implementors had some concerns about
this.  However, there was enough interest in starting an adoption
call on this.

Because of the holiday, I'm going to run this call until the 31st, to allow
folks to discuss.

This starts a Call for Adoption for:  draft-hoffman-dnssec-iana-cons

The draft is available here:
https://datatracker.ietf.org/doc/draft-hoffman-dnssec-iana-cons/

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: 31 December 2020

Thanks,
tim wicinski
DNSOP co-chair

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Dec 2020 16:34:56 +0000

On Dec 11, 2020, at 8:26 AM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> 
> This draft was present at IETF108 and IETF109. There was interest in adopting this, but I do recall that implementors had some concerns about this.  However, there was enough interest in starting an adoption
> call on this.
> 
> 
> 
> Because of the holiday, I'm going to run this call until the 31st, to allow folks to discuss. 
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-hoffman-dnssec-iana-cons/
> 
> 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.
> 

I'd like to see this adopted by the WG so that the GOST document can proceed forward. I'm also quite interested to hear input from developers about how they feel affected by the different options for documentation of algorithms for DNSSEC.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Thu, 24 Dec 2020 13:28:59 -0500

Hi,

As the DNS is a global shared resource and its reliability is based on
**all** pieces of software adhering a common standard, I am inclined to
believe that new cryptographic algorithms introduced with anything less
restrictive than "IETF Review" - such as "Specification Required" and "RFC
Required" - does not sufficiently prevent altering the interoperability of
the DNS.
This is likely to result in the introduction of potentially weak - and
unmanageable - cryptography, a fragmentation of the DNS name space, as well
as the introduction of policy matters within the IETF. Typically, some code
points will be qualified as **standard** while others will be
**non-standard**. This may put the IETF in a position to define that the
trust of community C1 in algorithm A1 is non-standard while the trust of
 community C2 in algorithm A2 is standard. I believe we should avoid this
path.
In addition, I also believe that "Standard Track" is the appropriated
status. While a call for adoption of a cryptographic algorithm with a
"Standard Track" asks pretty clearly the community on whether they are
willing to see that algorithm being deployed. The same call for adoption
with another status is less clear and people may not feel concerned which
will make it harder to judge the consensus. It is also envisioned that
calls for adoption will have an extra round of discussion over the status
which I am not sure is necessary.

As a result, I am inclined to believe we should not adopt
draft-hoffman-dnssec-iana-cons and we should re-evaluate RFC6014.

Yours,
Daniel

On Fri, Dec 11, 2020 at 11:35 AM Paul Hoffman <[email-masked]>
wrote:

> > 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.
> >
> I'd like to see this adopted by the WG so that the GOST document can
> proceed forward. I'm also quite interested to hear input from developers
> about how they feel affected by the different options for documentation of
> algorithms for DNSSEC.
>
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
Daniel Migault
Ericsson

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Dec 2020 19:01:41 +0000

On Thu, Dec 24, 2020 at 01:28:59PM -0500, Daniel Migault wrote:
> ...

+1.

-- 
Paul Vixie

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Dec 2020 20:27:07 +0000

On Dec 24, 2020, at 10:28 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> As the DNS is a global shared resource and its reliability is based on **all** pieces of software adhering a common standard, I am inclined to believe that new cryptographic algorithms introduced with anything less restrictive than "IETF Review" - such as "Specification Required" and "RFC Required" - does not sufficiently prevent altering the interoperability of the DNS.  

Why do you feel that DNSSEC has requirements stronger than other IETF security prot0cols such as TLS, IPsec, S/MIME, and so on? 

> This is likely to result in the introduction of potentially weak - and unmanageable - cryptography, a fragmentation of the DNS name space, as well as the introduction of policy matters within the IETF.

How would that happen? The developers of DNSSEC signing and validating software are intelligent, thoughtful people.

> Typically, some code points will be qualified as **standard** while others will be **non-standard**. This may put the IETF in a position to define that the trust of community C1 in algorithm A1 is non-standard while the trust of  community C2 in algorithm A2 is standard.

Exactly right. DNSOP has already done that by adopting the GOST standard, which is only of interest to Russia (and maybe a small number of other countries). GOST is a standard *only* for DNSSEC, not for the other IETF security standards, which seems quite out of balance.

> I believe we should avoid this path.
> In addition, I also believe that "Standard Track" is the appropriated status. While a call for adoption of a cryptographic algorithm with a "Standard Track" asks pretty clearly the community on whether they are willing to see that algorithm being deployed. The same call for adoption with another status is less clear and people may not feel concerned which will make it harder to judge the consensus. It is also envisioned that calls for adoption will have an extra round of discussion over the status which I am not sure is necessary. 
> 
> As a result, I am inclined to believe we should not adopt draft-hoffman-dnssec-iana-cons and we should re-evaluate RFC6014.

What has changed since DNSOP discussed and adopted RFC 6014 that would make us want to do that? 

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 25 Dec 2020 22:52:51 -0500

> On Dec 25, 2020, at 3:27 PM, Paul Hoffman <[email-masked]> wrote:
> 
> On Dec 24, 2020, at 10:28 AM, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, 
>> 

DNS is a fire-and-forget protocol, all the ones you mention include a handshake that can be used to agree on algorithms. Such facility does not exist in DNS. 

I oppose any relaxation of thresholds to add algorithms to DNSSEC, as there is no need. 

  Ólafur

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 27 Dec 2020 13:40:15 -0500

(Speaking without my chairs hat here)

How about instead of loosening the requirement, we take the top 64 values,
allocate them as either Experimental or FCFS, and it is explicitly noted
NOT REQUIRED (or NO ONE WILL IMPLEMENT THESE FOR YOU).

That would leave the registry with the strict requirements and allow items
to get code points.

Too simple an answer?

tim

On Fri, Dec 25, 2020 at 10:53 PM Olafur Gudmundsson <[email-masked]> wrote:

> Why do you feel that DNSSEC has requirements stronger than other IETF
> security prot0cols such as TLS, IPsec, S/MIME, and so on?
>
>
> DNS is a fire-and-forget protocol, all the ones you mention include a
> handshake that can be used to agree on algorithms. Such facility does not
> exist in DNS.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Dec 2020 13:46:15 -0500 (EST)

On Sun, 27 Dec 2020, Tim Wicinski wrote:

> How about instead of loosening the requirement, we take the top 64 values, allocate them as
> either Experimental or FCFS, and it is explicitly noted NOT REQUIRED (or NO ONE WILL IMPLEMENT
> THESE FOR YOU).
> 
> That would leave the registry with the strict requirements and allow items to get code points. 
> 
> Too simple an answer?

I think this is the best solution. There just will be nation state
crypto, and this allows those to exist. And we still keep control
of limiting the international ciphers by the IETF to the small
subset we think is good, hopefully preventing new long tails of
obsolete ciphers.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 30 Dec 2020 13:29:26 +0300

Hi,

> subset we think is good, hopefully preventing new long tails of

I agree, except that I'd make allocation policy Specification (or RFC) Required and not FCFS or Experimental.
Because I believe that _some_ bar should exist, not to make this area a garbage bin...

Regards,
Valery.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Dec 2020 22:50:36 +0000

On Dec 27, 2020, at 10:40 AM, Tim Wicinski <[email-masked]> wrote:
> How about instead of loosening the requirement, we take the top 64 values, allocate them as either Experimental or FCFS, and it is explicitly noted NOT REQUIRED (or NO ONE WILL IMPLEMENT THESE FOR YOU).
> 

Yes, but it is close. I agree with Valery and others that allocation in this set of values needs to be "RFC required" to avoid losing track of the actual algorithms. Also, it can't be "the top 64 values" because some of them are already in use. And it really doesn't need to be 64 values: the WG will want to revisit this decision well before then. Making 100-122 be RFC Required, and updating RFC 8624 to show these values with "MAY" in each column, makes the intention clear.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Wed, 30 Dec 2020 22:10:50 -0500

Hi,

Thanks for your questions, please see inline some clarifications.

Yours,
Daniel

> security prot0cols such as TLS, IPsec, S/MIME, and so on?

<mglt>
If I understand clearly the comment, it seems to say that TLS ( for example
) is using RFC Required and that DNSSEC should do the same. Quickly going
through RFC 8447, I cannot find "RFC Required", so I am wondering if you
have a specific registry in mind. As far as I can see, the TLS cipher suite
registry requires Standard Action to set Recommended to "Y" and
Specification Required otherwise. As a result, leaving it to Standard
Action seems better aligned with what TLS does for "Recommended".

My motivation for not lowering the requirement is based on the specificities
of DNS, that is the DNS is a system handles a global shared resource - I
think that is what I was trying to say in my first sentence. I am not aware
of shared resources handled by the protocols you mentioned. DNS is part of
the Internet architecture and an interoperability issue with DNS is an
Internet infrastructure concern. A resolver not resolving .example affects
all its worldwide clients willing to connect to any host in .example. An
interoperability issue associated with the other security protocols being
mentioned is an issue between one sender and one receiver. This seems to me
less than an issue for the Internet.

Olafur comes with additional differences between DNSSEC and other security
protocols.
</mglt>

> as the introduction of policy matters within the IETF.
>
> How would that happen? The developers of DNSSEC signing and validating
> software are intelligent, thoughtful people.
>
> <mglt>
If I understand your comment you seem to say that interoperability is
overall provided by the DNSSEC developers as opposed to the IETF. In
particular, developers will take the responsibility to make sure they all
pick the same subset of crypto to ensure interoperability. If that is
correct, it seems hard to explain that a resolver will not resolve some
domains, and believe this is the role of the IETF instead is to provide
such guidance.
</mglt>

> > Typically, some code points will be qualified as **standard** while
> others will be **non-standard**. This may put the IETF in a position to
> define that the trust of community C1 in algorithm A1 is non-standard while
> the trust of  community C2 in algorithm A2 is standard.
>
> Exactly right. DNSOP has already done that by adopting the GOST standard,
> which is only of interest to Russia (and maybe a small number of other
> countries). GOST is a standard *only* for DNSSEC, not for the other IETF
> security standards, which seems quite out of balance.
>
> <mglt>
My comment was that the specificities of DNS make code point assignment not
only technical but potentially raise some policy issues. It seems important
to be well aware of this and - in my opinion - avoid taking that path.
Your comment seems to say that GOST is a Standard for DNSSEC which is
unfair as this is not the case for other protocols and that GOST is only of
interest by some specific countries.
As mentioned earlier, DNSSEC has its own specificites that makes it
different from other protocols. Typically, your comment seems to say that
the use of GOST will be limited to the boundaries of a subset of countries.
I think this is misleading as this is, in fact, used by anyone (worldwide)
willing to access a web site associated with those countries/communities
(under .ru, among others). I do see this as a fragmentation and believe we
should avoid this as much as it is possible. More specifically, I expect
that resolvers will have to implement anything that is used, which - again
in my opinion - makes the requirement for anything non standard useless.
</mglt>

> <mglt>
Looking at the call for adoption of RF6014 [1] this seems a legitimate
question. On my side, I had not reviewed RFC 6014 but would have probably
come with similar comments if the call for adoption would have been today.
[1] https://mailarchive.ietf.org/arch/browse/dnsext/?q=dnssec-alg
-allocation&gbt=1
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 30 Dec 2020 22:16:37 -0500

Hi Tim,

Just to answer the question and maybe clarify my opinion. I also considered
that we might need some experimental RFCs, but came to the conclusion that
it was not necessary. The experimentation seems quite straight forward. On
the other hand, I see two issues with allocating code points with non
Standard Actions. Firstly, it will make hard to prevent any code point to
be assigned, so management of the registry might become harder. Then, I do
believe it will be hard to not implement any code point being used. As a I
believe the registry should be the gatekeeper as opposed to developers. For
that reason I still believe that sticking to Standard Action is the
preferred way to do.

Note it is not uncommon that for some people every code points in the
registry should be supported, so requiring Standard Action only also avoids
many confusions.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Dec 2020 22:22:51 -0500

On Dec 30, 2020, at 22:11, Daniel Migault <[email-masked]> wrote:
> 
> 
> <mglt>
> If I understand clearly the comment, it seems to say that TLS ( for example ) is using RFC Required and that DNSSEC should do the same. Quickly going through RFC 8447, I cannot find "RFC Required", so I am wondering if you have a specific registry in mind. As far as I can see, the TLS cipher suite registry requires Standard Action to set Recommended to "Y" and Specification Required otherwise. As a result, leaving it to Standard Action seems better aligned with what TLS does for "Recommended".

As previously explained in this thread, you cannot compare TLS with DNSSEC. With TLS you can offer IETF algorithms along with a nation state algo, and the client can pick what it prefers.

For DNSSEC, the signed zone has already made all the decisions. A DNS client cannot decide to use or not use its local national algo.

Paul

> My motivation for not lowering the requirement is based on the specificities of DNS, that is the DNS is a system handles a global shared resource

For those regimes who for instance are not allowed to trust RSA or NIST/NSA based ECC curves, you prefer those zones use no DNSSEC at all versus say GOST ?

Because that’s what you are offering as the only choice now.

Paul

---

From: Daniel Migault <[email-masked]>
Date: Wed, 30 Dec 2020 23:28:04 -0500

On Wed, Dec 30, 2020 at 10:22 PM Paul Wouters <[email-masked]> wrote:

> > If I understand clearly the comment, it seems to say that TLS ( for
> example ) is using RFC Required and that DNSSEC should do the same. Quickly
> going through RFC 8447, I cannot find "RFC Required", so I am wondering if
> you have a specific registry in mind. As far as I can see, the TLS cipher
> suite registry requires Standard Action to set Recommended to "Y" and
> As previously explained in this thread, you cannot compare TLS with
> DNSSEC. With TLS you can offer IETF algorithms along with a nation state
> algo, and the client can pick what it prefers.
>
> For DNSSEC, the signed zone has already made all the decisions. A DNS
> client cannot decide to use or not use its local national algo.
>
> Paul
>
<mglt>
I think you expand what was my response mentioned as:"Olafur comes with
additional differences between DNSSEC and other security protocols." So yes
that is correct. I however, do not see that contradicting that RFC Required
is not so widely used - even in other security protocols.
</mglt>

>
> > My motivation for not lowering the requirement is based on the
> specificities of DNS, that is the DNS is a system handles a global shared
> resource
>
> For those regimes who for instance are not allowed to trust RSA or
> NIST/NSA based ECC curves, you prefer those zones use no DNSSEC at all
> versus say GOST ?
>
<mglt>
I do not understand the reasoning. I am proposing a Standard Action
requirement and as far I can see GOST [1] is Standard Track. It is unclear
to me what prevents DNSSEC being deployed with GOST.

[1] https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
</mglt>

-- 
Daniel Migault
Ericsson

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Dec 2020 13:48:36 -0800

> Because that’s what you are offering as the only choice now.

Thanks for making the point so sharply, Paul.

To be transparent about my priors, I think it would be better if
people used one of the more typical IETF algorithms, which is to say
ECDSA or EdDSA [0]. With that said, for whatever reason there are
people who want to use some other set of algorithms and the IETF's
ability to discourage them is limited. The IETF really has three main
options:

1. Don't allocate a code point at all
2. Allocate the code point but in some manner that makes clear
   we don't endorse it (effectively what TLS does for algorithms
   like this)
3. Allocate the code point without comment

My general sense is that (1) and (2) do to some extent discourage the
use of these algorithms (with (1) being more effective than (1)) but
(1) may discourage them *entirely*, so the likely result is that
people who want to use them just squat on a code point (or worse,
multiple code points!) and we lose those code points anyway, but
potentially after some interop problems. It's for this reason that
I think (2) is the best approach here.

As a number of people have noted, DNSSEC is different from TLS, IPsec,
etc. in that there's no real opportunity to negotiate. I don't think
that this changes the basic calculation but it might make it worth
investing more effort in discouraging people, both to prevent
algorithms that we think people should avoid and to reduce sharding of
the ecosystem if, for instance, some implementations opt not to do
algorithm X. It might also make it worth spending more effort in
helping people get good definitions of algorithm X even if we don't
think they should use it (as opposed to with TLS where the response is
mostly "go ahead and register, but don't bother us"). I'm skeptical
that "RFC Required" would foster either one of these goals, but
perhaps that's what Daniel is arguing?

-Ekr

[0] I think we should discourage RSA.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Dec 2020 22:09:11 +0000

Hiya,

> 3. Allocate the code point without comment

FWIW, I kind of agree with ekr, both as to the options
and on my current preference to not too easily loosen
up for DNSSEC.

That said, I wonder as to the actual deployment of algs
that we'd not recommend, especially given the relative
scarcity of DNSSEC signing.

Does anyone have a pointer to survey-like material that
has a focus on rarer algorithms in DNSSEC? One reason to
ask is that from a first glance it looks to me like .ru
isn't using gost, which would be telling, if correct.

To be clear: I don't think spending much time debating
how to handle algs for an infinitesimal number of zones
is that worthwhile, so that'd be another reason to prefer
the status quo, if that is the case.

Thanks,
S.