On Fri, Sep 8, 2023, at 02:18, Paul Hoffman wrote:
Thanks for the review!On Sep 7, 2023, at 7:16 AM, Bron Gondwana via Datatracker <noreply@xxxxxxxx> wrote:> My only concern is that it does fall back very easily to cleartext, for a long> damping period. As a protocol implementer myself, I would generally expect to> retry something one or two more times over the course of a few minutes before> giving up entirely for 24h, since the server at the other end may have just> been restarting and either dropped an existing connection or rejected a SYN> packet, but be ready a moment later. I'd be happy with a limit of something> like 5 tries over 2 minutes (one every 30 seconds) before giving up.In Section 4.3, the "damping" parameter has a "suggested default" of 1 day. That's a suggestion, not at all a requirement. It was established based on the idea that almost every domain name has multiple nameservers, and that it is likely that if one server has a failure such as a timeout, the resolver will try the other nameservers (which may or may not be encrypting).
Yeah, that bit makes sense, so you'll wind up with one of them having encrypted connection and the other not - so you'll probably want to default to sending further requests to that once since you have it tagged as available for encryption.
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.
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong@xxxxxxxxxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
