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

On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson <sara@sinodun.com> wrote:

>
>
> On 7 Jan 2020, at 22:08, Rob Sayre <sayrer@gmail.com> wrote:
>
> On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <sara@sinodun.com> 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...” ?
>
>
> 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

>
> 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
>
>
> As others have mentioned - this document gives an overall discussion of
> privacy across all DNS protocols, RFC8484 is focussed on the DoH specific
> aspects.
>
>
>
>
>> 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.
>
>
> 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.
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>