On 4/10/2022 3:00 PM, Daniel Kahn Gillmor wrote:
Maybe the concern is that the authoritative server implementation might
not have control over the full stack enough to respond ICMP Port
Unreachable to a specific subset of client IP addresses.
Yes. Something done by the application is much easier than messing with
ICMP.
In that case, i can imagine two distinct modes of operation:
- the server only has the opportunity to respond after the TLS/QUIC
handshake is complete. In this case, i don't see why the server
shouldn't just go ahead and handle the query; some part of the stack
has already borne the connection setup costs.
True. But this is easy to spoof.
- the server can respond early during the TLS/QUIC handshake. In this
case, we'd want to define an error at that layer, so that the
authoritative server can signal failure without incurring any
additional connection costs.
That could work. It would be similar to "ALPN negotiation failed". But I
am not sure that's easy to implement, giving different TLS answers to
different clients. It is essentially a layer violation. Architecture
considerations aside, that requires a pretty tight coupling between TLS
and Application implementation. Not always possible. Also, not
authenticated. The bad guys recipe book is going to say, "spoof this
message if you want to force a client to stop unilateral probing for 24
hours."
Does this analysis seem right to you? Or is there a reason that i'm
missing that an authoritative server would want to have the signal at
the layer where a extended DNS error message would make sense?
I like it because it can be entirely done at the DNS layer. The message
is authenticated by TLS, which does cost the server some cycles but
protects the client against spoofs.
-- Christian Huitema
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
