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

From: Sara Dickinson <[email-masked]>
Date: Wed, 18 Dec 2019 13:45:27 +0000

> 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?

Sara

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Dec 2019 05:51:54 -0800

>    The attack surface for this specific scenario is not considered here."

This seems insufficient. We don't generally assume that the encryption in
mobile access networks is secure, if only for operational complexity
reasons.
So I think this case could do with rather more text.

-Ekr

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Dec 2019 14:00:45 +0000

Hiya,

> 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.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Dec 2019 14:05:09 -0800

> I'm ok that you and the ADs figure out if its needed or

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").

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

Thanks for raising these issues, Stephen and Ekr.

-Ben

---

From: Rob Sayre <[email-masked]>
Date: Mon, 23 Dec 2019 14:12:27 -0800

Hi, here are comments I mistakenly sent to a thread about another dprive
last call. 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.

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.

thanks,
Rob