Subject: [dns-privacy] Will unilateral-probing "poison the well"?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 11 Dec 2021 00:15:45 +0200

One of the concerns raised at IETF 112 about
draft-dkgjsal-dprive-unilateral probing was that unilateral probing by
recrusive resolvers might "poison the well" and discourage authoritative
servers from deploying encrypted transport.

For example, in jabber, Erik Nygren commented: "TOFU has a big "poison
the well" risk here that will prevent operators from enabling."

  https://jabber.ietf.org/jabber/logs/dprive/2021-11-11.html#13:07:33.595176
    ("TOFU" means "Trust on First Use")

I think this is a legitimate concern: one of the goals of the draft is
to describe how to probe in a way that *doesn't* discourage adoption.

Would folks who have this concern (maybe including Erik, if you're
reading!) take a look at the draft and identify any specific behavior
that you think could be problematic?

I don't think the behavior that Joey and I have specified in
unilateral-probing does TOFU, since it's entirely unconcerned with
authentication.  So there is no "trust on first use" with regards to
choice of server authentication credentials from this perspective.

If an initial attempt at encrypted transport fails, there will be no
penalty, because the cleartext query is ("happy eyeballs"-style) already
in flight.

If an authoritative server never offers an encrypted transport, each
recursive resolver client will check its status at most once a day (see
the `damping` parameter), and will accept a "port closed" message as a
failure, so it's not going to increase costs for cleartext-only
authoritatives in any significant way.  This should also reduce concerns
about runaway retries consuming excessive resources.

And, if an authoritative that has previously offered encrypted transport
stops offering it, there will be at most a one-time very short delay (a
few seconds, see the `timeout` parameter) for each recursive resolver
that had expected encrypted transport, before it falls back to
cleartext.

So i think the probing described here shouldn't scare anyone off from
deploying at the authoritative.  Is this analysis missing something?

    --dkg

---

From: Robert Evans <[email-masked]>
Date: Fri, 10 Dec 2021 20:11:59 -0500

> servers from deploying encrypted transport.

"4.5.3.4.  Authoritative Server Authentication" is permissive towards
authentication.

If resolver implementers are allowed to implement some varying behaviors
here, authoritative operators will be stuck dealing with the resolvers'
multitude of behaviors. This will make TLS deployment (and changes) brittle
and difficult.

This should ideally be replaced with "resolvers discovering TLS support
solely via unilateral probing MUST NOT perform ANY authentication or
validation whatsoever on the TLS certificate(s) presented by the
authoritative name server".

As an example, certificate pinning by resolvers would cause TLS certificate
auto-rotation to break. Validation might also break "automatic
opportunistic TLS" where the server self-provisions a self-signed cert for
its lifetime and throws it away on restart. When used on an anycast
network, those servers would all have valid certs but every connection
might present unrelated certs. If the resolver tries to be clever, adding
more servers might break everything.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 11 Dec 2021 08:53:18 +0200

> authoritative name server".

This might be a bit excessive -- surely there's no harm in a recursive
resolver trying to validate a given name and then throwing that
information away.  Or, validating a name and sending a report to the
server (via some as-yet-undefined mechanism) if the validation fails.

What the opportunistic unilateral-probing recursive resolver MUST NOT do
is abort the handshake or otherwise delay, penalize, or constrain the
connection due to server authentication failure, right?

> more servers might break everything.

I agree that this would be problematic -- we don't want to encourage
that kind of fragility.

        --dkg

---

From: Robert Evans <[email-masked]>
Date: Sun, 12 Dec 2021 07:58:08 -0500

> connection due to server authentication failure, right?

Yes. It is reasonable to leave room for clients to validate for measurement
or analysis purposes that have no effect on authoritative operators.

Perhaps you can consider changing the "SHOULD NOT" in that section to "MUST
NOT".

Or perhaps it would be better to reframe this section as "MUST accept any
certificate presented" rather than framing this around MAY validate and
MUST NOT reject invalid certs.