Hi Paul,

On 12 Aug 2021, at 15:48, Paul Wouters <p...@nohats.ca> wrote:

> On Thu, 12 Aug 2021, Joe Abley wrote:
> 
>>> 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.
>> 
>> 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.

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

>> 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).

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.

>> 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.

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.

> 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.

I certainly don't fully understand the degree of risk from subverting a 
resolver to send a query to a bogus authority server. 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:

> 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)

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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to