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

[Rob Sayre <[e-mail]>]

On Thu, Jan 9, 2020 at 10:30 AM Eric Rescorla <[e-mail]> wrote:

>
> On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson <[e-mail]> wrote:
>
>>
>> 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 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?


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