On Thu 2021-12-16 10:37:53 -0800, Ben Schwartz wrote: > In my view, a correct implementation here would simply provide the TLS > stack with an IP address and no validation identity, so there is no > way for the TLS stack to retrieve an ECHConfig.
That would be a reasonable implementation, for sure. But i don't see
why it wouldn't *also* be reasonable to supply a TLS stack with the NS
name and a flag that says not to treat authentication failure as fatal.
> (Unless you're talking about a client stack that deliberately provokes
> the fallback mechanism to retrieve the ECHConfig in-band???)
I don't know of any such stack currently, but if it exists, i wouldn't
see using it as in any way a contradiction to this unilateral probing
strategy for recursive resolvers.
>> Do you want to propose some text that makes this adjustment?
>
> I think it's basically already there.
ok, great :) if you have any concrete suggestions after chewing it
over, please don't hesitate to propose on the list.
>> Do you have a sense of how to tune such a distinction that wouldn't
>> create that incentive?
>
> How about if the resolver waits for deltaT * damping / timeout after each
> failure? Then the average delay is the same either way, but returning RST
> reduces tail latency.
I'm not sure i know what deltaT means in the proposal here -- does it
mean time from the connection attempt to the observed failure?
If that's what it means, then a prompt response (RST, ICMP port
unavailable, or other immediate failure indicators) would mean a sooner
retry, right? This seems like it still creates the negative incentive
that i was concerned about: the admin of an authoritative server that
isn't offering encrypted transport, who wants to reduce the number of
attempts it sees, might then be inclined to *disable* failure
indicators, because it would increase the delay that each unilateral
probing client takes between retries.
Am i misunderstanding your proposal?
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
