Subject: Re: [dns-privacy] [secdir] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:34:58 +0000

> On 23 Dec 2019, at 22:05, Benjamin Kaduk <[email-masked]> wrote:
> 
> On Wed, Dec 18, 2019 at 02:00:45PM +0000, Stephen Farrell wrote:
>> 
>> Hiya,
>> 
>> On 18/12/2019 13:45, Sara Dickinson wrote:
>>> 
>>> 
>>>> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker <[email-masked]> wrote:
>>>> 
>>>> Reviewer: Stephen Farrell
>>>> Review result: Ready
>>> 
>>> Hi Stephen, 
>>> 
>>> Thanks for reviewing (again)!
>>> 
>>>> 
>>>> I might not be the best reviewer for this one as I've read it a few times
>>>> before. But anyway, I scanned the diff [1] with RFC7626 and figure it
>>>> seems fine. 
>>>> 
>>>> The only thing that occurred to me that seemed missing was to note
>>>> that while the new privacy analysis in 3.5.1.1 is already complex, many
>>>> systems are mobile and hence an analysis that ignores that won't be 
>>>> sufficient. For a mobile device one really needs to analyse all of the 
>>>> possible setups, and hence it's even harder to get to a good answer. 
>>>> (It could be that that's elsewhere in the document but since I only 
>>>> read the diff, I didn't see it:-)
>>> 
>>> There was a bit of discussion about this and the following text in 3.4.1 was added:
>>> 
>>> “ It is also noted that typically a device connected _only_ to a modern
>>>   cellular network is
>>> 
>>>   o  directly configured with only the recursive resolvers of the IAP
>>>      and
>>> 
>>>   o  all traffic (including DNS) between the device and the cellular
>>>      network is encrypted following an encryption profile edited by the
>>>      Third Generation Partnership Project (3GPP [2]).
>>> 
>>>   The attack surface for this specific scenario is not considered here."
>>> 
>>> Which hopefully covers this?
>> 
>> Not really, no. My point is that the analysis in 3.5.1.1
>> doesn't encompass the fact that hosts are often (or even
>> mostly) mobile and hence connect to many networks, and that
>> the results of a privacy analysis related to DoT/DoH will
>> likely differ for each of those networks, from the POV
>> of the user or device owner, and even those two may not
>> agree in some cases.
>> 
>> I don't believe that point is made in the document. But
>> I'm ok that you and the ADs figure out if its needed or
>> not.
> 
> I think some kind of treatment is needed, even if the extent of the
> treatment might still be up for debate.
> 
> Sara: note that "mobile" here is used in the generic sense of "moving
> around", not specific to a mobile or "cellular" pocket computer (aka
> "phone”).

Thanks - I did misread Stephens response - I see the issue now.

As a starting point I would suggest some text at the very beginning of Section 3 along these lines. 

“This section outlines the privacy considerations associated with different aspects of the DNS for the end user. When reading this section it needs to be kept in mind that many of the considerations (for example, recursive resolver and transport protocol) can be specific to the network context that a device is using at a given point in time. A user may have many devices and each device might utilise many different networks (e.g. home, work, public or cellular) over a period of time or even concurrently. An exhaustive analysis of the privacy considerations for an individual user would need to take into account the set of devices used and the multiple dynamic contexts of each device. This document does not attempt such a complex analysis, instead it presents an overview of the various considerations that could form the basis of such an analysis. "

> 
> (I also agree with Ekr that the considerations around 3GPP encryption
> remain not great and would prefer to not rely on them.)

I think the idea of the above text was to show there is an orthogonal but out of scope issue with 3GPP encryption, not to make any judgement on it as a technology. Are you saying that the document should make an explicit statement something like ’This form of encryption should not generally be considered secure but an analysis is out of scope for this document. The attack surface for this specific scenario is not considered here.’?

If I have misunderstood, please suggest some text to be used here.

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:34:58 +0000

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:35:50 +0000

> On 23 Dec 2019, at 22:12, Rob Sayre <[email-masked]> wrote:
> 
> Hi, here are comments I mistakenly sent to a thread about another dprive last call.

I took the liberty of removing Stephen, Ben and secdir from the cc list and modifying the subject as I believe this is a general review of the document not one specific to the issues raised by the secdir review. Please correct me if I’m wrong. 

> Summary: the section about "DoH Specific Considerations" is highly questionable, and seems like advocacy rather than a representation of IETF consensus.
> 
> ----
> 
> Hi,
> 
> I found two issues with [this draft]. The document mentions unattributed "concerns" in a few places.. That doesn't seem like helpful content, but I can't say that such "concerns" and rampant use of the passive voice are uncommon in today's IETF. 

I would suggest replacing ‘concerns' with ‘considerations', given that the title of the document is DNS Privacy Considerations.

> 
> Secondly, I found the entire section "3.5.1.5.2.  DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH.

As mentioned since this document is an analysis of the privacy considerations of actually _using_ DNS (not just the protocol definitions) then privacy considerations raised by poor implementations seem entirely in scope. The document does also discuss such issues with TLS, ones with PKI and PGP are clearly out of scope for this document. 

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 7 Jan 2020 18:35:50 +0000

Sara.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 7 Jan 2020 14:08:35 -0800

On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <[email-masked]> wrote:

>
> >
> > Secondly, I found the entire section "3.5.1.5.2.  DoH Specific
> Considerations" to be objectionable, and recommend removing it. It mentions
> many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and
> contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow
> extension fields and metadata, so there's nothing unique to DoH here
> (source: I've implemented DoH and ESNI clients). The entire section amounts
> to a description of fields that privacy conscious DoH clients /might/ send
> if they were poorly implemented. But it seems strange to stop there.
> Implementation quality ratholes can go on for a while: for example, the
> document doesn't mention the numerous problems with today's TLS, PKI, and
> BGP infrastructure that apply to both DoT and DoH.
>
> As mentioned since this document is an analysis of the privacy
> considerations of actually _using_ DNS (not just the protocol definitions)
> then privacy considerations raised by poor implementations seem entirely in
> scope. The document does also discuss such issues with TLS,

The document contains the text:

  "DoT, for example, would normally contain no client identifiers above
   the TLS layer and a resolver would see only a stream of DNS query
   payloads originating within one or more connections from a client IP
   address.  Whereas if DoH clients commonly include several headers in
   a DNS message'

Doesn't this just mean "if the DoT client is a good implementation, and the
DoH client is not..." ?

I think the Section 8.2 of RFC8484 states this problem better. Why do we
need this section?

https://tools.ietf.org/html/rfc8484#section-8.2

> ones with PKI and PGP are clearly out of scope for this document.
>

I didn't mention PGP--I was talking about misrouting (BGP). I disagree that
they are out of scope. Most of the larger TLS use cases rely on PKI.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Tue, 7 Jan 2020 14:08:35 -0800

thanks,
Rob

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Jan 2020 21:58:28 -1000

On 1/7/2020 12:08 PM, Rob Sayre wrote:
> Doesn't this just mean "if the DoT client is a good implementation,
> and the DoH client is not..." ?

I am not sure that this is just about client identifiers, but there is
indeed a difference in complexity between DoH and DoT. Yes you could
minimize it by using an absolutely minimal implementation of HTTP for
DoH, but the very idea of DoH is to reuse existing HTTP infrastructure
for DNS. In practice that means a much larger attack surface.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Jan 2020 21:58:28 -1000

-- Christian Huitema

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 05:12:48 -0800

On Wed, Jan 8, 2020 at 12:00 AM Christian Huitema <[email-masked]>
wrote:

> Doesn't this just mean "if the DoT client is a good implementation, and
> the DoH client is not..." ?
>
>
> minimize it by using an absolutely minimal implementation of HTTP for DoH,
> but the very idea of DoH is to reuse existing HTTP infrastructure for DNS.
> In practice that means a much larger attack surface.
>
I think the concept you're describing is covered by RFC8484, as I wrote.

Is there something in this document's DoH considerations that's new?

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 05:12:48 -0800

thanks,
Rob

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Jan 2020 16:11:24 +0100 (CET)

Il 08/01/2020 14:12 Rob Sayre <[email-masked]> ha scritto:

But basically every DNS RFC from the past few years (e.g. the DoT ones) already has a privacy considerations section or discusses privacy issues. The point of RFC 7626, of which this draft is an update, was to provide the entire analysis in a single document. So why was RFC 7626 made then? Under your logic, it would not make sense to have it at all - but now we have it, and we are stuck with an obsolete version unless we update it.

--

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

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Jan 2020 16:11:24 +0100 (CET)

--

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 08:06:02 -0800

On Wed, Jan 8, 2020 at 7:11 AM Vittorio Bertola <
[email-masked]> wrote:

> But basically every DNS RFC from the past few years (e.g. the DoT ones)
> already has a privacy considerations section or discusses privacy issues.
> The point of RFC 7626, of which this draft is an update, was to provide the
> entire analysis in a single document. So why was RFC 7626 made then? Under
> your logic, it would not make sense to have it at all - but now we have it,
> and we are stuck with an obsolete version unless we update it.
>

RFC 7626 doesn't normatively reference any protocol documents other than
the original DNS RFCs, which do not have privacy or security considerations
sections.

It would be better to include more of this content by reference, or by
quoting the DoT and DoH RFCs directly.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 08:06:02 -0800

thanks,
Rob

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Jan 2020 18:02:19 +0000

> On 7 Jan 2020, at 22:08, Rob Sayre <[email-masked]> wrote:
> 
> On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > 
> > Secondly, I found the entire section "3.5.1.5.2.  DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there.. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH.
> 
> As mentioned since this document is an analysis of the privacy considerations of actually _using_ DNS (not just the protocol definitions) then privacy considerations raised by poor implementations seem entirely in scope. The document does also discuss such issues with TLS,
> 
> Doesn't this just mean "if the DoT client is a good implementation, and the DoH client is not...” ?

It means a standards compliant DoT implementation will have no client identifiers, a standards compliant DoH implementation is free to (and likely) to include them. 

> 
> I think the Section 8.2 of RFC8484 states this problem better. Why do we need this section?
> 
> https://tools.ietf.org/html/rfc8484#section-8.2 <https://tools.ietf.org/html/rfc8484#section-8.2>
As others have mentioned - this document gives an overall discussion of privacy across all DNS protocols, RFC8484 is focussed on the DoH specific aspects. 

> I didn't mention PGP--I was talking about misrouting (BGP). I disagree that they are out of scope. Most of the larger TLS use cases rely on PKI.

I meant BGP - it was a typo.  Section 2 currently states:

“The privacy risks associated with the use of other protocols, e.g.,
   unencrypted TLS SNI extensions or HTTPS destination IP address
   fingerprinting are not considered here.”

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 9 Jan 2020 18:02:19 +0000

Sara.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Jan 2020 10:29:29 -0800

On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson <[email-masked]> wrote:

>> if they were poorly implemented. But it seems strange to stop there..
> the DoH client is not...” ?
>
>
> It means a standards compliant DoT implementation will have no client
> identifiers, a standards compliant DoH implementation is free to (and
> likely) to include them.
>

[Citation needed]

-Ekr

> As others have mentioned - this document gives an overall discussion of
> privacy across all DNS protocols, RFC8484 is focussed on the DoH specific
> aspects.
>
>
>
>
> I didn't mention PGP--I was talking about misrouting (BGP). I disagree
> that they are out of scope. Most of the larger TLS use cases rely on PKI.
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Jan 2020 10:29:29 -0800

[Citation needed]

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Jan 2020 12:13:00 -0800

>> identifiers, a standards compliant DoH implementation is free to (and

I also found this explanation lacking. When the draft states

"the wide practice in HTTP to use various headers to optimize
HTTP connections, functionality and behaviour (which can facilitate user
identification and tracking)"

Which headers is this statement referring to, and which optimizations?

>>    fingerprinting are not considered here.”
Except the draft does spend a lot of time discussing HTTPS, in a
speculative way that frames the issues as though DoT doesn't have these
problems. It's true that there are two places to put metadata in DoH, but
DoT suffers from all the same risks nevertheless.

It's perfectly possible to add metadata to a DoT request at the TLS layer,
and that data could identify users or clients, just as the draft claims is
the case "if DoH clients commonly include several headers in a DNS message
(e.g., user-agent and accept-language)...".

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Jan 2020 12:13:00 -0800

>> that they are out of scope. Most of the larger TLS use cases rely on PKI

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:55:08 +0100

On Thu, Jan 09, 2020 at 10:29:29AM -0800,
 Eric Rescorla <[email-masked]> wrote 
 a message of 181 lines which said:

> > It means a standards compliant DoT implementation will have no
> > client identifiers, a standards compliant DoH implementation is
> > free to (and likely) to include them.
> >
> 
> [Citation needed]

I'm not sure I understand your remark. Do you mean that Sara's
sentence should be backed up with specific references? I mean, since
DoH is HTTP and HTTP (unlike DNS) has a lot of headers that, together,
can identify a client, is it enough to reference HTTP RFCs to support
the claim?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:55:08 +0100

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Jan 2020 09:14:55 -0800

> can identify a client, is it enough to reference HTTP RFCs to support

1. I don't really know what "client identifiers" means. If it means "things
that identify the implementation" then that isn't really correct, because
the TLS ClientHello is quite characteristic.
2. "quite likely" is just speculation and given that Firefox, at least, is
removing the User-Agent string (
https://bugzilla.mozilla.org/show_bug.cgi?id=1543201), I think the evidence
actually points in the other direction.

If it's

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Jan 2020 09:14:55 -0800

If it's

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 12 Jan 2020 19:57:52 -0800

> “This section outlines the privacy considerations associated with different aspects of the DNS for the end user. When reading this section it needs to be kept in mind that many of the consideration…

Okay.

> I think the idea of the above text was to show there is an orthogonal but out of scope issue with 3GPP encryption, not to make any judgement on it as a technology. Are you saying that the document…

I don't think it's necessary to make an explicit statement such as you
propose, but would prefer to just not not say as much about 3GPP encryption
at all.  The current text in the -03 is prefaced with "a device connected
_only_ to a modern cellular network", and while the latest-and-greatest
stuff has less known breakage, in practice current deployments still seem
to allow downgrade attacks to the more-vulnerable older protocols.

> If I have misunderstood, please suggest some text to be used here.

My thinking would be more along the lines of updating the bullet point in
3.4.1 to be like:

o some level of protection against some types of eavesdropping is afforded
  to all traffic (including DNS traffic) due to the cellular network
  link-layer encryption.

This is probably not the document in which to attempt a comprehensive
analysis of cellular traffic (including radio and core network), and with
this wording it probably avoids the need to pull in specific references for
attacks on cellular links, along the lines of
https://www.zdnet.com/article/stingray-security-flaw-cell-networks-phone-tracking-surveillance/,
https://arxiv.org/pdf/1510.07563.pdf, https://alter-attack.net/,
https://blog.cryptographyengineering.com/2013/05/14/a-few-thoughts-on-cellular-encryption/,
https://techcrunch.com/2019/02/24/new-4g-5g-security-flaws/, etc.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 12 Jan 2020 19:57:52 -0800

Okay.

-Ben