Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Tue, 26 Mar 2019 at 10:48, Paul Vixie wrote: > > > Ian Swett wrote on 2019-03-25 01:28: > > One way DoH may be faster than DoT in the near future is that DoH can go > > over HTTP/3 via QUIC and avoid head of line blocking like Do53. > Do53/UDP has no HoL prolem. > > nor does Do853/TCP. > TCP suffers from network head-of-line blocking. -Tiru > > only Do53/TCP had an HoL problem, so, it was never widely used, and has > been replaced by Do853/TCP. > > -- > P Vixie > > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, 25 Mar 2019 at 16:05, Tony Finch wrote: > Ted Lemon wrote: > > > This is equally an argument for doing DNS over DTLS. This would give > > similar performance to DoH over QUIC. > > If I understand it correctly, DTLS leaves MTU and fragmentation up to the > application protocol. The DNS has horrible packet size problems, so it > needs a lot more help than DTLS provides. QUIC is much better. > We had a proposal in our draft https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-02#section-9 to handle fragmentation and reassembly but due to lack of support, it was removed in the next revision. If there is renewed interest in DNS-over-DTLS, we can submit a new draft discussing the fragmentation and reassembly procedure. Cheers, -Tiru > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > The Minch: Westerly 4 or 5, backing southwesterly 5 or 6, occasionally 7 > later > in north. Rough in far north and in far south, otherwise slight or > moderate. > Occasional drizzle. Good, occasionally poor. > > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ian Swett wrote on 2019-03-25 01:28: One way DoH may be faster than DoT in the near future is that DoH can go over HTTP/3 via QUIC and avoid head of line blocking like Do53. Do53/UDP has no HoL prolem. nor does Do853/TCP. only Do53/TCP had an HoL problem, so, it was never widely used, and has been replaced by Do853/TCP. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
It seems like SACK would make the problem less bad in theory, but wouldn’t eliminate the problem. With DNS-over-DTLS, if a packet is lost, the next packet still gets an immediate answer, because DTLS is a datagram protocol, not a stream protocol. The retry strategy for DNS-over-DTLS would be the same as DNS-over-UDP, once the Diffie-Hellman shared key has been derived. So assuming you are using this to communicate to a resolver, there would be an initial handshake that’s extra compared to DNS-over-UDP, and then it would just be DNS-over-UDP until such time as re-keying is needed. > On Mar 25, 2019, at 5:13 PM, Tony Finch wrote: > > Ted Lemon wrote: >> On Mar 25, 2019, at 4:04 PM, Tony Finch wrote: >>> If I understand it correctly, DTLS leaves MTU and fragmentation up to the >>> application protocol. The DNS has horrible packet size problems, so it >>> needs a lot more help than DTLS provides. QUIC is much better. >> >> Indeed. My point was simply that this avoids ordering problems, just as >> QUIC does. I suspect that it is worth having DNS-over-DTLS; QUIC is >> great, but based on what I’ve been seeing, quite a lot, and probably not >> appropriate for a lot of use cases where DNS-over-DTLS would do just >> fine. > > It isn't so much ordering that is the problem, but not delaying answer B > when answer A suffers packet loss. I'm kind of curious about what the > relative trade-offs might be between DoQ and DoT with a decent SACK > implementation, when there is not much latency between the client and the > resolver. DNS-over-DTLS will need its own application layer retry > strategy. I kind of prefer the idea of DNS being able to re-use a good > off-the-shelf transport protocol rather than doing its own thing. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Irish Sea: West or northwest 4 or 5. Smooth or slight. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ted Lemon wrote: > On Mar 25, 2019, at 4:04 PM, Tony Finch wrote: > > If I understand it correctly, DTLS leaves MTU and fragmentation up to the > > application protocol. The DNS has horrible packet size problems, so it > > needs a lot more help than DTLS provides. QUIC is much better. > > Indeed. My point was simply that this avoids ordering problems, just as > QUIC does. I suspect that it is worth having DNS-over-DTLS; QUIC is > great, but based on what I’ve been seeing, quite a lot, and probably not > appropriate for a lot of use cases where DNS-over-DTLS would do just > fine. It isn't so much ordering that is the problem, but not delaying answer B when answer A suffers packet loss. I'm kind of curious about what the relative trade-offs might be between DoQ and DoT with a decent SACK implementation, when there is not much latency between the client and the resolver. DNS-over-DTLS will need its own application layer retry strategy. I kind of prefer the idea of DNS being able to re-use a good off-the-shelf transport protocol rather than doing its own thing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Irish Sea: West or northwest 4 or 5. Smooth or slight. Showers. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mar 25, 2019, at 4:04 PM, Tony Finch wrote: > If I understand it correctly, DTLS leaves MTU and fragmentation up to the > application protocol. The DNS has horrible packet size problems, so it > needs a lot more help than DTLS provides. QUIC is much better. Indeed. My point was simply that this avoids ordering problems, just as QUIC does. I suspect that it is worth having DNS-over-DTLS; QUIC is great, but based on what I’ve been seeing, quite a lot, and probably not appropriate for a lot of use cases where DNS-over-DTLS would do just fine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ted Lemon wrote: > This is equally an argument for doing DNS over DTLS. This would give > similar performance to DoH over QUIC. If I understand it correctly, DTLS leaves MTU and fragmentation up to the application protocol. The DNS has horrible packet size problems, so it needs a lot more help than DTLS provides. QUIC is much better. Tony. -- f.anthony.n.finchhttp://dotat.at/ The Minch: Westerly 4 or 5, backing southwesterly 5 or 6, occasionally 7 later in north. Rough in far north and in far south, otherwise slight or moderate. Occasional drizzle. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Ian Swett wrote: > One way DoH may be faster than DoT in the near future is that DoH can go > over HTTP/3 via QUIC and avoid head of line blocking like Do53. It ought to be better to have native DoQ to eliminate the overhead of the http layer. Dunno whether this should use yet another port (all the obvious ones are already taken) or use ALPN. Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight, Humber: Northwest 6 or 7, occasionally gale 8 at first, decreasing 4 or 5. Rough or very rough, becoming moderate later. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On 25/03/2019 10:41, Patrick McManus wrote: I've seen this confusion before, so I can clear it up! Ray is (I believe) referring to the flexible re-ordering of DNS request-reply pairs of a TCP channel.. similar to HTTP/2 (though with less flexibility in granularity iirc). That addresses hol-blocking problems due to the time the server spends building replies. Ian is (I believe) referring to head of line blocking problems related to TCP's in-order delivery semantic and packet loss. TCP packet loss will delay the delivery of received packets if there are outstanding unreceived lower-numbered packets. If the data in these packets are unrelated (e.g. different DNS request/reply pairs) - that causes head of line blocking to the application. That's true of http/2 and RFC7766 (anything tcp based really). QUIC streams provide a mechanism for identifying which sequences actually need to have that dependency. DoH with H3 would use separate streams for separate requests (as different HTTP exchanges are inherently on different streams). Its a shame that the term hol blocking is used for both scenarios - it has caused a lot of confusion. hth Yes, that dh :) I was indeed talking about DNS message re-ordering, and wasn't aware of this particular distinction at the TCP layer itself when compared to QUIC. thanks, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
This is equally an argument for doing DNS over DTLS. This would give similar performance to DoH over QUIC. On Mon, Mar 25, 2019 at 10:43 Brian Dickson wrote: > > > On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus > wrote: > >> >> >> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson < >> brian.peter.dick...@gmail.com> wrote: >> >>> >>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do >>> not believe anyone has proposed explicit downgrade triggers. >>> >> >> that's the downgrade I am referring to >> >> >> >>> Or do you mean, when a DoT connection is blocked by e.g. a firewall (or >>> other network enforcement device), that an RST is generated? I believe the >>> RST requires sequence number validation before it can be processed by the >>> TCP stack, which means the entity doing the RST generally needs to be in >>> the data path. Other than "lucky guess" or "high volume attempts", I don't >>> believe RST to be a serious threat. >>> >> >> path manipulation attacks are real. arp attacks.. bootp attacks.. rouge >> access points. stingray. all kinds of things. unauthenticated network >> packets are just that: unauthenticated. RST (or blackhole) is a good >> indication that a path isn't going to work - its not a good indication of >> who is expressing that policy (or whether it is a policy at all). >> >> Anyhow - I'm really not trying to amp up this thread.. I just felt that >> there were a few relevant points to the discussion that had not been >> introduced. >> > > Okay, that's good to know, and I think we are in agreement (i.e. that > inference is a poor substitute for declarations.) > > I think that this is an area that needs thought and mechanism development, > possibly aligned with DoT/DoH operation, possibly not (or orthogonal to > them). > > Brian > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus wrote: > > > On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >>> >>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do >> not believe anyone has proposed explicit downgrade triggers. >> > > that's the downgrade I am referring to > > > >> Or do you mean, when a DoT connection is blocked by e.g. a firewall (or >> other network enforcement device), that an RST is generated? I believe the >> RST requires sequence number validation before it can be processed by the >> TCP stack, which means the entity doing the RST generally needs to be in >> the data path. Other than "lucky guess" or "high volume attempts", I don't >> believe RST to be a serious threat. >> > > path manipulation attacks are real. arp attacks.. bootp attacks.. rouge > access points. stingray. all kinds of things. unauthenticated network > packets are just that: unauthenticated. RST (or blackhole) is a good > indication that a path isn't going to work - its not a good indication of > who is expressing that policy (or whether it is a policy at all). > > Anyhow - I'm really not trying to amp up this thread.. I just felt that > there were a few relevant points to the discussion that had not been > introduced. > Okay, that's good to know, and I think we are in agreement (i.e. that inference is a poor substitute for declarations.) I think that this is an area that needs thought and mechanism development, possibly aligned with DoT/DoH operation, possibly not (or orthogonal to them). Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:58 AM Ray Bellis wrote: > > > On 25/03/2019 09:28, Ian Swett wrote: > > One way DoH may be faster than DoT in the near future is that DoH can go > > over HTTP/3 via QUIC and avoid head of line blocking like Do53. > > Head of line blocking shouldn't happen on a modern Do53 server. > > See RFC 7766 §6.2.1.1 > > I've seen this confusion before, so I can clear it up! Ray is (I believe) referring to the flexible re-ordering of DNS request-reply pairs of a TCP channel.. similar to HTTP/2 (though with less flexibility in granularity iirc). That addresses hol-blocking problems due to the time the server spends building replies. Ian is (I believe) referring to head of line blocking problems related to TCP's in-order delivery semantic and packet loss. TCP packet loss will delay the delivery of received packets if there are outstanding unreceived lower-numbered packets. If the data in these packets are unrelated (e.g. different DNS request/reply pairs) - that causes head of line blocking to the application. That's true of http/2 and RFC7766 (anything tcp based really). QUIC streams provide a mechanism for identifying which sequences actually need to have that dependency. DoH with H3 would use separate streams for separate requests (as different HTTP exchanges are inherently on different streams). Its a shame that the term hol blocking is used for both scenarios - it has caused a lot of confusion. hth -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson wrote: > > >> >> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do > not believe anyone has proposed explicit downgrade triggers. > that's the downgrade I am referring to > Or do you mean, when a DoT connection is blocked by e.g. a firewall (or > other network enforcement device), that an RST is generated? I believe the > RST requires sequence number validation before it can be processed by the > TCP stack, which means the entity doing the RST generally needs to be in > the data path. Other than "lucky guess" or "high volume attempts", I don't > believe RST to be a serious threat. > path manipulation attacks are real. arp attacks.. bootp attacks.. rouge access points. stingray. all kinds of things. unauthenticated network packets are just that: unauthenticated. RST (or blackhole) is a good indication that a path isn't going to work - its not a good indication of who is expressing that policy (or whether it is a policy at all). Anyhow - I'm really not trying to amp up this thread.. I just felt that there were a few relevant points to the discussion that had not been introduced. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On 25 Mar 2019, at 10:25, Stephen Farrell wrote: > I see a problem with the above argument. DNS means nothing to > most people, so I can't see how they can ever make the informed > decision you mention. I view that as a research question (I don’t accept your assertion, but neither can I disprove it). That is- could a question be formed around local network trust that encompasses this component? Possibly. Eliot ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Hiya, On 25/03/2019 09:13, Eliot Lear wrote: > Putting aside legal language, but Brian’s basic notion is that the > user can make an informed decision and the network can express its > policies, with which the user can agree or not agree (and go > elsewhere). Having the protocol elements to permit this sort of > agreement is its own tussle. I see a problem with the above argument. DNS means nothing to most people, so I can't see how they can ever make the informed decision you mention. Cheers, S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Hi, > On 24 Mar 2019, at 23:25, Paul Wouters wrote: > >> The blocking of DoT to a given provider should be interpreted as an explicit >> policy. Users should be informed >> that they may, and very likely will, be violating someone’s policy, if they >> choose to use DoH in that >> circumstance, and that they may be violating laws by doing so, and should >> only do so if they are willing to >> accept that risk. > > Again, this is the network operator centric view. There are many hostile > networks that would block DoT just so that they could monetize (legally > or illegally!) from my harvested DNS data. I can assure you the warning > you want to write to users would be very different from the warning I > would want to give those users. Which is why the IETF doesn't do > banners towards endusers. Putting aside legal language, but Brian’s basic notion is that the user can make an informed decision and the network can express its policies, with which the user can agree or not agree (and go elsewhere). Having the protocol elements to permit this sort of agreement is its own tussle. Eliot___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu
wrote:
> On Mon, 25 Mar 2019 at 09:15, Brian Dickson
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
>> wrote:
>>
>>> I'm not pushing against DoT per se in this thread, I am pushing against
>>> the notion that a client has an obligation to the network to provide a
>>> clear channel for traffic analysis and downgrade triggers.
>>>
>>> fwiw - there are lots of reasons an http client is going to be
>>> interested in an http substrate beyond just traffic analysis defense. It
>>> has the potential for better overall application responsiveness - by
>>> sharing connections and handshakes with other http data. I don't think that
>>> particular discussion is important to this thread.
>>>
>>
>>
>> The DoH operators who have made public statements (google and cloudflare
>> are two I am aware of), have specifically indicated that NO OTHER HTTPS
>> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
>>
>> So, the handshakes and sharing argument is specious at best, and bogus at
>> worst.
>>
>
> That may be true for Google and Cloudflare right now. But if I will be
> running my own DoH server it would probably be on AWS or compute engine
> along with any other website I'm currently running, so the connection
> sharing WILL happen.
>
Okay, that's a useful anecdote/datapoint.
Have you considered whether you will need to operate DoT as well, in case
DoH is blocked from some networks that do not also block DoT?
I.e. fallback from DoH to DoT rather than fall all the way back to Do53?
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On 25/03/2019 09:28, Ian Swett wrote: One way DoH may be faster than DoT in the near future is that DoH can go over HTTP/3 via QUIC and avoid head of line blocking like Do53. Head of line blocking shouldn't happen on a modern Do53 server. See RFC 7766 §6.2.1.1 Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, 25 Mar 2019 at 09:15, Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in this thread, I am pushing against
>> the notion that a client has an obligation to the network to provide a
>> clear channel for traffic analysis and downgrade triggers.
>>
>> fwiw - there are lots of reasons an http client is going to be interested
>> in an http substrate beyond just traffic analysis defense. It has the
>> potential for better overall application responsiveness - by sharing
>> connections and handshakes with other http data. I don't think that
>> particular discussion is important to this thread.
>>
>
> Actually, it really is.
>
> At a minimum it needs to be treated as an assertion that is subject to
> validation or refutation.
>
> This is a refutation:
>
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
>
> So, the handshakes and sharing argument is specious at best, and bogus at
> worst.
>
That may be true for Google and Cloudflare right now. But if I will be
running my own DoH server it would probably be on AWS or compute engine
along with any other website I'm currently running, so the connection
sharing WILL happen.
> The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
> DoT does not require the encoding/decoding of the DNS messages (plus all
> the other HTTP overhead).
> Both DoT and DoH require DNS messages in wire format be constructed first,
> and after whatever decoding, wire format responses processed by the client.
>
> A cursory analysis of the logic -- extra encoding vs no extra encoding --
> essentially proves by "the triangle inequality"* that DoH cannot be faster
> than DoT when comparing same-client to same-server.
>
> Brian
>
> *(the sum of lengths of two sides is greater or equal to the length of the
> third side) In this case two sides are the same length (processing of TLS
> and DNS) and the other side is extra processing of HTTP encoding, headers,
> etc., and the sum is (HTTP + common path) , compared with (common path).
> HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
>
>
>>
>> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>>> wrote:
>>>
>>>
>>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
This is important for network operators in identifying encrypted DNS
traffic,
>>>
>>> not all clients acknowledge a network's right to do such things at all
>>> times. And of course it would be useful to tell the difference between
>>> policy and a RST injection attack.
>>>
>>> If the client does acknowledge the network has the right to set policy -
>>> then the policy can be set on the client using existing configuration
>>> mechanisms that allow the client to differentiate between authorized
>>> configuration and perhaps less-authorized folks identifying their DNS
>>> traffic. This is well worn ground in the HTTP space.
>>>
>>>
>>> What I find interesting, is that as far as I can tell, everything you
>>> wrote applies equally to DoH and DoT, if the transport is the only
>>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>>> DoT.
>>>
>>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>>
>>> Brian
>>>
>> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
I have seen such a public statement from Google. Where have you seen a
similar statement from Mozilla/Cloudflare?
I asked for such a statement from Mozilla recently (on this mailing
list). No answer yet.
Steinar Haug, AS2116
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
I think it would be better to not combine (and conflate) two or more issues
(which may not be directly related).
Plus, this is approaching a "straw man" argument: the notion of
"obligation".
I might not have been clear enough previously. I am arguing against
obligating client applications to take actions that users have not
explicitly given permission to do.
In this case, the action is: "Use Do{HT} service X".
If X is not on the user's list of Do{HT} providers the user has
selected/configured, then my position is the user MUST be prompted prior to
using X, or absent a user interaction mechanism (UI), then X MUST NOT be
used. This includes the case where X is Do53 (regular DNS), if the user has
selected/configured that Do{HT} is required.
In other words, I am proposing that clients not be built so as to be
susceptible to downgrade attacks (whether by the network operator, or by an
attacker). This is directly analogous to attacks on TLS itself for
downgrading TLS versions or cipher selections. In fact, IMHO, Do{TH} should
take a page from the whole TLS state machine, where the client selects
among the servers' offered parameters, possibly deciding to not complete
the handshake if any of a host of issues are discovered (cert validation,
among others).
>
> One of the notions presented here is that unauthenticated RST injection
> forgery is an acceptable, perhaps in the minds of some even desirable,
> signal for DoT to trigger downgrades and, further, that clients are
> obligated to create a clear signal to the network to enable this approach.
>
This is a separate issue.
Other than blocking all-but-a-few (or all, or a few) DoT servers, I do not
believe anyone has proposed explicit downgrade triggers. Or do you mean,
when a DoT connection is blocked by e.g. a firewall (or other network
enforcement device), that an RST is generated? I believe the RST requires
sequence number validation before it can be processed by the TCP stack,
which means the entity doing the RST generally needs to be in the data
path. Other than "lucky guess" or "high volume attempts", I don't believe
RST to be a serious threat.
> One issue is that you cannot differentiate this signal between a party you
> may want to cooperate with (e.g. your enterprise controller) and an
> attacker - that's the nature of an unauthenticated injection. But there are
> authenticated enterprise configuration methods available for expressing
> policy directly to the client in a trusted way. Indeed my post centered
> around the notion of https interception being a necessary outcome of DoH in
> the enterprise - my point is basically if you can do https interception
> then you are doing enterprise config - consider a config to still do
> secured DNS with a server that implements the enterprise policy rather than
> doing interception.
>
I agree that there is a need for both service discovery (local and
pre-selected Do{TH} providers), and service *policy* discovery, ideally
authenticated and secured (subject to provider implementations adhering to
mechanisms to provide secure authenticity proofs).
>
> And if you do that an enterprise client can, by using its own do{th}
> server, also enjoy the benefits of transport security and be confident that
> the policy server it intends to use is actually the one in use.
>
I agree with this.
I believe there is widespread interest in solving this problem.
However, I believe there is a need for the solution to this problem being
coordinated between the DoH and DoT groups, seeing as the DNS operators
have a significant interest in both DoT and DoH being served on their
servers, and thus a strong interest in any relevant components (discovery,
validation, etc.) being uniformly specified across both protocols.
It might be worth having an AD/WG discussion on where these should be
developed; it might be better to do in DNSOP, rather than DPRIVE or DOH, or
alternatively spinning up a new, very focused WG for this work (I would not
be in favor of the latter).
Brian
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>> wrote:
>>
>>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>> This is important for network operators in identifying encrypted DNS
>>> traffic,
>>>
>>
>> not all clients acknowledge a network's right to do such things at all
>> times. And of course it would be useful to tell the difference between
>> policy and a RST injection attack.
>>
>> If the client does acknowledge the network has the right to set policy -
>> then the policy can be set on the client using
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
On Mon, Mar 25, 2019 at 4:15 AM Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in this thread, I am pushing against
>> the notion that a client has an obligation to the network to provide a
>> clear channel for traffic analysis and downgrade triggers.
>>
>> fwiw - there are lots of reasons an http client is going to be interested
>> in an http substrate beyond just traffic analysis defense. It has the
>> potential for better overall application responsiveness - by sharing
>> connections and handshakes with other http data. I don't think that
>> particular discussion is important to this thread.
>>
>
> Actually, it really is.
>
> At a minimum it needs to be treated as an assertion that is subject to
> validation or refutation.
>
> This is a refutation:
>
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
>
> So, the handshakes and sharing argument is specious at best, and bogus at
> worst.
>
> The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
> DoT does not require the encoding/decoding of the DNS messages (plus all
> the other HTTP overhead).
> Both DoT and DoH require DNS messages in wire format be constructed first,
> and after whatever decoding, wire format responses processed by the client.
>
> A cursory analysis of the logic -- extra encoding vs no extra encoding --
> essentially proves by "the triangle inequality"* that DoH cannot be faster
> than DoT when comparing same-client to same-server.
>
> Brian
>
> *(the sum of lengths of two sides is greater or equal to the length of the
> third side) In this case two sides are the same length (processing of TLS
> and DNS) and the other side is extra processing of HTTP encoding, headers,
> etc., and the sum is (HTTP + common path) , compared with (common path).
> HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
>
>
>>
>> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>>> wrote:
>>>
>>>
>>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>
This is important for network operators in identifying encrypted DNS
traffic,
>>>
>>> not all clients acknowledge a network's right to do such things at all
>>> times. And of course it would be useful to tell the difference between
>>> policy and a RST injection attack.
>>>
>>> If the client does acknowledge the network has the right to set policy -
>>> then the policy can be set on the client using existing configuration
>>> mechanisms that allow the client to differentiate between authorized
>>> configuration and perhaps less-authorized folks identifying their DNS
>>> traffic. This is well worn ground in the HTTP space.
>>>
>>>
>>> What I find interesting, is that as far as I can tell, everything you
>>> wrote applies equally to DoH and DoT, if the transport is the only
>>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>>> DoT.
>>>
>>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>>
>>> Brian
>>>
>> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
> fwiw - there are lots of reasons an http client is going to be interested
> in an http substrate beyond just traffic analysis defense. It has the
> potential for better overall application responsiveness - by sharing
> connections and handshakes with other http data. I don't think that
> particular discussion is important to this thread.
>
Actually, it really is.
At a minimum it needs to be treated as an assertion that is subject to
validation or refutation.
This is a refutation:
The DoH operators who have made public statements (google and cloudflare
are two I am aware of), have specifically indicated that NO OTHER HTTPS
TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
So, the handshakes and sharing argument is specious at best, and bogus at
worst.
The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
DoT does not require the encoding/decoding of the DNS messages (plus all
the other HTTP overhead).
Both DoT and DoH require DNS messages in wire format be constructed first,
and after whatever decoding, wire format responses processed by the client.
A cursory analysis of the logic -- extra encoding vs no extra encoding --
essentially proves by "the triangle inequality"* that DoH cannot be faster
than DoT when comparing same-client to same-server.
Brian
*(the sum of lengths of two sides is greater or equal to the length of the
third side) In this case two sides are the same length (processing of TLS
and DNS) and the other side is extra processing of HTTP encoding, headers,
etc., and the sum is (HTTP + common path) , compared with (common path).
HTTP is not a zero-cost flow, so HTTP + x > x. QED.
>
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 24, 2019, at 10:42 PM, Patrick McManus
>> wrote:
>>
>>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>> This is important for network operators in identifying encrypted DNS
>>> traffic,
>>>
>>
>> not all clients acknowledge a network's right to do such things at all
>> times. And of course it would be useful to tell the difference between
>> policy and a RST injection attack.
>>
>> If the client does acknowledge the network has the right to set policy -
>> then the policy can be set on the client using existing configuration
>> mechanisms that allow the client to differentiate between authorized
>> configuration and perhaps less-authorized folks identifying their DNS
>> traffic. This is well worn ground in the HTTP space.
>>
>>
>> What I find interesting, is that as far as I can tell, everything you
>> wrote applies equally to DoH and DoT, if the transport is the only
>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>> DoT.
>>
>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>
>> Brian
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.
One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable, perhaps in the minds of some even desirable,
signal for DoT to trigger downgrades and, further, that clients are
obligated to create a clear signal to the network to enable this approach.
One issue is that you cannot differentiate this signal between a party you
may want to cooperate with (e.g. your enterprise controller) and an
attacker - that's the nature of an unauthenticated injection. But there are
authenticated enterprise configuration methods available for expressing
policy directly to the client in a trusted way. Indeed my post centered
around the notion of https interception being a necessary outcome of DoH in
the enterprise - my point is basically if you can do https interception
then you are doing enterprise config - consider a config to still do
secured DNS with a server that implements the enterprise policy rather than
doing interception.
And if you do that an enterprise client can, by using its own do{th}
server, also enjoy the benefits of transport security and be confident that
the policy server it intends to use is actually the one in use.
fwiw - there are lots of reasons an http client is going to be interested
in an http substrate beyond just traffic analysis defense. It has the
potential for better overall application responsiveness - by sharing
connections and handshakes with other http data. I don't think that
particular discussion is important to this thread.
On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson
wrote:
>
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 10:42 PM, Patrick McManus
> wrote:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> This is important for network operators in identifying encrypted DNS
>> traffic,
>>
>
> not all clients acknowledge a network's right to do such things at all
> times. And of course it would be useful to tell the difference between
> policy and a RST injection attack.
>
> If the client does acknowledge the network has the right to set policy -
> then the policy can be set on the client using existing configuration
> mechanisms that allow the client to differentiate between authorized
> configuration and perhaps less-authorized folks identifying their DNS
> traffic. This is well worn ground in the HTTP space.
>
>
> What I find interesting, is that as far as I can tell, everything you
> wrote applies equally to DoH and DoT, if the transport is the only
> difference. E.g. Same client browser, same DNS service, accessed via DoH or
> DoT.
>
> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
> On 25 Mar 2019, at 6:06 pm, Daniel Stenberg wrote: > > On Sun, 24 Mar 2019, Vittorio Bertola wrote: > >> In today's "plain DNS" world, I choose a DNS resolver that provides that >> kind of filters for me, I set it up on my router, and my router pushes it to >> my smart TV via DHCP. What is the "existing configuration mechanism" that >> allows me to set this policy in the DoH world, i.e. if the TV came equipped >> with applications preconfigured to use their own remote resolver via DoH? > > We can easily turn this example the other way around. > > With Do53 in your TV, your kids can easily fool your TV with their own DHCP > responses or by intercepting and intefering with the DNS traffic while you're > at work. > > With DoH used in the TV, set to use a trusted server, they can’t. Which won’t work if the network is filtering Do53 traffic to non approved servers or if the TV is manually configured with Do53 or DoT servers and the TV’s configuration is locked down. Yes, TV’s do have the ability to lock this part of the configuration down same as filters on program ratings can be enforced provided the data stream includes the rating information. The problem with DoH is that it makes filtering difficult. That is both a good and a bad thing depending on your perspective and responsibilities. It’s a pandora’s box. > -- > > / daniel.haxx.se > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, 24 Mar 2019, Vittorio Bertola wrote: In today's "plain DNS" world, I choose a DNS resolver that provides that kind of filters for me, I set it up on my router, and my router pushes it to my smart TV via DHCP. What is the "existing configuration mechanism" that allows me to set this policy in the DoH world, i.e. if the TV came equipped with applications preconfigured to use their own remote resolver via DoH? We can easily turn this example the other way around. With Do53 in your TV, your kids can easily fool your TV with their own DHCP responses or by intercepting and intefering with the DNS traffic while you're at work. With DoH used in the TV, set to use a trusted server, they can't. -- / daniel.haxx.se ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Sent from my iPhone > On Mar 24, 2019, at 10:42 PM, Patrick McManus wrote: > > >> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson >> wrote: >> >> This is important for network operators in identifying encrypted DNS traffic, > > not all clients acknowledge a network's right to do such things at all times. > And of course it would be useful to tell the difference between policy and a > RST injection attack. > > If the client does acknowledge the network has the right to set policy - then > the policy can be set on the client using existing configuration mechanisms > that allow the client to differentiate between authorized configuration and > perhaps less-authorized folks identifying their DNS traffic. This is well > worn ground in the HTTP space. What I find interesting, is that as far as I can tell, everything you wrote applies equally to DoH and DoT, if the transport is the only difference. E.g. Same client browser, same DNS service, accessed via DoH or DoT. Are you suggesting (or claiming) otherwise, and if so, please elaborate? Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, Mar 24, 2019 at 11:25 PM Paul Wouters wrote: > On Sun, 24 Mar 2019, Brian Dickson wrote: > > > There is one important difference, which is that DoT uses a unique port > number. This is important for network > > operators in identifying encrypted DNS traffic, in order to ensure that > implementation of security policies for > > DNS don’t conflict with any other network policies (regardless of what > those policies are.) > > The network cannot "ensure" this based on DNS. I can come on to the > network with a DNS cache already, which is the functional equivalent > of me refreshing my personal cache using a sneaky HTTPS connection. > The network can never control my DNS cache. I won't let it. > > So while it was perhaps nice that network operators _could_ help in such > a case, it was never a real defense against a smart network "abuser". > > I am trying to keep conversation sub-threads specific to single variables. In this case, I am interested in policy enforcement mechanisms, not what the policy is or who it applies to. The assumption in the above is that the network operator has some policy (regardless of what it is) that it would like to enforce between some (or possibly all) hosts, towards encrypted DNS services. If the operator blocks all DoH, but does something less restrictive for DoT, then the policies applied on DoT are the ones that have the desired effect. Yes, this is network-centric, or more specific, network-security-centric. >From the perspective of the network policy enforcement, the applicable rules involve 3-tuples of source, destination, and port 853 (plus TCP but not UDP). Any such rules, when explicitly applied only to port 853, by definition have no direct bearing on any destinations for port 443 (HTTPS). These rules only need to be updated if/when new "permit" rules for new DoT servers are added. This is a white-list model, which scales very nicely. However, the blocking of specific DoH servers becomes an absolute nightmare, in that the network operator needs continuously monitor information from any number of sources (of various degrees of completeness, trustworthiness, timeliness, etc), for new DoH servers, along with an ongoing policy maintenance on (allow vs deny). This is, by its very nature, a black-list model, which does not scale nicely, and consequently reduces the overall security, from the perspective of the network operator (or network security department of the enterprise network). (See my previous message detailing *why* networks NEED to do this, at least in the large enterprise.) Chances are, the network segment you are on does not care one whit about the DNS cache you have, and probably is happy to let you access whoever you want for your encrypted DNS service. I'm willing to wager, in the enterprise environment, they do have an opinion on what transport they prefer you use for that: DoT. This is mostly about scalability, and about the ability to detect abnormal behavior distinct from regular user activity (malware, phishing, and other use cases.) > > IMNSHO, if both ports are reachable for a given provider of Do*, the DoT > port MUST be used. DoH should only be > > used with explicit informed user consent, and only when DoT is > unavailable.. This supports the “dissident” use > > case, without impacting any other aspects of privacy provided by DoT. > > If the network allows DoT, clearly it does not care about DoH being > used? Since it will also not be able to read DoT to a remote server > like the Quads. So I do not understand what is gained by such a > policy. > It is about scale. If large numbers of users, across a variety of platforms, all use only DoT, then restrictions about which DoT servers are permitted can be applied. Or, alternatively, access to new DoT servers can potentially alert the appropriate security team(s) to investigate which machines have started this new behavior, and get an early jump on things if this happens to be a malware-infected device (for example). Blocking specific DoT servers (or more typically, blocking all DoT servers except those white-listed) allows end users to know that this blockage is deliberate. Users can then make informed decisions about whether to accept that blockage (e.g. due to enterprise policies, or perhaps ISP policies where those are allowed according to contract and jurisdictional legal frameworks), or to take unilateral action to bypass the blockage. What is gained by preferring DoT over DoH, is scaling on the network operator side, and clear indication of policy via DoT blocking. Scaling for network operators is always an indirect win for users -- users have to pay, directly or indirectly, for situations where technology does not (and cannot) scale. > > Unless you meant "must use a local DoT server first", in which case we > are again shifting the discussion towards when can or should you trust > a network for anything but relaying IP packets. Because then you > basically demand access
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, Mar 24, 2019 at 11:14 PM Vittorio Bertola wrote: > > In today's "plain DNS" world, I choose a DNS resolver that provides that kind > of filters for me, I set it up on my router, and my router pushes it to my > smart TV via DHCP. What is the "existing configuration mechanism" that allows > me to set this policy in the DoH world, i.e. if the TV came equipped with > applications preconfigured to use their own remote resolver via DoH? > > As a minimum, I would have to open all the applications and configure them > one by one to use my desired resolver, and repeat this for every device > connected to my network - while in the current situation this is all > automated after I configure the resolver once on my router. But applications > like Firefox might completely refuse to use the resolver I want, advertised > by my router on my behalf, because it does not support DoH, or it does but is > not on their list of "trusted resolvers". And Javascript bits in the pages I > visit might use DoH to pre-encoded servers without even offering me any > configuration. > I think configuring every application, operating system, or platform to do the filtering is the right way regardless of the existence of DoH. I wouldn't trust that the opinion given by a DHCP server is what will be really used by all clients. If you need to check that's what is really happening, wouldn't it require about the same effort to configure the parental control features that are already provided by many vendors. I also believe that's a lot easier thing to do for the average user. If you really want a DIY solution, why don't you look into the actual HTTP(S) traffic and SNIs? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, 24 Mar 2019, Brian Dickson wrote: There is one important difference, which is that DoT uses a unique port number. This is important for network operators in identifying encrypted DNS traffic, in order to ensure that implementation of security policies for DNS don’t conflict with any other network policies (regardless of what those policies are.) The network cannot "ensure" this based on DNS. I can come on to the network with a DNS cache already, which is the functional equivalent of me refreshing my personal cache using a sneaky HTTPS connection. The network can never control my DNS cache. I won't let it. So while it was perhaps nice that network operators _could_ help in such a case, it was never a real defense against a smart network "abuser". IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port MUST be used. DoH should only be used with explicit informed user consent, and only when DoT is unavailable.. This supports the “dissident” use case, without impacting any other aspects of privacy provided by DoT. If the network allows DoT, clearly it does not care about DoH being used? Since it will also not be able to read DoT to a remote server like the Quads. So I do not understand what is gained by such a policy. Unless you meant "must use a local DoT server first", in which case we are again shifting the discussion towards when can or should you trust a network for anything but relaying IP packets. Because then you basically demand access to my decrypted DNS stream. Why should I ever use a starbucks DNS server, regardless of whether I use DoT or DoH or plain 53? On almost every network I connect to, I only want one service: "relay my (encrypted) IP packets". The rest of the services I obtain from trusted sources elsewhere, using this ephemeral network as an insecure transport only. So your policy above that you propose really assumes a lot about the network, namely that you are considered hostile to the network and that you trust that network more than your own device. That's a very specific application. It basically never applies to me unless I join an enterprise network with an enterprise device, and then we have other ways for the enterprise to enforce things on their device. The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to accept that risk. Again, this is the network operator centric view. There are many hostile networks that would block DoT just so that they could monetize (legally or illegally!) from my harvested DNS data. I can assure you the warning you want to write to users would be very different from the warning I would want to give those users. Which is why the IETF doesn't do banners towards endusers. Besides, why should the network operator have a say about when I want my device to connect to my remote servers? Do you want my VPN client to throw the same warning around that it might be against the network operator's wishes to inspect all my traffic and it might be against the law to circumvent it? Then you also have to do that for _all_ TLS connections, and make the internet go back to port 80. Why is there a different expectation of website content monitoring versus dns content monitoring? You shouldn't have access to either. There is no reason DoH should be used if DoT works (towards the same DNS provider). If DoT works to dot.nohats.ca, which you cannot decrypt, why do you care whether I use DoH to that server or not? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
> Il 24 marzo 2019 alle 22.42 Patrick McManus ha scritto: > > > On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < > brian.peter.dick...@gmail.com mailto:brian.peter.dick...@gmail.com > wrote: > > > > > > > > This is important for network operators in identifying encrypted > > DNS traffic, > > > > > > not all clients acknowledge a network's right to do such things at all > times. And of course it would be useful to tell the difference between policy > and a RST injection attack. > > If the client does acknowledge the network has the right to set policy - > then the policy can be set on the client using existing configuration > mechanisms that allow the client to differentiate between authorized > configuration and perhaps less-authorized folks identifying their DNS > traffic. This is well worn ground in the HTTP space. > Let's say I just bought a new smart TV that can browse the Internet, but I don't want my kids to be able to access inappropriate websites from it. Or, let's say I actually like the fact that my operator filters out malware destinations at the DNS level and I want my new TV to have that protection as well. In today's "plain DNS" world, I choose a DNS resolver that provides that kind of filters for me, I set it up on my router, and my router pushes it to my smart TV via DHCP. What is the "existing configuration mechanism" that allows me to set this policy in the DoH world, i.e. if the TV came equipped with applications preconfigured to use their own remote resolver via DoH? As a minimum, I would have to open all the applications and configure them one by one to use my desired resolver, and repeat this for every device connected to my network - while in the current situation this is all automated after I configure the resolver once on my router. But applications like Firefox might completely refuse to use the resolver I want, advertised by my router on my behalf, because it does not support DoH, or it does but is not on their list of "trusted resolvers". And Javascript bits in the pages I visit might use DoH to pre-encoded servers without even offering me any configuration. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < brian.peter.dick...@gmail.com> wrote: > > This is important for network operators in identifying encrypted DNS > traffic, > not all clients acknowledge a network's right to do such things at all times. And of course it would be useful to tell the difference between policy and a RST injection attack. If the client does acknowledge the network has the right to set policy - then the policy can be set on the client using existing configuration mechanisms that allow the client to differentiate between authorized configuration and perhaps less-authorized folks identifying their DNS traffic. This is well worn ground in the HTTP space. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
Sent from my iPhone >> On Mar 24, 2019, at 9:43 PM, Patrick McManus wrote: >> >> > >> On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister >> wrote: >> >> Don't overplay the privacy provided by DoH it has no effect on the DNS >> provider > > The major effect of the transport security on the privacy practices of the > provider is that it allows the client to authenticate the provider. Trust in > their privacy practices needs to be establish some other way (and the best > way we have right now is 'out of band' - hopefully that gets better) - but > with DoH Minor correction: with DoH or DoT ... > you can be confident that you're having a private conversation with the > entity you've decided to trust. That's a pretty big distinction from port 53. > Without that assurance its reasonable to be concerned about what names you > lookup. > > This of course applies to local and enterprise configs as well as the cloud > configs contemplated by most of this thread. An enterprise DoH server Minor correction: An enterprise DoH and/or DoT server... > expresses and enforces a policy - if an application needs to use that policy > it should be comforted in transport security providing confirmation that it > is doing so rather than reading in whatever might be showing up on port 53.. The only point I’m making in the above is there is no meaningful distinction in the privacy, security, or server validation between DoH vs DoT. There is one important difference, which is that DoT uses a unique port number. This is important for network operators in identifying encrypted DNS traffic, in order to ensure that implementation of security policies for DNS don’t conflict with any other network policies (regardless of what those policies are.) IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port MUST be used. DoH should only be used with explicit informed user consent, and only when DoT is unavailable. This supports the “dissident” use case, without impacting any other aspects of privacy provided by DoT.. The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to accept that risk. There is no reason DoH should be used if DoT works (towards the same DNS provider). Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
I want to add one thought to the general argument that goes along the lines of "I need to enforce a policy on my network, and doh will just encourage more https interception - we have gotten nowhere." This argument assumes a scenario where the network is trusted by the application and can require/achieve host or application configuration. Indeed - deploying trust anchors to these clients is the only way you're going to intercept https as the notion of network defined configuration of "trusted proxies" and the like is consistently rejected by clients. That seems like the right standard for DNS as well - go ahead and configure a different policy but do it via an existing authenticated configuration mechanism like you would use for adding a trust root. However, rather than adding a root I would suggest that if you're doing client configuration for network-local DNS policy, that you deploy a DoH server that enforces that policy and point DoH clients at it through the various enterprise config mechanisms. It doesn't require any kind of access that adding a trust root does not. This has the desirable property that the application can reliably know what server is providing DNS service in a fully authenticated way. Perhaps in a "my way or the highway" scenario it will choose the highway. That's fair enough - that should be a real choice. When you just intercept 8.8.8.8:53 an informed decision cannot be made. Use of non-default trust roots is also a property generally visible to applications. Most allow it as a matter of user configuration. -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister wrote: > > Don't overplay the privacy provided by DoH it has no effect on the DNS > provider The major effect of the transport security on the privacy practices of the provider is that it allows the client to authenticate the provider. Trust in their privacy practices needs to be establish some other way (and the best way we have right now is 'out of band' - hopefully that gets better) - but with DoH you can be confident that you're having a private conversation with the entity you've decided to trust. That's a pretty big distinction from port 53. Without that assurance its reasonable to be concerned about what names you lookup. This of course applies to local and enterprise configs as well as the cloud configs contemplated by most of this thread. An enterprise DoH server expresses and enforces a policy - if an application needs to use that policy it should be comforted in transport security providing confirmation that it is doing so rather than reading in whatever might be showing up on port 53. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
