Re: [dns-privacy] [Last-Call] last call review of draft-ietf-dprive-rfc7626-bis-03

[Rob Sayre <[e-mail]>]

On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <[e-mail]> 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