Subject: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

From: Tim Wicinski <[email-masked]>
Date: Wed, 4 Aug 2021 11:29:07 -0400

All

This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/

The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  18
August 2021

thanks
tim

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 4 Aug 2021 12:57:10 -0400

Hi,

I think this is a good, short draft and I support its publication. The
assignment requirement level it imposes is more appropriate than the
current requirement.

I do have some suggestions which range from minor to trivial:

   - Delete "some" from the first line of the Abstract.
   - To avoid the odd sounding rapid duplication of words, in the Abstract,
   replace the second occurrence of ". It also" with ", and".
   - Section 1: Replace the 2nd sentence/paragraph with "This document uses
   terms for IANA registry assignment policies as they are defined in
   [RFC8126]." or the like. (As I understand it, policies are not constrained
   to be those enumerated in RFC 8126 and, as long as you were careful to be
   clear about what you meant, you could use the terms in RFC 8126 with a
   different meaning in another document.)
   - Section 3: Suggest that the old and new RFC 8624 paragraphs be
   indented and/or enclosed in double quotes.
   - Section 4: Shouldn't "[this document]" be added to the References for
   the changed registries?
   - There are people who think that "assigned" is the best word for the
   assignment of a code point to a specific purpose and that "allocated" is
   more appropriate for allocating blocks of code points to a particular
   authority (as in allocated prefixes to regional internet registries) or to
   a particular policy (as in having a block of code points allocated to
   Standards Action assignment and another block allocated to FCFS). If you
   see any merit in that point of view, replace all occurrences of "allocated"
   with "assigned", I note that RFC 8126 makes no such distinction.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

On Wed, Aug 4, 2021 at 11:29 AM Tim Wicinski <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 11 Aug 2021 15:44:05 +0200

Hello,

I support the draft.  (as I wrote in November)  I re-read the current 
text, though I admit I could miss details relatively easily in process 
matters.

--Vladimir | knot-resolver.cz

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 11 Aug 2021 15:45:41 +0200

I support the adoption

-- 
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 11 Aug 2021 15:46:15 +0200

Sorry, I meant I support the draft

On Wed, Aug 11, 2021 at 3:45 PM Dmitry Belyavsky <[email-masked]> wrote:

>> If someone feels the document is *not* ready for publication, please
>> speak out with your reasons.
>>

-- 
SY, Dmitry Belyavsky

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 12 Aug 2021 10:02:38 -0400

> On Aug 4, 2021, at 11:29 AM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> All
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/>
> 
> If someone feels the document is *not* ready for publication, please speak out with your reasons.
> 
> This starts a two week Working Group Last Call process, and ends on:  18 August 2021
> 
> thanks
> tim

Hi Tim, 

I read the draft and I oppose it on principle, it is a bad idea. 
 
IMHO the ONLY benefit of it is to encourage DS record overloading with random data that has no DNSSEC relevance,  leading to abuse that threatens to turn the DS record into the new TXT overloading record resulting in large DS sets. 

The DS record is a unique record that it lives only at the parent side of delegation, when DNS was defined no such records were envisioned, if more are needed this working should take up a new work item to 
define a sub-set of the RRtype number space as Parent side-only to have a proper debate on the topic. 

Further more this draft  makes it trivial for vanity algorithms to be added to the DS and DNSKEY registries threatening the depletion of the small number space. 
There is a big difference between registration and deployment, only algorithms that the IETF thinks have a benefit to the whole community and have a expectation of wide deployment should be registered. 
Those of us who have fought the battles to get new algorithms rolled out and supported by large fraction of the internet can attest that increasing the number of supported algorithms is a no-win battle as it may lead to fragmented validation on the internet, forcing zones to sign with multiple algorithms ==> increasing packet size for no good reason. 

Getting DS records into parents at TLD level is hard, CDS/CDNSKEY are supposed to make that easier but uptake has been slow due resistance by industry and any overloading of the DS record may derail it. 

Olafur

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Aug 2021 10:57:14 -0400 (EDT)

On Thu, 12 Aug 2021, Olafur Gudmundsson wrote:

> IMHO the ONLY benefit of it is to encourage DS record overloading with random data that has no DNSSEC relevance,  leading to abuse that
> threatens to turn the DS record into the new TXT overloading record resulting in large DS sets. 

Not the only one, as you point out below. It is also useful for "vanity algorithms" :)

> The DS record is a unique record that it lives only at the parent side of delegation, when DNS was defined no such records were
> envisioned, if more are needed this working should take up a new work item to 

This would have been excellent to do when we did DS. It would still be
good to do this now, I agree. But it would be too late for some of the
things discussed now. If people insist that we need a parent side
"encrypted transport" indicator, that can be deployed next week, then
the options are DS or NS. By blocking DS use, we are just going to get
a less secure version stuffed in NS. So why I agree in principle with
you, I disagree in practise.

> Further more this draft  makes it trivial for vanity algorithms to be added to the DS and DNSKEY registries threatening the depletion of

It seems inevitable that we will see a few of these, whether we like it
or not. The alternative is that DNSSEC as a whole is disregarded by
some nation states. We don't want those ciphers to go through Standard
Track all the time. So the policy change to me seems reasonable.

> There is a big difference between registration and deployment, only algorithms that the IETF thinks have a benefit to the whole community
> and have a expectation of wide deployment should be registered. 

In an ideal world yes. In reality we can't stop some of this from
happening.

> Those of us who have fought the battles to get new algorithms rolled out and supported by large fraction of the internet can attest that
> increasing the number of supported algorithms is a no-win battle as it may lead to fragmented validation on the internet, forcing zones to
> sign with multiple algorithms ==> increasing packet size for no good reason. 

The "no good reason" is the subjective part of course :)

> Getting DS records into parents at TLD level is hard, CDS/CDNSKEY are supposed to make that easier but uptake has been slow due resistance
> by industry and any overloading of the DS record may derail it. 

This is a real concern. I personally do not have the knowledge to say
how much they might derail things or not. Again, it is more of a TLD
policy item then a technical issue. From a technical point of view,
the parent doing a "dumb copy" would be best. But then comes the
lawyers.

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 12 Aug 2021 13:25:37 -0400

On Aug 12, 2021, at 10:57, Paul Wouters <[email-masked]> wrote:

> things discussed now.

Can you talk more about why you think so?

Support for novel interpretations of particular DS algorithms will require support on both the provisioning and consumer side. Is it really that much more work to specify new DS-like RRTypes? 

There's truck-roll in both cases. Neither path is really going to make these features generally available any time soon.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Aug 2021 15:48:03 -0400 (EDT)

> Can you talk more about why you think so?

I did a small presentation during IETF 111 DPRIVE. You can find the
presentation deck and the recording on the IETF site.

> Support for novel interpretations of particular DS algorithms will require support on both the provisioning and consumer side. Is it really that much more work to specify new DS-like RRTypes?

It does not neccessarilly require support on the provisioning side, as
it is "just another DS record" from the provisioning point of view
unless lawyers insisted the TLD somehow verifies the pubkey is
pre-published or in an algorithm they 'support' (allow).

> There's truck-roll in both cases. Neither path is really going to make these features generally available any time soon.

There is a huge difference between "support for a DS record with
unknown or unexpected content at the RRR level" and "change all
DNS and EPP software on the planet". The first one has like 1500
actors. The second has millions or billions.

And as I argued, even if we do this by overloading DS or NS, is that
overloading really something we need? As it is only required for
privacy to nameservers that are in-bailiwick to the domain, which in
itself is already pretty much a dead give away even when you only
can observe encrypted TLS traffic to an IP address of a well known
published nameserver.

So my own order of preference is likely something like:

1) Forget about protecting in-bailiwick nameservers
2) Do it securely using DS at parent
    (only requires new code for validating nameservers that don't exist yet)
3) Do it insecurely using NS at parent
    (only requires new code for validating nameservers that don't exist yet)
4) Wait for SVCB at parent near universal deployment
    (requires widepsread recursive and authoritative updates, EPP updates, webgui updates)
5) do 3) until 4)
    (I can't even)

I guess somewhere between 2) and 5) would be "another out of band hack"

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 12 Aug 2021 16:38:39 -0400

Hi Paul,

> presentation deck and the recording on the IETF site.

Thanks, I will go and dig that out at some point.

> pre-published or in an algorithm they 'support' (allow).

I think the set of acceptable algorithms is constrained sufficiently often by registries and registrars that it makes little sense to consider any other case. But you may have different use-cases in mind.

> actors. The second has millions or billions.

I agree, but I don't think that observation is particularly helpful.

My earlier point was that any mechanism that changes the implementation of a referral is going to need to be backwards compatible to validators and authoritative servers that don't support it. Truck roll is required not to maintain the integrity of the DNS, but to enable the new desired functionality.

I think there's a lot of inertia on the provisioning side and no matter what mechanism is preferred. It might seem like accepting a new DS algorithm is much easier, but in practice it might also be that you only need a new RRType to be supported in two or three code bases before substantially all TLDs have support. My experience is that it can take years to have new algorithms supported by the RR machinery, regardless of how simple they are to express and consume in the DNS. It's always worth remembering that registry systems are not DNS systems; they are operated and constrained very differently. Without data I would suggest it's not especially helpful to predict which path is more rocky.

On the resolver side, a very small handful of resolvers account for the bulk of the world's validation. But regardless of what critical mass you identify as important to establish, there's substantially the same weight of change required on the consumer side. Whether you special-case a DS hack or understand what to do with a new RRType received as part of a referral, you still need code changes.

>   (only requires new code for validating nameservers that don't exist yet)

I don't understand what the parenthetical comment here means. You're suggesting that existing validating resolvers that don't know how to interpret a weird algorithm in a DS RRSet received during a referral don't need to be changed?

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Aug 2021 16:53:01 -0400 (EDT)

On Thu, 12 Aug 2021, Joe Abley wrote:

> I think the set of acceptable algorithms is constrained sufficiently often by registries and registrars that it makes little sense to consider any other case.

I think this problem is more easilly solved. You can reach out to them.

> I don't understand what the parenthetical comment here means. You're suggesting that existing validating resolvers that don't know how to interpret a weird algorithm in a DS RRSet received during a…

I'm saying that validators that support SVCB are not there yet, so when
adding SVCB support, they will also add the SVCB-via-DS support. So
the ramp-up will the ramp from "unencrypted resolvers" to "resolvers
with encrypted transport support". The DS hack does not delay that part.
And on the authoritative side, there is no protocol/code change
required (unlike the "SVCB at parent" solution)

Paul

---

From: Joe Abley <[email-masked]>
Date: Thu, 12 Aug 2021 17:07:41 -0400

> I think this problem is more easilly solved. You can reach out to them.

I wish you every success!

Joe

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Aug 2021 18:40:20 -0400

Hi, Joe,
Please allow me to interject, on a few different issues from this thread…

Sent from my iPhone

> On Aug 12, 2021, at 4:39 PM, Joe Abley <[email-masked]> wrote:
> 
> Hi Paul,
> 

Without referring to his presentation (literally or figuratively), and having not been active at that stage of DNSSEC, my take is that getting DS added to the EPP stuff was the o e opportunity where any other additions could have been proposed. That was also a few thousand TLDs ago and possibly pre-NSEC3.

> I think the set of acceptable algorithms is constrained sufficiently often by registries and registrars that it makes little sense to consider any other case. But you may have different use-cases i…

I’m not sure, but I think there are ICANN things that govern algorithms that are mandatory to support, at least in the gTLD space? (Thus the reason for the draft we are discussing, I believe… ie how new algorithms get added to the IANA registry.

> I agree, but I don't think that observation is particularly helpful.

See back to my comment about what I think Paul meant. If new DS records can be used (with either new DNSKEY algorithms or new DS hash algorithms), the EPP mechanics can be used as-is with no protocol changes required (and likely no code changes in the majority of registries, hopefully).

There is an uptake curve for the usefulness of this mechanism (Ie validation by resolvers and/or clients) but it is fully backward compatible. No truck roll required.

> On the resolver side, a very small handful of resolvers account for the bulk of the world's validation. But regardless of what critical mass you identify as important to establish, there's substant…

(Nodding in agreement…)

>> can observe encrypted TLS traffic to an IP address of a well known

Actually (sorry, changing who I’m replying to mid-stream), this is not accurate.

Protection of NS is needed for out-of-bailiwick domains too. The NS name is required for TLS.

This is also the case when THAT domain is served by nameservers in yet another domain.

The first two delegations do not strictly require glue A/AAAA records, and if the latter-most domain is in a different TLD, glue is not even permitted.

(Resuming stream of reply now to Joe…)

> 
> I certainly don't fully understand the degree of risk from subverting a resolver to send a query to a bogus authority server.

If all domains are signed, the degree of risk is likely insignificant.

However, there are use cases where the delegation of an unsigned zone to an authoritative server whose name is in a signed zone results in a large change in risk, at least in the privacy use case. Having the delegation (NS set) protected via some record signed in the parent, ensures that the right name server name is used. When that name server name is in a signed zone, other record types can securely be obtained, such as TLSA records. If the NS is not protected this way, it is not possible to securely obtain transport parameters.

Actually, sending the query to the wrong authoritative server always results in loss of privacy information.

IFF the delegation is not over a secure transport, unvalidated NS responses are possible to subvert via an on-path attacker, or by a cache poisoning attack.

The unsigned delegation gets even worse at this point, since a successful poisoning attack can elevate an off-path attacker to an on-path attacker.

> I am not arguing for or against any kind of mechanism to mitigate unsigned glue. So I don't have any order of preference. However:
> 

This is correct. It is specified in 4033/4/5, and has been confirmed experimentally with several major resolvers and diagnostic tools.
Paraphrasing, “treat unknown algorithms as insecure”, and ignore lack of corresponding matching DNSKEY records below the cut on unknown algorithms.

(I did a lot of experiments first before proposing any of this.)

The bigger picture on which WG handles any DS type algorithms (DNSKEY or DS) is what is placed on the parent side of a zone cut, for what purpose, and how that gets sent to the parent.

It seems to me that DPRIVE folks want to optimize for cold cache use cases, fewer DNS queries, and to do this using inappropriate trust/security models. For example, placing signals on transport mechanisms and potentially even public keys on the parent side of a zone cut.

IMNSHO, the use of signed child zones to provide things like TLSA records is the only secure and trustworthy mechanism for the privacy use case (over TLS).

Other than a handful of CCTLDs, there is no CDS available to provide DS to the parent. CDS polling directly from registry to registrant is pretty much ruled out by RRR, and Registrar polling still relies on EPP for uploading DS to the registry. There is no data integrity protection, and registrar level credentials are used.

Adding new DS types is required to avoid truck rolls.

Doing this in DNSOP is how we ensure it is possible to use DANE/TLSA.

That this would also provide  insecure delegations with privacy, is a feature, not a bug.

Sorry, didn’t mean for this to be such a long message.

Brian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 Aug 2021 20:45:15 -0700

The title page (top left) says this updates RFC 3658, and that RFC is
mentioned in the Introduction and listed in the References section, but
this document doesn't explain what in that document is being updated.

-MSK

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Aug 2021 14:13:16 +0000

On Aug 15, 2021, at 8:45 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> The title page (top left) says this updates RFC 3658, and that RFC is mentioned in the Introduction and listed in the References section, but this document doesn't explain what in that document is being updated.

Good catch. I'll update the introduction to make that more explicit.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Aug 2021 03:06:15 -0400

All

The Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons ended
last week, and we've filtered through the comments both pro and con.

We feel there is rough consensus to move this forward.

thanks

Benno/Suzanne/Tim