On Wed, May 26, 2021 at 11:21 AM Vladimír Čunát <[email protected]> wrote:
> I like it in principle, so I say adopt. > > I already see a significant problem, though I expect we can fix it somehow > after adoption: > > After sending out all requests for SVCB records [...] > > My understanding of section 3 implies that an implementing resolver MUST > NOT ask any of the nameservers until *all* their SVCBs have been attempted, > in the most common case where no encryption is supported by the > nameserver-set. That would *not* scale at all. Even with 13 NSs it's a > rather bad amplification factor, and it reminds me of the recent NXNS > attack. > > On the whole, if a NS set has (many?) names without encryption support, > I'm afraid the corresponding zones may have to do without a guarantee of > getting encryption, though glue might help. > > > On 26/05/2021 15.21, Stephen Farrell wrote: > > SVCB in the parent zone will take years to happen > > The SVCB glue is just a slight optimization. I don't think it can even > save latency, just a packet per NS (and only in cases where the SVCB > exists). > As noted in my presentation, it's more than an optimization. It's an important security function in cases where the sensitive domain name is the apex. -Ekr > --Vladimir > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
