On Tue, Sep 12, 2023 at 5:26 PM Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> wrote:
Thanks for all this discussion. The main purpose of having any sort of
damping in the draft is to encourage operators of authoritative servers
that they will not find themselves in trouble even if they enable
encrypted transport briefly for experimentation or evaluation, and then
turn it off again.
There are two kinds of trouble that such an authoritative server could
find itself in:
a) It could be flooded with queries on a transport that it no longer
supports.
b) Queries from recursive resolvers could fail or be substantially
delayed when the encrypted transport is disabled.
The `damping` parameter primarily influences (a), which i'd argue is
likely the less-important of the two, operationally, since it doesn't
cost the authoritative operator that much to send a "port closed" ICMP
response. ((b) is influenced more by the `timeout` parameter.)
[...]
>From my perspective, the simple approach described in the draft is a
good opportunistic baseline -- minimally complex, works fine
(opportunistically) with a functioning server in the absence of an
active attacker, and fails gracefully in the face of errors on the
server side.
I still think this is wrong, because connection establishment is the expensive thing here. But I don't object strongly.
Let's say the server network hardware gets unplugged for 30 seconds. Does everyone then try to re-establish an encrypted connection 24 hours later? In this situation, the operator cannot send a "send a 'port closed' ICMP response", because the network is broken. The reason to insert at least a little bit of variability in the retry requests is to help bring up a server after something close to the server breaks.
The other way to deal with this problem is to arbitrarily reject connections at the server as things come back up, but the draft then recommends another 24 hours.
thanks,
Rob
thanks,
Rob
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
