On Thu, Jan 9, 2020 at 10:30 AM Eric Rescorla <ekr@xxxxxxxx> wrote:
On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson <sara@xxxxxxxxxxx> 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?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 addressfingerprinting 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
