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

[Vladimír Čunát <[e-mail]>]

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


--Vladimir