Hi Ben-- Thanks for the prompt review and feedback!
On Thu 2021-12-09 16:14:36 -0500, Ben Schwartz wrote:
> The SNI guidance looks good to me.
>
> I find it confusing to mention ECH in this draft. ECH can never be used
> with this specification, because there is (by definition) no SVCB record to
> provide the ECH keys. (If there is a SVCB record in play, then we are no
> longer in "unilateral probing".)
given that we haven't established what the signalling mechanism
is/should be for authoritative dprive, i'm not entirely sure that we're
out of the realm of unilateral probing here. (for example, does the
mere presence of SVCB indicate a hard-fail condition?) I think that's
up to the other draft. ☺
That said, i don't think i'd have an objection to removing the ECH
reference (or at least trimming it down to only be relevant for the
discussion of potential leak due to SNI in the privacy considerations
section)
> I did notice one issue with -01:
>
> To avoid incurring additional minor timeouts for such a recursive
>> resolver, the pool operator SHOULD either:
>>
>> * ensure that all members of the pool enable the same encrypted
>> transport(s) simultaneously, or
>>
>> * ensure that the load balancer maps client requests to pool members
>> based on client IP addresses.
>
> The first option seems a bit unrealistic.
It might be unrealistic for some pool operators, but it's surely not
unrealistic to all pool operators (for some plausibly-fuzzy definition
of "simultaneously")
> I would replace it with "ensure that any members of the pool return an
> explicit rejection packet (e.g. TCP RST) if they do not support the
> encrypted protocol, or".
While this is good guidance in general for authoritative servers (i'd
include "ICMP port unreachable" in list alongside TCP RST, and maybe
some QUIC-specific signalling?), i'm not convinced it belongs in this
section about authoritatives behind a pool.
In particular, i don't think the consequences of this approach would
yield a healthy pool, which is why i didn't include it in the list
initially.
First, if a pool's load balancer can't reliably map traffic from the
client at IP address X to pool member Y at all, then any sort of
stream-based protocol (whether that's DoT or DoQ or even Do53 over TCP)
is going to fail in pretty terrible ways.
If we assume that the load balancer is capable of allocating persistent
stream-like flows (including QUIC sessions if DoQ is in the mix?) to
specific pool members, but randomly allocates stream-initiating packets
from the same client IP address to different pool members, then we'll
have the problem that a client will "learn" that an encrypted transport
is available to that authoritative, and upon the next stream initiation
might land on a pool member that doesn't implement that encrypted
transport.
In effect, the presence of encrypted transport will "flap" for any given
client.
While the consequences will be relatively small (even if the RST or port
unreachable messages are swallowed by the network, the default `timeout`
parameter for establishing the encrypted transport has fast expiry),
clients will still incur at least an extra serialized round-trip on each
"flap", and if the allocations are truly random they'll be frequently
"damped" into not trying encrypted transport for a full day.
How would you feel about adding the guidance you suggested more
generally to the overall guidance for authoritative servers?
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
