Subject: [Add] Opportunistic encryption in draft-box-add-requirements

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Sep 2020 17:46:20 +0000

Section 5.1 is tecnically incorrect in multiple places and should be removed. It describes opportunistic encryption incorrectly, and then goes on to say it is out of scope even though others have shown how it could be part of discovery.

The choice whether to do opportunistic encryption belongs completely with the client implementation. If some client implementations want to not use it, but instead want to send queries in the clear for off-path attackers to watch, that's their decision. Other implementations might care more about increasing privacy on the Internet and implement it.

--Paul Hoffman

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 9 Sep 2020 20:17:03 +0000

Hey Paul,

My take on 5.1 is that “there’s no need for standard work on opportunistic encryption because it can already be done.” I do agree that is up to the client interpretation to dice if opportunistic is worth it over just sending clear text.

Do you also disagree with the sentiment I’m grokking here? Is there value in building a mechanism that accomplishes only opportunistic encryption when that is already possible by trying DoT without authentication as listed in the doc?

Thanks,
Tommy Jensen
================================================
How can you secure your DNS queries? https://aka.ms/dohblogpost

________________________________
From: Add <[email-masked]> on behalf of Paul Hoffman <[email-masked]>
Sent: Wednesday, September 9, 2020 10:46 AM
To: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] [Add] Opportunistic encryption in draft-box-add-requirements

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Sep 2020 20:30:45 +0000

On Sep 9, 2020, at 1:17 PM, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:

> Do you also disagree with the sentiment I’m grokking here?

I agree that you are grokking the wording in the -00 draft; that wording is technically wrong and goes in the wrong direction.

> Is there value in building a mechanism that accomplishes only opportunistic encryption when that is already possible by trying DoT without authentication as listed in the doc?

No one has suggested "building a mechanism that accomplishes only opportunistic encryption". This WG is about helping discovery. Discovering a DoH or DoT server is equally valuable for an implementation that is going to insist on authenticating the TLS handshake as to one who doesn't. That is, whether a client implementation allows opportunistic encryption is orthogonal to ADD requirements.

--Paul Hoffman

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 9 Sep 2020 22:46:21 +0000

> Discovering a DoH or DoT server is equally valuable for an implementation that is going to insist on authenticating the TLS handshake as to one who doesn't.

Agreed.

>  That is, whether a client implementation allows opportunistic encryption is orthogonal to ADD requirements.

Sure, but I still think it's important for us to call this out as a non-goal for the WG. If a discovery mechanism designed to empower an authenticated approach happens to work for opportunistic clients, then great. Just my 0.02.

Thanks,
Tommy

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Add <[email-masked]> on behalf of Paul Hoffman <[email-masked]>
Sent: Wednesday, September 9, 2020 1:30 PM
To: Tommy Jensen <Jensen.Thomas=[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] [Ext] Opportunistic encryption in draft-box-add-requirements

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Sep 2020 22:53:57 +0000

On Sep 9, 2020, at 3:46 PM, Tommy Jensen <Jensen.Thomas=[email-masked]> wrote:
> Sure, but I still think it's important for us to call this out as a non-goal for the WG.

Ah, I didn't see that is where you were going. Sure. It is unrelated to discovery, which I think is a fine reason to remove it from the discovery requirements draft.

> If a discovery mechanism designed to empower an authenticated approach happens to work for opportunistic clients, then great.

I think all of the discovery mechanisms do.

> Just my 0.02.

I'll make that 0.04.

--Paul Hoffman

---

From: tirumal reddy <[email-masked]>
Date: Thu, 10 Sep 2020 12:53:31 +0530

On Thu, 10 Sep 2020 at 04:26, Paul Hoffman <[email-masked]> wrote:

> > >  That is, whether a client implementation allows opportunistic
> encryption is orthogonal to ADD requirements.
> >
> Ah, I didn't see that is where you were going. Sure. It is unrelated to
> discovery, which I think is a fine reason to remove it from the discovery
> requirements draft.
>

Good point, we can remove section 5.1.

-Tiru

> > If a discovery mechanism designed to empower an authenticated approach
> happens to work for opportunistic clients, then great.
>
> --Paul Hoffman--
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 10 Sep 2020 03:44:47 -0700

No, it should not be removed. Clarified, sure, but it is important for the security section of the requirements document to explain (as it does) the threat models and goals of the discovery mechanisms. As such, it is important to state that it only makes sense to use authenticated services, not unauthenticated/opportunistic ones, with resolver discovery solutions. While no major discovery proposal currently tries to recommend opportunistic, it has come up in prior discussions and should be explained. 

Tommy

> On Sep 10, 2020, at 12:23 AM, tirumal reddy <[email-masked]> wrote:
> 
> 
> --

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 10 Sep 2020 13:07:47 +0200 (CEST)

>     Il 10/09/2020 12:44 Tommy Pauly <tpauly=[email-masked]> ha scritto:
> 
> 
I have a hard time following this discussion, but perhaps it is because I am not sure of how we define "authenticated".
For example - 3.1 mentions, as one of the benefits to be provided by the discovery mechanism, "Authenticate that the DNS resolver is the one provisioned by the network". So if I use a mechanism like draft-resinfo to send a DNS query to the network's unencrypted resolver (as discovered with traditional means) and I get back a record with a DoH URI, then upgrade the connection to DoH using that URI, does this "authenticate that the DNS resolver is the one provisioned by the network"? If so, how does this differ from "opportunistic"? If not, what would be needed to make this process "authenticated"?

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: tirumal reddy <[email-masked]>
Date: Thu, 10 Sep 2020 17:13:12 +0530

On Thu, 10 Sep 2020 at 16:38, Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> No, it should not be removed. Clarified, sure, but it is important for the
> security section of the requirements document to explain (as it does) the
> threat models and goals of the discovery mechanisms. As such, it is
> important to state that it only makes sense to use authenticated services,
> not unauthenticated/opportunistic ones, with resolver discovery solutions.
> While no major discovery proposal currently tries to recommend
> opportunistic, it has come up in prior discussions and should be
> explained.
>
> I have a hard time following this discussion, but perhaps it is because I
> am not sure of how we define "authenticated".
> For example - 3.1 mentions, as one of the benefits to be provided by the
> discovery mechanism, "Authenticate that the DNS resolver is the one
> provisioned by the network". So if I use a mechanism like draft-resinfo to
> send a DNS query to the network's unencrypted resolver (as discovered with
> traditional means) and I get back a record with a DoH URI, then upgrade the
> connection to DoH using that URI, does this "authenticate that the DNS
> resolver is the one provisioned by the network"?
>

No, the response could have come from an attacker (any on-path attacker can
spoof the response). However, if a secure discovery mechanism is used, it
does authenticate that the DNS resolver is the one provisioned by the
network.

> If so, how does this differ from "opportunistic"?
>

The selection of "opportunistic profile" is independent of the discovery
mechanism. In the best-case scenario for the Opportunistic Privacy profile
(an authenticated and encrypted) it is equivalent to the Strict Privacy
profile. In the worst-case scenario, it is equivalent to cleartext.

> If not, what would be needed to make this process "authenticated"?
>

If an insecure discovery mechanism is used, I would say it is equivalent
to TOFU (Trust on First Use).

-Tiru

> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Sep 2020 12:48:49 +0000

On Sep 10, 2020, at 4:07 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> For example - 3.1 mentions, as one of the benefits to be provided by the discovery mechanism, "Authenticate that the DNS resolver is the one provisioned by the network". So if I use a mechanism like draft-resinfo to send a DNS query to the network's unencrypted resolver (as discovered with traditional means) and I get back a record with a DoH URI, then upgrade the connection to DoH using that URI, does this "authenticate that the DNS resolver is the one provisioned by the network"?

Getting the DoH URI over an unauthenticated channel does not authenticate the DNS resolver: using normal authentication in TLS does.

> If so, how does this differ from "opportunistic"?

In opportunistic, the client tries to authenticate in TLS, but ignores an authentication failure if it happens.

> If not, what would be needed to make this process "authenticated"?

Doing the same authentication in TLS that clients have been doing forever.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Sep 2020 05:56:27 -0700

On Thu, Sep 10, 2020 at 5:49 AM Paul Hoffman <[email-masked]> wrote:

> On Sep 10, 2020, at 4:07 AM, Vittorio Bertola <vittorio.bertola=
> >> No, it should not be removed. Clarified, sure, but it is important for
> the security section of the requirements document to explain (as it does)
> the threat models and goals of the discovery mechanisms. As such, it is
> opportunistic, it has come up in prior discussions and should be explained.
> > I have a hard time following this discussion, but perhaps it is because
> I am not sure of how we define "authenticated".
> Getting the DoH URI over an unauthenticated channel does not authenticate
> the DNS resolver: using normal authentication in TLS does.
>

As far as I can tell, you need both.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Sep 2020 13:03:56 +0000

On Sep 10, 2020, at 3:44 AM, Tommy Pauly <[email-masked]> wrote:
> 
> No, it should not be removed. Clarified, sure, but it is important for the security section of the requirements document to explain (as it does) the threat models and goals of the discovery mechanisms. As such, it is important to state that it only makes sense to use authenticated services, not unauthenticated/opportunistic ones, with resolver discovery solutions.

That's unrelated to using opportunistic encryption for communication with the selected resolver. The section in the -00 draft that mis-defines opportunistic encryption appears to be about communication with the selected resolver. If you want to keep the section, you should make it clearer that you are only talking about the discovery mechanism. In that case, you also say what the requirements for trust anchors for the discovery platform are.

--Paul Hoffman

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 10 Sep 2020 13:05:28 +0000

Paul, I agree with Tommy, we still do want to call this out, but I also see your point and would welcome a rewording.

To the rest, I will elaborate on ekr's point: discovering a server over untrusted channels does not preclude connection to that server being authenticated. For example, the draft I'm contributing to (https://datatracker.ietf.org/doc/draft-pauly-add-resolver-discovery/) defines a mechanism for bootstrapping from an IP address to a DoH connection using TLS to confirm the recommending IP address is controlled by the same entity as the final DoH server.

So this would still be susceptible to local network attackers sending you to their server first. However, it will authenticate that the original advertised server is the same one you're finally connected to. For example, secure acquisition of the IP address via manual entry or VPN profile results in a beginning to end trusted connection.

Note that this only works for publicly routable addresses.

It also maintains the same trust a device expresses in the network today. If we want to prevent local attackers from hijacking DHCP to send to an attacker's DNS server, that is a problem we should solve separately so that the original IP address can be trusted with more authority.

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Paul Hoffman <[email-masked]>
Sent: Thursday, September 10, 2020 6:03 AM
To: Tommy Pauly <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: [Ext] Opportunistic encryption in draft-box-add-requirements

--Paul Hoffman

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 10 Sep 2020 15:07:08 +0200 (CEST)

> Il 10/09/2020 14:48 Paul Hoffman <[email-masked]> ha scritto:
> 

Does this mean that if the DoH resolver suggested through an unauthenticated channel, when establishing the HTTPS connection, shows a valid PKI certificate for its hostname, then it is "authenticated" and we are fine with using it, while if the certificate is self-signed or if it fails this validation, then it is "opportunistic" and we are not?

If so, I am fine with this, but I fail to see which additional security we get from the fact that the resolver's certificate validates, since the concern (as I understood it) was that we would like to be sure that it is actually run by whoever operates the network. In other words: do we want to authenticate the encrypted resolver's hostname, or do we want to authenticate (if ever possible) the encrypted resolver's operator?

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 10 Sep 2020 06:13:11 -0700

> On Sep 10, 2020, at 6:03 AM, Paul Hoffman <[email-masked]> wrote:
> 

It is also indeed talking about the selected resolver—specifically the opportunistic profile defined in section 4.1 of RFC 7858. Such a profile allows a client to not validate the resolver at all: “With such a discovered DNS server, the client might or might not validate the resolver.”

What we want to say here is that the discovery mechanisms that should be defined should have a higher bar for authentication of the resolver, and that such opportunistic approaches that do not require validation of the resolver are already possible and don’t need any new mechanism defined.

Tommy