Hi Christian-- On Mon 2022-04-11 15:21:26 -0700, Christian Huitema wrote: > True. But this is easy to spoof.
right, but it's even easier to spoof an ICMP Port Unreachable, which
will undoubtably have the same effect on an opportunistic recursive
resolver.
> 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."
I really don't think "not authenticated" or "spoofable" is a valid
objection in this particular use case, but i hear you about the
difficulties for an implementation based on different layers of the
stack that are typically accessible to the DNS server implementer.
I'm just wondering what the motivation is for the authoritative server
to emit this response if it can *only* be done at the DNS layer. Aren't
all the resources you're worried about already being consumed at that
point?
If we define semantics for some future signalled protocol that depends
on proper authentication, and those semantics could tell the recursive
resolver to limit itself somehow (and for some particular reason?), then
that'd definitely be interesting. But any response from the server that
requires the server to be properly authenticated doesn't seem like it
belongs in this draft, regardless of its semantics.
I'd be happy to include a definition/declaration of a "please back off"
response at the DNS layer into this draft, if we can be clear about:
- What specifically is the server expecting the client to do -- does it
differ from the client's response to, for example, an ICMP Port
Unreachable message? (no difference is fine, but we should be clear)
In particular, i'd be reluctant to imply or encourage that such a
signal would cause the recursive resolver to back off even more
strongly than it would back off if it received any other error,
includng ICMP Port Unreachable, a TLS handshake negotiation failure,
etc. Given that this signal is guaranteed to be just as spoofable as
these other network-inflicted failure modes, it would be unfortunate
if an interfering network attacker could cause *more* cleartext to
flow over time just because of the layer at which the response
appeared.
- What does the authoritative server gain from such a response? When
should a reasonable authoritative server deploy this response?
Would you be up for taking a crack at suggesting some text?
Thanks for talking this over!
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
