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
