Subject: Re: [Add] Use Cases - the coffee shop: DoH and Authentication

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 10:05:21 +0000

On Aug 15, 2019, at 18:50, Joe Abley <[email-masked]> wrote:
> In your view, what is missing in HTTPS authentication that is needed for DoH?

On Aug 15, 2019, at 18:56, Ted Lemon <[email-masked]>wrote:
> Fortunately DoH provides authentication. 

By itself, DoH does nothing to address the authenticity of a response, which could still be tampered with elsewhere.  Obviously combining DoH (or DoT) with DNSSEC improves this situation.

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 11:14:04 +0100

On Fri, 16 Aug 2019, 11:05 Andrew Campling, .

>
> By itself, DoH does nothing to address the authenticity of a response,
> which could still be tampered with elsewhere.
>

Incorrect, it reduces the attack surface by reducing scope for tampering
with client communications.

-a

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 10:20:22 +0000

On Fri, 16 Aug 2019, 11:14 Alec Muffett <[email-masked]>, . 
>> By itself, DoH does nothing to address the authenticity of a response, which could still be tampered with elsewhere.  
> 
> Incorrect, it reduces the attack surface by reducing scope for tampering with client communications.

Let's not forget that DoH introduces new vulnerabilities within the client device.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 12:25:37 +0200

> Let's not forget that DoH introduces new vulnerabilities within the client

What do you believe those vulnerabilties to be?

-Ekr

-- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 11:26:26 +0100

> Let's not forget that DoH introduces new vulnerabilities within the client

And now you're just casting aspersions.

DoH is an effective "last mile" defence, and to say that it does nothing to
protect DNS lookup "because an attack could happen upstream" is as crazy as
saying "I don't bother to lock my house front door because someone might
rob my bank and it's all the same thing really isn't it?"

It's an improvement over where we have been the last 30+ years, it brings
change and we will adjust to that change. Politicians will adjust to that
change.

If the full extent of the web today had been explained to politicians in
1993, I am confident that they would have tried to prevent it happening -
but I am glad that we are here.

-a

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 04:03:18 -0700

> By itself, DoH does nothing to address the authenticity of a response, which could still be tampered with elsewhere.

Agreed. But the question was about authentication, not integrity
protection. Are we just using the same words for different things?

DoH has no ambition to provide integrity protection, so the simple
observation of that as a weakness seems a bit bizarre. It's like
criticising a particular type of coffee maker for being bad at mashed
potatoes.

Joe

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 11:28:43 +0000

> And now you're just casting aspersions.

I'm sorry if you took brevity for the casting of aspersions, the intention was simply to highlight that the situation was not quite as clear cut as your earlier post implied.  See below for a little more detail, noting Eric asked a related question.  

> What do you believe those vulnerabilties to be?

As an example, see the message posted on 12th June "Google's DOH(like) being used for evil already" - https://mailarchive.ietf.org/arch/msg/add/DeaW7W2OTaxTLmzUjVwEzlPSvWU.  DoH gives a hidden path for malware to exploit - as others have noted, whilst a malware developer could write the code to do something similar, DoH gives them a tool and saves them the effort.  The related thread briefly discusses steps that could be taken to improve this.  

Separately, without rehashing too much ground covered elsewhere, combining DoH (or DoT) with DNSSEC wherever possible would seem to be a sensible step in order to give reassurance of the integrity of the response.  It's also worth considering the elevation of DNS from the OS and into the app layer makes it more vulnerable given the additional protections afforded to the OS on many devices.  I'll leave others to expand on this if they wish.  

By the way, these do not necessarily make DoH bad nor suggest that it should be abandoned.  It is however important to recognise its limitations and trade-offs, otherwise progress cannot be made.  

I'll pause there for now, conscious of the volume of responses dropping into mailboxes today.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 09:17:41 -0400

> By itself, DoH does nothing to address the authenticity of a response, which could still be tampered with elsewhere.  Obviously combining DoH (or DoT) with DNSSEC improves this situation.

DoH lets me know that I am talking to the resolver I intended to talk to, which means that I can reason about whether or not to trust a specific service provider, rather than just hoping for the best.  

You are correct that it doesn’t authenticate the data, and I think I’ve been pretty clear about that in this very conversational thread, so I’m puzzled to see you bring it up.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 15:47:19 +0200

On Fri, Aug 16, 2019 at 1:28 PM Andrew Campling
<[email-masked]> wrote:

> I'm sorry if you took brevity for the casting of aspersions, the intention
> was simply to highlight that the situation was not quite as clear cut as
> your earlier post implied.  See below for a little more detail, noting Eric
> asked a related question.
>
>
> As an example, see the message posted on 12th June "Google's DOH(like)
> being used for evil already" -
> https://mailarchive.ietf.org/arch/msg/add/DeaW7W2OTaxTLmzUjVwEzlPSvWU.
> DoH gives a hidden path for malware to exploit - as others have noted,
> whilst a malware developer could write the code to do something similar,
> DoH gives them a tool and saves them the effort.  The related thread
> briefly discusses steps that could be taken to improve this.
>

I don't think that "introduces new vulnerabilities" is a very accurate
characterization of this message. Rather "makes it harder for existing
mechanisms designed to counter malware" would be more accurate. OTOH,
that's true of encryption in general, and the IETF has, I think, pretty
strong consensus that the balance of cost/benefit is on the "encrypt
things" side.

Separately, without rehashing too much ground covered elsewhere, combining
> DoH (or DoT) with DNSSEC wherever possible would seem to be a sensible step
> in order to give reassurance of the integrity of the response.

Well, we might eventually add DNSSEC to our resolver, but I don't really
see that lack of endpoint DNSSEC resolution is any more of a threat with
DoH than Do53. To the contrary, because the client is free to select a
resolver which it knows validates, the situation with DoH is actually
better.

> It's also worth considering the elevation of DNS from the OS and into the
> app layer makes it more vulnerable given the additional protections
> afforded to the OS on many devices.  I'll leave others to expand on this if
> they wish.
>

This is too vague for me to form an opinion on one way or the other.

-Ekr

> By the way, these do not necessarily make DoH bad nor suggest that it
> should be abandoned.  It is however important to recognise its limitations
> and trade-offs, otherwise progress cannot be made.
>
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Aug 2019 11:12:00 -0400

On Aug 16, 2019, at 07:03, Joe Abley <[email-masked]> wrote:
> observation of that as a weakness seems a bit bizarre.

That we still think of DNS without DNSSEC as a production protocol is one of IETFs biggest mistakes. We should treat DNS without DNSSEC as an implementation error..

We do that for every single other protocol lacking integrity protection.

Paul