Hi Ben-- On Mon 2021-12-13 08:34:22 -0800, Ben Schwartz wrote: > The terminology section says > > * "unilateral" means capable of opportunistic probing deployment > without external coordination with any of the other parties > > To my eye, that excludes any way of delivering ECHConfigs, whether or not > SVCB becomes the preferred mechanism for that. > > In general, I think this draft should try to be clear that it is restricted > to the case where no additional DNS queries are performed.
I'd be game for such a clarification, but i'm not sure how to define
what "additional" means here. Surely this draft is not going to
encourage any draft-specific DNS queries, but it's also not going to
prohibit any DNS queries which might otherwise take place, right?
For example, imagine a TLS client stack that automatically checks for
ECHConfigs (assuming that mechanism has been specified, as i hope it
will be soon). This draft isn't going to explicitly require that such a
feature be disabled, right?
Do you want to propose some text that makes this adjustment?
>> 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")
>
> Perhaps "within the span of a few seconds" would be clearer.
Fixed in git, thanks.
>> 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.
>
> I'm not sure this is true. A 5-tuple load balancer, for example, would
> preserve stream continuity but fail for the purpose of this section.
right, that's a good point.
> I also don't think IP-based load balancing is technically sufficient. For
> large resolvers with multiple "exit" IPs, there is (currently) no
> requirement that the state estimate for a given destination IP be
> partitioned by the resolver's exit IP.
The section "Separate State for Each of the Recursive Resolver's Own IP
Addresses" is intended to address this concern. If you think it's
insufficient, i'd be happy to hear suggestions for improvement!
>> 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",
>
> Yes, but this is no worse than the handshake of the encrypted transport we
> are seeking to bootstrap, so it's a performance cost that will be borne
> anyway.
well, it incurs that specific performance cost on each query above and
beyond what would have been done for a cleartext connection, without
gaining any extra defense against a passive monitor. This seems like
something we'd like to minimize where possible.
>> and if the allocations are truly random they'll be frequently
>> "damped" into not trying encrypted transport for a full day.
>
> This is interesting. Maybe the long damping should only apply if the
> request timed out, as opposed to being rejected within a few milliseconds.
Maybe there should be two different damping values: a long one when
something times out, and shorter one when there is a rapid failure?
My concern is that if a quick failure (e.g. ICMP Port Unreachable)
results in a more rapid request to reestablish an encrypted session,
then we're encouraging authoritative server operators who *don't* plan
to enable encrypted transport to let attempted encrypted transports time
out, since that will reduce the number of attempts to establish an
encrypted connection.
Do you have a sense of how to tune such a distinction that wouldn't
create that incentive?
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
