Re: [dns-privacy] User Perspective
Christian Huitema wrote: > > An attacker could replay the 0-RTT packet, and observe whether it > creates a particular side effect at the server end. For example, replay > the traffic from client to recursive, and observe whether the resolver > issues a query to particular DNS server. Ah, yes, if you can see the upstream queries, even when encrypted they are quite a lot more leaky than the cache side channel. I'm now imagining a resolver that sends steganographic chaff queries when there's a cache miss :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ people involved in running their communities ___ 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 2:30 PM, Mukund Sivaraman wrote: > 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. The QUIC connection provides DHE and forward secrecy by default, just like TLS 1.3. This is already accounted for in the "1 roundtrip". Note that there are really 4 sources of latency: * Initial connection setup -- UDP or QUIC+0RTT beat TCP, TLS and QUIC without 0-RTT by 1 RTT * Inefficient retransmission -- in case of errors, corrections may arrive much later with UDP * Head of queue blocking -- an issue for TCP and TLS, not for UDP or QUIC, may cause 1 RTT delay of packets coming after and error * Fallback to TCP -- an issue with UDP if the response does not fit in a single packet. When you are comparing protocols, you need to consider all 4 issues, not just the initial connection setup. Estimate probabilities of issues based on traffic patterns, see what happens. For example, in the resolver to authoritative scenario, you are likely to use DNSSEC, in which case UDP suffers from the fallback to TCP a lot. -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On 9/26/2018 4:15 AM, Tony Finch wrote: > Christian Huitema wrote: >> The basic QUIC handshake will be 1-RTT before sending the first query, >> with two exceptions: > Thanks for those details! > >> 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. > Correct me if I'm wrong, but my understanding is that the 0RTT replay > attack is not a privacy problem, but is a problem if the payload has > undesirable side-effects. The 0RTT privacy problem is the same as for TLS > session resumption: the session details can be used to track clients. An attacker could replay the 0-RTT packet, and observe whether it creates a particular side effect at the server end. For example, replay the traffic from client to recursive, and observe whether the resolver issues a query to particular DNS server. I think DKG did the analysis in details. He should probably elaborate. > For privacy-conscious clients, I think it makes sense to use session > resumption for the lifetime of a particular layer 2/3 network connection, > and drop session tokens when roaming to a different connection. So you > benefit from the improved performance while the server has other ways to > track you, but it's harder for the server to track clients from place to > place. > > (this is more of a stub -> recursive concern rather than recursive -> > authoritative) There is indeed that other issue with 0-RTT and session resumption. It provides the server with a tracking cookie. > >> 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. > QUIC is something nice to look forward to :-) Yes... -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
Christian Huitema wrote: > > The basic QUIC handshake will be 1-RTT before sending the first query, > with two exceptions: Thanks for those details! > 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. Correct me if I'm wrong, but my understanding is that the 0RTT replay attack is not a privacy problem, but is a problem if the payload has undesirable side-effects. The 0RTT privacy problem is the same as for TLS session resumption: the session details can be used to track clients. For privacy-conscious clients, I think it makes sense to use session resumption for the lifetime of a particular layer 2/3 network connection, and drop session tokens when roaming to a different connection. So you benefit from the improved performance while the server has other ways to track you, but it's harder for the server to track clients from place to place. (this is more of a stub -> recursive concern rather than recursive -> authoritative) > 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. QUIC is something nice to look forward to :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: West 5 to 7, decreasing 4 for a time. Very rough, becoming rough. Rain then showers. Good occasionally poor. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
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
Re: [dns-privacy] User Perspective
On 9/24/18 11:58 AM, 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? It's not so much about "willingness" as it is about > "feeling comfortable with". I think it might be helpful to scope the data under discussion and identify what counts as PII under the context of the DNS. This may be outside the scope of the current discussion but I've been somewhat concerned lately by some of the assertions being made about who to trust (the "who" in this case being recursives) in privacy-protected DNS transactions. The assertions tend to be fairly global but it seems to me that in at least some cases (for example, secure messaging) the application will have some fairly specific requirements around privacy that it's unwilling to leave to the default OS configuration, the browser, the service provider, etc. Melinda ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On 2018-09-24 16: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? I propose to add: * Data management practises (i.e. profiling, advertisement, re-selling, etc) > If you agree with the above, could you describe a scenario to highlight > the requirements? 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? It's not so much about "willingness" as it is about "feeling comfortable with". best regards, Amelia > Regards, > Brian > > On 7/19/18 2:23 PM, 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. >> >> >> >> ___ >> dns-privacy mailing list >> dns-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/dns-privacy >> > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy -- Amelia Andersdotter Technical Consultant, Digital Programme ARTICLE19 www.article19.org PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
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? If you agree with the above, could you describe a scenario to highlight the requirements? Regards, Brian On 7/19/18 2:23 PM, 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. > > > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
1) User may be willing to send PII (such as ECS) to authority if the transaction is encrypted. 2) user may be willing to be signaled that the response is “validated” if the authoritative answer was obtained over an authenticated link for unsigned zones ( similar to 4. from Paul) Manu > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
The user scenarios that I can think of are: 1) Users want DNS transaction privacy if possible 2) Users need absolute DNS privacy 3) Users want DNS transaction authentication if possible 4) Users need absolute DNS authentication #1 is basically opportunistic encryption: the resolver keeps going even if the server can't be authenticated. A MITM can see the transaction, but a passive observer cannot. Widespread use of #1 would reduce the ability to snoop on resolver traffic. I cannot think of a real use case for #2. That is, I cannot imagine a way for a user to usefully signal to a resolver "you must have authenticated transaction privacy with all authoritative servers; if any of the servers cannot do that, don't continue and return an error to me". #3 does not help prevent any attacks I can think of. #4 is a new use case that has been discussed recently to give assurance of results in unsigned zones, and assurance of child NS and glue records in signed zones. This use case is not about privacy. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
