Re: [dns-privacy] User Perspective
Hi Christian On Tue, Sep 25, 2018 at 01:40:59PM -0700, Christian Huitema wrote: > On 9/25/2018 12:15 PM, Tony Finch wrote: > > > For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't > > know QUIC's handshake. > > > > The warm start time should soon be 0RTT. > > The basic QUIC handshake will be 1-RTT before sending the first query, > with two exceptions: > > 1) The server may require a token exchange (similar to SYN cookies or > DNS cookies) to protect against DOS attacks, in which case the handshake > will take 2 RTT. > > 2) If the client has established a connection previously and obtained a > "resume token", it could use 0-RTT, and send the first query immediately > after the initial QUIC packet -- in fact in the same UDP packet as the > initial QUIC packet. > > Using 0-RTT is a trade-off between security and performance, because > 0-RTT packets can be subject to replay attacks. That's true for 0-RTT in > QUIC and also 0-RTT in TLS. If you are really concerned about privacy, > the prudent decision is to not use 0-RTT. > > I ran a number of simulations comparing DNS over QUIC to DNS over UDP or > TCP, considering QUIC with and without 0RTT. The high level summary is > that for traffic from client to recursive, there is very little difference: I'm not familiar with the QUIC protocol, but following what you're saying: QUIC handshake + query = 2 roundtrips If there's a "connection" previously, query = 1 roundtrip RFC 1035 UDP query = 1 roundtrip RFC 1035 TCP query = 1 roundtrip if connection exists, 2 for syn,ack+query The 0 roundtrip case occurs only when there are no fetches involved (e.g., when the answer is found in cache, but there are other cases). So there will be a difference (at least double RTT latency vs. DNS over UDP) when the query requires talking to a new nameserver. Some desired security features such as DHE for forward secrecy may need additional round trips, so pros and cons of what is picked will need discussion. It looks like the parent of this thread wants to gather usage stories only and does not want us to discuss implementation details, so let's continue this discussion at another time when the requirements are gathered. Mukund ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On 9/25/2018 12:15 PM, Tony Finch wrote: > For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't > know QUIC's handshake. > > The warm start time should soon be 0RTT. The basic QUIC handshake will be 1-RTT before sending the first query, with two exceptions: 1) The server may require a token exchange (similar to SYN cookies or DNS cookies) to protect against DOS attacks, in which case the handshake will take 2 RTT. 2) If the client has established a connection previously and obtained a "resume token", it could use 0-RTT, and send the first query immediately after the initial QUIC packet -- in fact in the same UDP packet as the initial QUIC packet. Using 0-RTT is a trade-off between security and performance, because 0-RTT packets can be subject to replay attacks. That's true for 0-RTT in QUIC and also 0-RTT in TLS. If you are really concerned about privacy, the prudent decision is to not use 0-RTT. I ran a number of simulations comparing DNS over QUIC to DNS over UDP or TCP, considering QUIC with and without 0RTT. The high level summary is that for traffic from client to recursive, there is very little difference: * TCP and QUIC-1RTT suffer a 1RTT penalty when a new connection is required, but observations of traffic show that this is a relatively rare event between client and recursive. * TCP and QUIC benefit from better re-transmission handling than UDP; they can use "dup ACK" or "selective ACK" processing, when UDP has to rely on timers only. * When re-transmissions are necessary, TCP suffers from "head of line blocking". UDP and QUIC do not. * QUIC and TCP can carry long messages. UDP has to rely either the TC bit and TCP fall back. I did not model TLS. My assumption is that TLS will be mostly equivalent to TCP, but requires an extra round trip to set up the connection unless you can use TCP fast open. The high level summary is that if there is some truncation and fallback happening, UDP performs less well than either TCP or QUIC. If 0-RTT is enabled, QUIC performs better than either UDP or TCP in all scenarios; if it is not, QUIC still performs slightly better than TCP or TLS, because it does not suffer from head of line blocking. -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
Mukund Sivaraman wrote: > > During the "how-to-achieve-it" phase, attention should be given to not > adding extra roundtrips (to keep it as close as possible to the RFC 1035 > UDP scenario). Various new facilities such as TCP's fast open, TLS false > start, etc. should not be taken for granted - considerion should be > given to the average and worst case scenarios, esp. queries in unseen > zones to non-anycast-"cloud" nameservers that aren't "known". Yes, I very much agree. As I understand it, TLS false start is able to reduce the 2RTT TLS/1.2 handshake to 1.5RTT (same as a session resume). For TLS/1.3 cold starts and session resume are the same 1.5RTT, and sessions can also be resumed with 0RTT which is very yummy for the DNS. So if I'm allowed to assume TLS/1.3 then false start doesn't buy us anything. The cold start time for DoT is 3RTT. For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't know QUIC's handshake. The warm start time should soon be 0RTT. Tony. -- f.anthony.n.finchhttp://dotat.at/ champion the freedom, dignity, and well-being of individuals ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On Tue, Sep 25, 2018 at 10:43:44PM +0530, Mukund Sivaraman wrote: > DNS is at the head of any user-initiated internet connection and the > turnaround time of a DNS request is definitely influenced by the > resolution time at the head of the sequence of steps. That should say "turnaround time of the entire user-initiated internet action", not just DNS request. Mukund ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On Thu, Jul 19, 2018 at 02:23:53PM -0400, Brian Haberman wrote: > This thread is for discussion of the user perspective of DNS privacy > between the recursive resolver and authoritative servers. > > - Focus on *what* is needed. > - Avoid *how* to achieve it. > - Consider both ends of DNS the exchange. > - Scenarios will frame the discussion. > I live in a part of the world where RTT to other parts of the world widely varies. Average RTT to "the west" or "the east" is quite high. These days many zones are concentrated on anycast "local" namesevers, but a lot of nameservers are not local too. Many users don't use "cloud" resolvers either - they use resolvers on their LAN. DNS is at the head of any user-initiated internet connection and the turnaround time of a DNS request is definitely influenced by the resolution time at the head of the sequence of steps. Recursive resolution involves several RTTs already and any extra client->server roundtrips will be a multiplier overall. I want recursive resolution to work efficiently, for everyone, for every type of scenario. This is what is needed. During the "how-to-achieve-it" phase, attention should be given to not adding extra roundtrips (to keep it as close as possible to the RFC 1035 UDP scenario). Various new facilities such as TCP's fast open, TLS false start, etc. should not be taken for granted - considerion should be given to the average and worst case scenarios, esp. queries in unseen zones to non-anycast-"cloud" nameservers that aren't "known". As an example, consider yourself as a person who has the resolver on the LAN and is a reddit.com or news.ycombinator.com visitor. You visit these websites and open links to various random websites. You don't want to be stuck at "Looking up example.com.." for seconds longer for each new query (which miss cache as they are new usually unvisited websites) compared to the RFC 1035 UDP case. The internet would suck then. Mukund ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
clients hide on proxy, but still get the specified network topological close response. Brian Haberman 于2018年7月20日周五 上午2:24写道: > This thread is for discussion of the user perspective of DNS privacy > between the recursive resolver and authoritative servers. > > - Focus on *what* is needed. > - Avoid *how* to achieve it. > - Consider both ends of DNS the exchange. > - Scenarios will frame the discussion. > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On 24 Sep 2018, at 7:08, Brian Haberman wrote: > All, > I would like the focus for this week (9/24-9/30) to be on > clarifying the requirements from the user's perspective. So far, I have > seen: > > * DNS transaction privacy, if possible > * User willingness to send PII if transaction is encrypted > > Do others have additional requirements? Not a requirement, but a strong desire: ability for a resolver to efficiently discover whether an authoritative server has privacy enhancements turned on. With that ability, given a list of NS records, a resolver might choose the privacy-enhanced one first. > If you agree with the above, could you describe a scenario to highlight > the requirements? The requirement for "DNS transaction privacy, if possible" is simple: it is known that malicious third parties will snoop the network for DNS traffic, and some resolver operators want to thwart that for the benefit of their customers. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
Tony Finch wrote: > Amelia Andersdotter wrote: >> >> I have difficulties seeing how a user (within the meaning of individual >> internet consumer) has any practical choice to other than to share PII >> with a DNS provider? > > Yes, me too. There’s always the option to run your own recursive, possibly even on your own machine. In the latter case, it even becomes a practical option for non-technical users. In this case, the discussion about privacy between recursive and authoritative becomes much more important since it becomes easier to link the information leaked to the authoritative to a specific user (well, device). But then, how much information do you leak, really, to a individual authoritative? I’ve been meaning to do a proper privacy analysis of the possible option for a user’s DNS setup. Which of these leaks the least amount of information and, as a result, is there any measures that can be taken to leak even less? I have a sense that the gut feeling assessments that people often do (“Just run your own Unbound on a private server”) may not actually hold up. Not sure if such an analysis is relevant for this particular work, but it may still be useful to do as part of this working group. > Since the overall topic is recursive -> authoritative, the questions imply > some mechanism for the user to communicate their privacy policy to the > recursive server, or perhaps it would be more useful for clients to ask > the recursive server what its policies or capabilities are. But what > happens when there is a mismatch? I’m not sure such capability announcement is useful. It can help with making a decision when automatically picking a recursive -- but then you can’t actually put too much trust in it because it easy to claim whatever and, since automation hides the decision, hardly anyone will ever check. Essentially, you will have to make a trust decision for a particular recursive service. There may be technical means to support this, but these need to be off path and operated by independent third parties. Kind regards, Martin ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
Amelia Andersdotter wrote: > > I have difficulties seeing how a user (within the meaning of individual > internet consumer) has any practical choice to other than to share PII > with a DNS provider? Yes, me too. Since the overall topic is recursive -> authoritative, the questions imply some mechanism for the user to communicate their privacy policy to the recursive server, or perhaps it would be more useful for clients to ask the recursive server what its policies or capabilities are. But what happens when there is a mismatch? Specific information leaks that we might care about: * QNAME minimization or not? * EDNS client subnet or not? * Upstream encryption available or not? (asking for it to be required is a "break the Internet" switch so it doesn't make sense) And the points Amelia made about data management which I might recast more mechanically as: * Passive DNS logging on the upstream side? * Query logging on the client side? Some of this is stuff that a recursive server knows about itself, and could (reasonably easily) communicate to a client; some of it is about the deployment and setup around the server which it doesn't necessarily know (and I don't think it would be realistic to expect operators to configure their servers to say they are running packet captures on DNS traffic...) Tony. -- f.anthony.n.finchhttp://dotat.at/ Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5 to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming moderate or rough, then very rough later in Fisher. Showers. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy