On Thu 2023-09-07 19:38:01 -0700, Rob Sayre wrote:
> On Thu, Sep 7, 2023 at 7:15 PM Paul Hoffman <paul.hoffman@xxxxxxxxx> wrote:
>
>> On Sep 7, 2023, at 6:58 PM, Bron Gondwana <brong@xxxxxxxxxxxxxxxx> wrote:
>> >> Are you proposing a shorter value for "damping", or a note saying "1
>> day is just the suggested value, you might choose a shorter one if you
>> want"? Or something else?
>> >
>> > I'm suggesting a backoff algorithm which isn't "single failure gives you
>> N hours of no retry" - particularly, if you have an existing encrypted
>> connection and it has a fault, my reading was that you don't retry at all
>> to form an encrypted connection, even when talking to somewhere that has
>> previously succeeded. I agree you don't want to try more than once per day
>> against a server that's never supported encryption, but if you have had
>> consistent success encrypting to a server, then a single failure, you don't
>> want to be treating that one the same! It's definitely worth retrying
>> faster than a full day later.
>>
>> This sounds like you want a smaller value than 1 day for `damping` then.
>> Because those parameters are only suggested defaults, a resolver operator
>> like you could simply change the 1 day to maybe 1 hour, with the risk of
>> slowing down resolution to that one nameserver.
>
> I think you might want to rephrase this part. It seems like you really mean
> retries asymptotically approaching a 1 day timeout. What I've found works
> is exponential backoff that doesn't get too pessimistic, and also contains
> some amount of uncertain time intervals. It seems very dumb at first. But,
> if one piece breaks that may have nothing to do with DNS, you will get a
> stampede. Introducing a little bit of uncertainty can help.
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.)
It looks to me like it would be fine to introduce something more
sophisticated than a static `damping` parameter with the aim of
increasing the total amount of encrypted transport happening, but to do
so, you'd need to add to the per-authoritative-IP state held by
recursive resolver. This would further expand the table "Recursive
resolver state per authoritative IP, per encrypted transport", adding
more complexity to the implementation.
(it looks to me like you could probably do the uncertainty proposal it
without adding to the state if you just applied a randomized offset to
the test that evaluates: `(T0 - E-completed[X]) > damping` though)
If done wrong, it could also increase the risk of (b) happening: in
particular, you'd want make sure any change would *only* affect the
reversion to "happy eyeballs" style dual querying, rather than avoiding
the cleartext queries for too long. and of course, happy-eyeballs-style
queries will leak information.
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.
Any subsequent draft that specifies strong (non-opportunistic)
confidentiality for DNS queries should of course be more cautious. But
i think sticking with the simplest guidance that provides moderate
confidentiality for this case is the right way to go. If implementers
end up doing something more sophisticated i'd hope they would report
back on what they did and what parameters they chose. I don't think
more sophistication or complexity needs to be in this particular draft,
though.
--dkg
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
