On Tue, Mar 12, 2019 at 3:51 PM Paul Vixie <p...@redbarn.org> wrote: > On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote: > > On 12/03/2019 21:11, Paul Vixie wrote: > > > ... > > > > There are reasons to want confidentiality for DNS queries > > and answers, and access patterns, for which the IETF has > > achieved consensus. (See RFC7626) (*) > > i have no qualms about confidentiality, for traffic allowed by a network > operator. it's the inability to interefere (as called for in RFC 8484) and > not > the inability to observe (as called for in RFC 7626) that's at issue here. > > > DoT is one way to tackle those problems. DoH is another. > > DoT does not intend to place itself beyond interference by on-path > entities, > and as such, my choice as a network operator is either to allow it through > even though i can't see the contents, or disallow it. and that's all fine. > > I think there is a way to use technical design(s) to split hairs, i.e. I think the side meeting has the possibility of bearing fruit which is palatable enough for all parties.
The crux of the problem is how to determine if the network operator is truly hostile (GFC), or merely restrictive (Paul's network, Paul's rules.) Suppose the client signaled a desire to use a particular DoH operator. The network could respond with, "No", or "Yes", or "Yes, but I want to inspect your DNS traffic", or "No, but I'll place you logically outside my network, and enable the isolated bubble you are in to do what you want." The client could treat "No" as hostile, and do something appropriate for being behind the GFC. The client could treat the "Yes, but" as a reason to then ask for the "bubble" treatment. If the client is offered and accepts, or requests and is permitted, the "bubble" treatment, there is no need to go hostile. In "bubble", the client would not be able to interact with any local resources, in effect being in a non-split-mode VPN to the outside world. There is really nothing that would stop a non-compliant client (or malware) from choosing the "hostile" mode. However, if "bubble" is available, I don't see why that would not be acceptable for any client that isn't malicious. Does "bubble" (and the signaling required) seem like a promising compromise? (Presuming the operator can still refuse "bubble" requests, of course, perhaps with a polite message denying the request with an explanation.) (Also, I would expect the MDM thing can be reduced to whether client(s) are allowed to go hostile or do "bubble" mode.) Brian Brian > DoH intends "to prevent on-path interference with DNS operations", and > that's > well beyond the remit of RFC 7626, and is therefore not spoken to one way > or > another by IETF consensus. i do not believe that a non-interference > objective > would reach broader IETF consensus. perhaps we can test that one day. > > vixie > > > _______________________________________________ > dns-privacy mailing list > dns-priv...@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
