Subject: [dns-privacy] Intermediate proposal (what I was saying at the mic)

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jul 2021 13:08:18 -0700

To recap what I was saying on the list, here's my proposal:

- Recursives can attempt to connect to any authoritative by probing
  with DoT/DoQ [0]. In this case, they should cleanly fall back to
  Do53 on connect failure and not validate the credential (whether
  WebPKI or DANE) This allows authoritatives to just turn on TLS
  without risk.

- The SVCB record is used to signal that the authoritative expects to
  do TLS and indicates the type of credential (WebPKI, DANE, etc.)
  that the authoritative intends to present.  The recursive should
  insist on TLS in this case and hard fail if it cannot negotiate. [1]
  If there is an overlap between the credentials the recursive
  supports and the ones the authoritative advertises, then the
  recursive should validate the credential and fail if it cannot.  If
  there is no overlap, it should not validate the credential.

- (Optional) We should invent some way for the server to say in
  SVCB that it doesn't have any valid credential (e.g., a reserved
  credential type). This would be a signal you wanted unauthenticated.

This would allow for:

- Unauthenticated to work and be discovered.
- An easy upgrade to authenticated after initial contact (a la
  HSTS etc.)
- A path to fully authenticated from initial contact if we
  ever figure out the parent signaling, because you just need
  to propagate the contents of SVCB (or some subset).

-Ekr

[0] As PaulH says, this won't work with DoH because of ambiguity
about the path portion.

[1] This signal should only be accepted over an authenticated
connection, a la HSTS.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Jul 2021 16:19:26 -0400 (EDT)

>   WebPKI or DANE) This allows authoritatives to just turn on TLS

I agree.

And importantly, they can turn on _credentialed_ TLS without risk. If
you would allow to continue "unauthenticated", then the DNS operator still
has a future hard decision to make when to insist on authenticated. They
again have to make a risky decision. The fact that "unauthenticated"
works as standalone or fallback is no guarantee whatsoever that adding
credentials to that setup won't cause complete failure.

>   insist on TLS in this case and hard fail if it cannot negotiate.

Yes, I tried to do exactly this with TLSA records <grumbles about history>
And this is what TLSA for SMTP actually does.

>   there is no overlap, it should not validate the credential.

If there is no overlap, why even try the transport? Just do port 53.
Don't give the user/OS a false sense of privacy if you can't even detect
a MITM.

>   credential type). This would be a signal you wanted unauthenticated.

Now you are advertising which DNS servers can easilly be MITMed. An
attacker can live query the DNS to see if it should commence attacking.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jul 2021 13:23:09 -0700

> If there is no overlap, why even try the transport? Just do port 53.

The usual 7258 reasons, namely that forcing an active attack is good.

> a MITM.

Can you expand on how someone is getting a false sense of security here?
I mean, we're talking about the recursive, right? So generally, the client
won't know what's happening at all.

> attacker can live query the DNS to see if it should commence attacking.

How is this different from seeing who supports TLS but has an invalid cert?
Anyway, I'm not going to fight about this piece.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Jul 2021 22:42:55 +0000

Having a differentiated signal for "I don't expect to be authenticated" would be good for draft-ietf-dprive-unauth-to-authoritative. I also agree with the reasoning of the recursive and auth operators who spoke at the mic.

PaulW's "Now you are advertising which DNS servers can easilly be MITMed" is silly because any attacker could test that trivially.

--Paul Hoffman

---

From: Robert Evans <[email-masked]>
Date: Fri, 30 Jul 2021 14:42:55 -0400

On Thu, Jul 29, 2021 at 6:43 PM Paul Hoffman <[email-masked]> wrote:

> Having a differentiated signal for "I don't expect to be authenticated"
> would be good for draft-ietf-dprive-unauth-to-authoritative. I also agree
> with the reasoning of the recursive and auth operators who spoke at the mic.
>

Suppose ADoX specifies that SVCB with alpn=dot but without any
authentication params implies the same thing. Would that be good enough?

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Jul 2021 20:45:27 +0000

On Jul 30, 2021, at 11:42 AM, Robert Evans <evansr=[email-masked]> wrote:
> Suppose ADoX specifies that SVCB with alpn=dot but without any authentication params implies the same thing. Would that be good enough?
> 

It would be OK. I prefer explicit statements in either direction versus a default that has to be understood because then later possible additional states will be clearer. Also, as others said at this meeting and earlier meetings, the less likely that it is that an authoritative who is just testing can screw this up, the better.

--Paul Hoffman