Re: [dns-privacy] Fwd: New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features

On Wed, May 26, 2021 at 11:21 AM Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
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
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>