[dns-privacy] Secdir last call review of draft-ietf-dprive-dnsoquic-08
Reviewer: Phillip Hallam-Baker Review result: Has Issues The draft addresses the longstanding problem of DNS using an insecure transport protocol in the way that it should have been addressed from the start - encrypting the UDP packets. It is an important and overdue addition to the network protocol stack. The approach to using QUIC is about as straightforward as is possible given the legacy infrastructure. One area that is likely to require attention that is not addressed is the interaction of DNS and PKI and DHCP in the context of WiFi roaming networks. The principled way to address this use case would be for WiFi networks requiring authentication and/or agreement to terms to advertise via a standardized interaction signaled through e.g. DHCP. But there being no such agreed standard, public WiFi access points engage in a wide variety of approaches to intercepting the user's attention. Many of these intercept DNS connections. Thus, the assumption that DNS is insecure is built into legacy systems. While the incoherence of existing infrastructure is outside the remit of this specification. Guidance to implementers on this point might help reduce the amount of additional incoherence generated. Just noting that this is an issue might spur folk to correct this situation. The security considerations section forwards to RFC7858. This specification is six years old and represents the state of knowledge before deployment of the specification. Further the scope of 7858 is stub-to-recursive traffic, the new draft discusses zone transfer which is far outside that scope. The document has a privacy considerations section but all of the text would normally come under the 'confidentiality' heading in security considerations. The distinction is helpful in some cases but does not appear to add much in this one. The section on traffic analysis states information can be gained from observing packet lengths. Given the sensitivity of DNS traffic to analysis, this seems like a significant oversight. Even if QUIC does not provide a convenient mechanism for doing this, it could easily be added within the DPRIVE binding. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [EXTERNAL] Re: Trying to understand DNS resolver 'discovery'
This business of proxy chains. It seems like it is insoluble. We faced the same problem when we were trying to deal with spam. There is a huge amount of complexity there. I have been thinking about this problem for the past week and I think I have come up with the answer: None of it matters. To explain, if Alice decides to use DavesDNS.resolv as her resolution service, that is the end of the matter as far as Alice is concerned. There are two possible types of service Dave might provide: 1) Untrusted: Dave returns full DNSSEC paths for all his answers, Alice checks them. In this case, the source of the data Dave supplies is irrelevant as the source of trust is whatever DNSSEC apex is used for validation. 2) Trusted: Dave returns unsigned records and Alice must trust that Dave obtained the records, processed them etc. in accordance with the agreement between Alice and Dave. The point is that Alice ONLY has a relationship here with Dave. How Dave obtains the records is irrelevant. They can be sent by carrier pigeon for all it matters. The internals of how Alice obtains the information is 'black box'. Within any relay structure, there is always a controller who decides which will be the next relay in turn and unless there is a successful MITM attack (in which case we should want to force the connection to ABORT) the control is always with either the sender or the receiver As far as the Internet protocol is concerned, there is always exactly one hop, the point where the client side hands control over to the service side. And this is always the hop that crosses the narrow waist. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
On Tue, Nov 26, 2019 at 1:08 PM Stephane Bortzmeyer wrote: > On Tue, Nov 26, 2019 at 12:35:13PM -0500, > Phillip Hallam-Baker wrote > a message of 166 lines which said: > > > 2) Admin/User Configured DNS > > The client obtains the information to connect to a resolver through > an > > Administrator or User configuration action. This may be inserting an IP > > address (8.8.8.8/1.1.1.1/etc) or some form of DNS label. > > > > 3) Application/Platform Provider Configuration. > > The application or OS platform can simply ignore user preferences and > > choose a DNS provider of its own liking. > > Note that, for free software, there is no real difference between 2) > and 3). Someone can always change the source and recompile. (And there > is of course no real privacy without free software.) > A very small number of people have that ability. It is not possible for the typical iOS user for example. >From my perspective, the user is the only valid source of authority. The user must have control of their environment (unless they are at work and know that they have surrendered control in return for a consideration). > > But please, assure me that we are not the brink of users being faced > > with pop ups asking them 'would you like to choose me as your DNS > > provider'. > > Why not? But, anyway, the IETF does not do UI so it's not really our > job. > Modern Web browsers have countless security blunders. Allowing sites to do pop ups at all was an abomination. Saying we don't do UI in this case is like saying we don't do security. Changes to the security configuration should only be initiated by the user. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Trying to understand DNS resolver 'discovery'
This notion of DNS resolver discovery seems very strange to me. There are three ways in which a DNS resolver can be realistically determined by a client whether that is in the platform (Windows/OSX/Linux/etc) or the application. 1) Promiscuous DNS The client obtains the information to connect to a resolver either as part of DHCP configuration or by further interrogation of the local network. 2) Admin/User Configured DNS The client obtains the information to connect to a resolver through an Administrator or User configuration action. This may be inserting an IP address (8.8.8.8/1.1.1.1/etc) or some form of DNS label. 3) Application/Platform Provider Configuration. The application or OS platform can simply ignore user preferences and choose a DNS provider of its own liking. This is not an exhaustive enumeration of the possibilities of course. But please, assure me that we are not the brink of users being faced with pop ups asking them 'would you like to choose me as your DNS provider'. Of these three models, I have always considered (1) to be a security hole. It made some sense in the days when the smallest machine connected to the Internet was the size of a washing machine and portable computers didn't exist. But not today. [As a pragmatic matter, it will continue to be necessary for devices to use the local network DNS resolver for the purpose of connecting to WiFi in kiosk type environments. ] We might well see the third model being imposed by government decree in some places. Along with the DNSSEC root key to be used for validation. Yes, there are situations where split DNS has to be considered so that the device knows that when it is on the employer network it behaves differently. But I see those as being a subset of VPN config. If Alice works for example.com, then she can install a signed config file stating which DNS resolvers and IPSEC (or other VPN) parameters to use on which networks for which sets of DNS addresses. So what I see is a requirement for DNS resolver configuration. We already have rfc6763 to tell us how to get from a DNS label to an Internet service. Albeit one that presupposes the existence of a resolution mechanism. I don't see it being problematic to use the local DNS to do this resolution provided that 1) we have the means to authenticate the connection and 2) we only use this mechanism once, to perform initial configuration. DNS resolution service providers do need to change their IP configs from time to time of course. But there is an expectation that the resolver IP is stable over very long periods of time. Moving to DNS names for resolvers does not free us from this expectation in this case. In my view, choice of a DNS resolver should be an event backed by ceremony so while I think we can and should insist on DNSSEC authentication for the resolver[1], there is certainly a potential role for a WebPKI certificate to establish accountability (i.e. EV). There is also a potential role for use of rfc3709 (logotypes) to provide a strong security signal during a one-time configuration operation. [1] Even if the local resolver does not support DNSSEC or insists on the use of an untrusted root, the DPRIV service being connected to can provide this information as part of the initial handshake. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Correcting some misstatements made in the session
Some of the attacks made on one of the speakers seemed overly aggressive to me. And as sometimes happens, the people making the statements were simply misinformed. The use of machine readable legal terms is not just possible, it is the way most international trade takes place. When I first joined VeriSign, I worked in the practices group where one of our projects was developing that technology in a collaboration with the ICC. That project was probably premature, back in 1997 we had barely started SSL. But INCOTERMS are the basis for most international trade. https://www.export.gov/article?id=Incoterms-Overview Secondly, we keep having people make blanket statements about what the user can understand. If we are going to have people make claims based on 'academic studies' I think it behoves them to state which studies they mean. Because when we recently had this discussion on the Mozilla list, we were once again shown the same decade old study based on 18 participants split into three groups of six that found that users don't understand security signal without training. Cherry picking results to find the result you want is not science. As with the EFF claim that there were over 1000 CAs, this is a zombie prejudice. If people are going to slap down speakers with statements of absolute certitude and ridicule them, better get it right. In this case the statements made were wrong. I think an apology is warranted to the speaker. We are not going to get the best results if people are ridiculed for making statements that are actually correct. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt
On Mon, May 18, 2015 at 6:37 AM, Simon Josefsson si...@josefsson.org wrote: Phillip Hallam-Baker i...@hallambaker.com writes: Any DNSvNext protocol MUST work in 100% of network situations where DNS works or else it has 0% of being adopted. That's simply impossible. A goal like that will just distract us. It is completely possible as I have done that. Google is currently working on HTTP over UDP to shave a second of page load times. This group is working is proposing to move the most latency critical interaction from UDP to TLS. Some people here pointed out that the initial goal is for stub resolving, which is not latency critical. I believe this point can be made more clear in the documents and in the discussion. One easily gets the idea that this is about Internet-wide DNS. Confusing these two use-cases is bad. Stub resolving is totally latency critical. Go talk to some folk who work on browsers. Personally, for stub-resolving I don't see the need for having two mechanisms (upgrade-TLS and port-TLS). Just standardize one of them and be done with it. /Simon ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] How many mechanisms in draft-ietf-dprive-start-tls-for-dns?
On Wed, May 13, 2015 at 12:32 PM, Doug Royer douglasro...@gmail.com wrote: Firewall issue: We can't live in fear that only a handful of ports are forever usable because of busted firewalls or busted firewall administrators. I think the decision should be based on what's best for DNS. I hope that older DNS servers do no crash when getting a new type of packet information on port 53. I would think that making sure we do not bust existing things should take priority. We should be abolishing port numbers in favor of SRV type discovery. However, DNS is the exception to the rule. It is a discovery protocol so it is the one area where fixed IP address and port is arguably acceptable still. It depends on your view of the client-resolver versus resolver-authoritative protocols and how binding is achieved for client-resolver. I think it is time to let go of fixed IP address and known port completely ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Tue, Apr 28, 2015 at 5:04 AM, Tony Finch d...@dotat.at wrote: Phillip Hallam-Baker i...@hallambaker.com wrote: Having it work for content and DNS are two different things. The routing tables only need to be constant for a few minutes to support TCP content download. For DNS to be viable they have to be stable much longer. Why? Because when downloading content, what matters is throughput.The byterange extensions in http mean that it is possible to resume a session interrupted part way through if it is static content. For DNS the pattern is a tiny number of one packet interactions per hour with exceptionally tight latency. If the anycast changes then you are going to have to timeout and resume. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Tue, Apr 28, 2015 at 12:16 AM, Christian Huitema huit...@huitema.net wrote: On Monday, April 27, 2015, at 5:22 PM, Warren Kumari wrote On Mon, Apr 27, 2015 at 4:17 PM, Paul Hoffman paul.hoff...@vpnc.org There is a third solution to the anycast problem, which is what is done today in all systems that use anycast: assume that it happens so rarely, that a rare reset is just fine. ... Many (most?) of these properties run HTTPS. From what I hear, fastly customers are happy chappies -- TCP anycast works... OK. Let's put this anycast/UDP/TCP thread to rest, and agree that this is not a problem in practice. And if that's true, then we should just pick UDP/TLS/TCP and be done with it. Having it work for content and DNS are two different things. The routing tables only need to be constant for a few minutes to support TCP content download. For DNS to be viable they have to be stable much longer. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Mon, Apr 27, 2015 at 3:50 PM, Christian Huitema huit...@huitema.net wrote: Which is why I propose what is in effect a STLS (Staleless TLS) in which each UDP request packet (optionally) contains the full state required to decrypt it at the server. Without going in the details, there are two types of solution to the anycast problem: either some form of pinning, so requests from a given context are guaranteed to arrive at the server with that context; or, somehow ensuring that the requests carry enough state that they can be understood by any server in the pool. I understand how to do pinning: a first transaction to the anycast address returns the unicast address of the relevant server. Not perfect, because it adds a roundtrip during the initial setup, but easy to understand. I am not too bothered about the initial setup. That is a one off thing that can happen as soon as the IP stack is initialized. Even doing it in application space there is usually a gap between someone starting a browser and clicking on a link. I am not sure about the way to carry enough state in each request. Kerberos tickets, or rather an opaque blob that the service can put whatever format ticket it likes. Especially if we want to do PFS, which means negotiating different session keys over time. I assume that the client could learn a temporary key that is understood by all servers in the pool, and use that to encrypt the messages. But then that requires a fair bit of coordination between the servers in the anycast pool. How much PFS do you want? Easy enough to rotate a kerberized ticket on an hourly basis or so. -- Christian Huitema ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Thu, Apr 23, 2015 at 4:21 PM, Dan Wing dw...@cisco.com wrote: I am not an expert on DTLS but that was the concern that made me avoid using it. I want a completely stateless resolver, not just UDP. That means using either a very fast ECC scheme for authentication or some sort of kerberos ticket. I believe Transport Layer Security (TLS) Session Resumption without Server-Side State, https://tools.ietf.org/html/rfc5077 solves that problem. It works with TLS and with DTLS. That is an option in DTLS. For a DTLS based scheme to be acceptable, client support has to be mandatory. If we do that, I have no problem with the additional overhead. The question then is whether we can profile DTLS without in effect requiring a new implementation library. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE over UDP or TCP
On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd watsonbl...@gmail.com wrote: On Apr 23, 2015 1:52 PM, Phillip Hallam-Baker i...@hallambaker.com wrote: On Thu, Apr 23, 2015 at 4:21 PM, [image: ]Dan Wing dw...@cisco.com wrote: I am not an expert on DTLS but that was the concern that made me avoid using it. I want a completely stateless resolver, not just UDP. That means using either a very fast ECC scheme for authentication or some sort of kerberos ticket. I believe Transport Layer Security (TLS) Session Resumption without Server-Side State, https://tools.ietf.org/html/rfc5077 solves that problem. It works with TLS and with DTLS. That is an option in DTLS. For a DTLS based scheme to be acceptable, client support has to be mandatory. If we do that, I have no problem with the additional overhead. The question then is whether we can profile DTLS without in effect requiring a new implementation library. This doesn't solve the actual problem, as compared with DNS/UDP. DTLS resumption requires a round trip: the server keeps that state alive as a new DTLS connection, and then the client or server closes it after using it. So if you have 10,000 clients, even if only 100 of them issue queries a second, but over two minutes they all do, you will either force them all to pay the latency price of reopening the connection or store state for 10,000 DTLS sessions. Another problem is with anycast. Ordinarily failover is completely transparent to users: the packets go somewhere else, and get responded to. I don't see how this works with TLS, unless you do fancy stateful failover tricks. The easiest solution is to encrypt packets with a public key that the servers have, or force every packet to contain something equivalent to resumption data. But that requires not using TLS/DTLS. Sincerely, Watson Ladd Ah, then it doesn't work. I can't see why people are so insistent on clinging to a familiar label. Is it because it is easier to put blind faith in TLS than consider how it works? ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoptions on the 3 documents.
There are two sets of issues:
1) Discovery
2) Presentation
I suggest dividing the drafts into two parts and considering these
separately. DNS currently has two transports. The idea that all uses
can be addressed over TCP is currently unproven as far as the majority
of the stakeholders whose action is required for deployment.
Discovery
Confidential DNS and TLS for DNS both handle the discovery portion as
an upgrade from regular DNS protocol. This is directly analogous to
the STARTTLS approach introduced in SMTP. As such it has the advantage
of being expeditious and the weakness of being vulnerable to a
downgrade attack.
While there are approaches that can be taken to prevent a downgrade
attack, these have not matured for STARTTLS/SMTP and it is difficult
to see how to apply DNSSEC in this particular case since the starting
point for discovery is an IP address, not a domain name.
It is clear that 'some mechanism' of this sort is required and the one
presented in TLS for DNS is probably as good as can be done in that
situation.
Private DNS takes the approach of introducing a new protocol for Web
Service binding that leverages TLS to establish an authenticated
session key for a Web service specified by DNS name (i.e.
'google.com', not '8.8.8.8'). This approach is designed to address the
use case where a device establishes a 'lifetime binding' with a
particular DNS service for resolution services. Optionally, a binding
may be for a subset of the DNS namespace.
This proposal is a very general Web Service Discovery mechanism
designed to support multiple protocols. The idea being that when a
device is first initialized, it is bound to a collection of services
that it will need. For an embedded device this would be likely {DNS,
ACME, SMTP, Log}, for a user it would likely be {SMTP, XMPP, IMAP,
DNS, OpenID...}
The two schemes adopt different deployment strategies. DNS over TLS
attempts to reduce the size of the ask to the bare minimum. Private
DNS attempts to maximize the Reward while keeping the cost bounded.
Proposal:
* Adopt the Discovery portion of TLS for DNS now with the proviso that
the in-band upgrade mechanism be demonstrated to support additional
presentation transports and establish a registry for declaring such
transports in the usual way.
* Get a fast win with the above approach if possible, while exploring
Discovery mechanism of Private DNS on an experimental basis.
Presentation
==
DNS over TLS proposes reuse of the existing TLS stack. This has the
advantage of simplicity if a device already has a TLS stack. Otherwise
it is a vast increase in complexity. The main drawback to TLS is the
need for TCP transport. This is an approach many of us remain
skeptical of. And even if the argument can be won inside the group
there is little evidence that it would be accepted outside.
There are several parties that have the technical resources and
infrastructure who could simply roll out TLS over DNS today if they
were convinced of the benefits. With SPDY we had a vendor come to us
with a fait acompli.
Private DNS proposes a simple mechanism currently based on a
pre-established symmetric key and ticket. But the plan was to drop the
CFRG ECC key in as soon as it became available.
Proposal: Adopt the relevant part of DNS over TLS as the TCP based
scheme and Private DNS as the UDP scheme.
Separating the protocol into layers is work but it is the right
approach I believe.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Starting call for adoptions for the 3 documents
On Tue, Apr 7, 2015 at 3:33 PM, Warren Kumari war...@kumari.net wrote: Hi all, We are planning on starting a call for adoption on the documents on April 15th. At the meeting in Dallas we heard that a number of people didn't feel that they had enough information / knowledge of the documents to make in informed decision, so we are giving y'all some extra time to read the documents before kicking off the CfA. Our plan is to have a *single* call for adoption, listing all 3 documents, and ask people to put in a *clear* indication for each document if they would like it adopted or not. We will then decide which we will be adopting -- if we get really strong support for multiple documents we will adopt multiple... I think that the more important question is how we partition the problem up and how we address each part. Documents are only a bunch of text and it is doubtful much of what is there now will survive if anything. As I see it, there are two sub-problems: 1) How does a client discover and establish a binding to a DPRIV service? 2) What transport/sessions(s) are supported for queries? Before answering either, I think it is pretty clear that at some point in the future, SPUD will be the logical choice for transport/session. It is also clear that we should not build research on research. So the way forward as I see it should be that our answer to (1) should support some mechanism for advertising alternative transports so we can use TLS for now and make use of SPUD if and when it matures. The hard part of the problem is all in problem 1. I designed, implemented and wrote the draft for the transport/session part in a day. It isn't a difficult problem (if you are only solving DNS, SPUD is a lot harder). The hard question is how to discover and establish a binding to the DNS service before you have DNS. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-wijngaards-dnsop-confidentialdns and DDoS
On Fri, Mar 20, 2015 at 6:33 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 19/03/15 23:43, Zhiwei Yan wrote: Hi, all, I think it's better that this draft contains some solution about the client authentication to decrease/avoid the DoS attack. But it's really not the focus of this draft. In order to solve this problem, many other schemes can be used, such as DHCP, SAVI and DANE. Anyway, this draft can make use of them to authenticate the client. I, and probably others, would fairly strongly object if the work of this group that is intended to enhance privacy required all clients to be authenticated, and hence identified, and thus give up privacy. There may be a place for authenticated clients in this space (e.g. perhaps within an Enterprise n/w) but that had better not be the main mitigation for potential DoS attacks. S. There is message authentication, client authentication, device authentication and user authentication and they are very different things where privacy is concerned. One of the reasons why I am not keen on 'just' use TLS is that it forces one particular approach that is optimized for a different purpose. I find it much easier to provide the desired As far as DNS privacy goes, the big performance issue is the DNS lookup. We need to get latency reduced to the absolute minimum there and we need to have strong protections preventing people from DoS-ing the resolution hosts. For this particular interaction, my preference is for symmetric key based authentication using a kerberos style ticket to allow stateless key management on the server. The request is going to be encrypted, so we have a symmetric key at this point. So the question is how to establish a shared secret/ticket pair and how long it would be valid for. In the enterprise case we are going to require authentication of the user and/or device in order to connect to enterprise resources behind the split horizon. Here we will want to do a one time user/device authentication to establish a local credential. In the anonymous use case, the simplest approach might be to simply set up a TLS connection to the DNS service and request a ticket via a HTTP/JSON type interaction. That is what my current drafts describe. The problem with the purely anonymous case is that what our customers are currently paying us to provide is not actually 'privacy'. They are paying for a mechanism that bypasses local DNS based censorship and a curated DNS/IP address space that has the criminal element excluded. That makes things rather complicated because quite often a user may have different ideas about what censorship is good and which is bad. This is quite a challenging problem to get 100% right. But if the solution is less than 100% we are not going to get Microsoft, Apple or Google to deploy on the platforms 95% of the market uses. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Fwd: Encrypt the signalings between stub and recursive resolvers under UDP
The proposal is a reasonable approach and not overly complex. The question that concerns me though is how the client authenticates the resolver. Without authentication, encryption is useless because you could be having the conversation with Mallet. Using DNSSEC for that is problematic since the credentials in DNSSEC are designed to be ephemeral. Even PKIX certs, limited to 60 months becomes a real problem. And both approaches have circular dependency issues. Another concern that I have is that the protocol has to protect resolver hosts from a Denial of Service attack. That means that the hosts cannot perform any function that provides an attacker with 'leverage' unless the request passes authentication first. So the first thing I think is necessary in any proposal is to separate out the problem of how the client-resolution service context is established from the mechanism used to enhance the DNS packets. The second part of the proposal is very straightforward. A simple framing scheme using the tools already present in the TLS toolkit can be devised and implemented in few hours. Supporting parallel UDP and TCP or even UDP and HTTPS schemes is not a major overhead. The hard part is how you decide to set up the initial relationship between the client and the resolver and how long you want it to last. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Another reason not to layer DNS security on TLS
On Sun, Mar 8, 2015 at 7:48 PM, Christian Huitema huit...@huitema.net wrote: What worries me is if we build a circular dependency into the stack. TLS is layered on top of DNS at several points. The names used in TLS are DNS names. Let's step back a minute. We are worried that TLS carries clear text that may disclose the nature of the service. In the absence of such disclosure, adversaries only know that the client is using one of the many services collocated at the IP address of this server. With the disclosure, adversaries discover that the client is using a private DNS resolver service located at the IP address of the server. But then, look at what happen if we define a special purpose protocol, different from TLS. Adversaries can presumably identify that this is the DPRIVE protocol. Thus, they can identify that the client is using a private DNS resolver service located at the IP address of the server. What kind of privacy would we gain? The privacy concern DPRIV is trying to address is to prevent an adversary seeing the contents of DNS traffic or being able to deduce them from packet sizes, timing etc. That is a very different problem from stopping the attacker from being able to distinguish DNS traffic from HTTP. At the extreme, any client connecting to 8.8.8.8 is doing DNS... Now there are techniques that we can use to make the observation somewhat harder. But there we have stepped outside the 'stop pervasive monitoring' brief and we are trying to prevent pervasive censorship. That is an important problem but not one that we are focused on here. DNS client-resolver queries over TCP and TLS is going to be quite easy to identify as DNS traffic. The problem I have been concerned about in this thread is that if we assume DPRIV succeeds, we will still be leaking the DNS names through the SNI feature in HTTPS, i.e. HTTP-over-TLS. HTTPS privacy isn't the problem we are solving right now but DPRIV privacy isn't going to be worth very much if the information we are securing is then disclosed in the HTTP/HTTPS layer. So we have to solve DPRIV in a way that does not paint us into a corner when we try to solve the next puzzle. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] tcpinc ?
On Mon, Mar 2, 2015 at 9:00 AM, Ilari Liusvaara ilari.liusva...@elisanet.fi wrote: On Mon, Mar 02, 2015 at 07:49:08AM -0500, Phillip Hallam-Baker wrote: Having long experience of trying to persuade browser providers to do OCSP with TLS, I do not see any possibility that DNS over TCP is going to be acceptable to them. I don't care how many graphs are presented showing that TCP is as fast under lab conditions or with a specific stack or with new extensions etc. I would not be convinced and I see no reason why Google is going to be. Reducing the time to load of the first page is a really big deal for the Chrome team. So when people are saying 'DNS over TCP isn't a major overhead' what the Chrome team are probably hearing is 'giving up half your annual bonus to do privacy our way shouldn't be a problem'. Are you talking about: - Overhead of establishing (secured) TCP connection (AFAIK, 2RTT without extensions)? - Bad handling of packet loss by TCP (don't know)? - Latency increase from increased bandwidth and encryption/decryption (AFAICT, on order of 0.1ms or so)? All of the above The hot assoication performance looks acceptable. Are you talking about cold association performance being important? As soon as you put an adjective in there, I think you lose them. The origin of my proposal is that I was trying to reduce the overhead of doing OCSP checks to an acceptable level because they were refusing to hardfail on TLS cert status checks. Now DPRIV might be a higher security priority but I somehow doubt it. I don't think we have any chance of getting the fish to bite unless we can show a performance advantage in virtually every case without exception. Also, the end that bears the burnt of keeping hot associations is the server end (recursive resolver in case of stub-recursive), not the client (stub) end. I have heard of single system image managing to keep 1 million TCP connections at once (that was some time ago, likely higher now). Again, that is an argument that I think only has weight if it comes from some party that is going to deploy a highly trafficked recursive. And I think it is only something that we should even consider if there isn't any other alternative. We have an alternative and it is just as easy to implement and guarantees performance at least as good as current DNS for 97% of network circumstances. I would see the point of using UDP (which means increased complexity): - If cold case 2RTT is unacceptable. - If packet loss handling of TCP proves too troublesome. - If maintaining enough associations is problem for recursive servers. Using UDP does virtually nothing to extra bandwidth latency. The startup and session maintenance costs are significant. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] tcpinc ?
On Mon, Mar 2, 2015 at 9:00 AM, Ilari Liusvaara ilari.liusva...@elisanet.fi wrote: I would see the point of using UDP (which means increased complexity): No it does not. UDP is a lot simpler than any of the TCP proposals. * Fewer states * Smaller library * Fewer options TLS is a big complicated specification and the open source libraries are in a woeful state. Take a look at the date the tutorial on the OpenSSL API was written. The expeditious approach to setting up a client-service binding is to leverage TLS. But that is separate from the DNS session transport question and something that can be revisited later. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] (re-)identifying from sets of queries (was Re: Start of WGLC for draft-ietf-dprive-problem-statement - please review.)
On Fri, Feb 27, 2015 at 10:50 AM, Tim Wicinski tjw.i...@gmail.com wrote: On 2/27/15 10:46 AM, Stephane Bortzmeyer wrote: On Fri, Feb 27, 2015 at 10:38:53AM -0500, Phillip Hallam-Baker i...@hallambaker.com wrote a message of 78 lines which said: BTW are we planning to IETF last call this doc and publish as an RFC or is this internal only? The charter is silent about it. My goal is certainly to have this document published as a RFC, we need clear documentation of privacy properties of IETF protocols, like RFC 6973 says. Now, whether or not an IETF Last Call is necessary, I don't know. Warren and I have discussed this, though not recently. The consensus (from the group and from ADs) is published as an RFC. I know a few have felt the IETF are awash in problem statements. I just want to know what sort of review to give it. I won't bother with spelling errors and the like for non RFC docs. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Devote time to draft-rafiee-intarea-cga-tsig? (Was: Moving things along...
On Fri, Feb 27, 2015 at 2:58 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Feb 27, 2015, at 11:40 AM, Hosnieh Rafiee i...@rozanak.com wrote: I agree that the first versions might be confusing. I have looked at the current draft and it is still just as confusing to me. I do not feel that it is a good use of our time to cycle on this draft just to get it to be understandable to typical readers. I'm happy to read the Introduction section of further revisions and, if one eventually is clear, to comment then. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy I agree. I don't see that this is helping us understand the problem or the solution options. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] (re-)identifying from sets of queries (was Re: Start of WGLC for draft-ietf-dprive-problem-statement - please review.)
On Thu, Feb 26, 2015 at 7:51 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, On 26/02/15 12:43, Brian Haberman wrote: Are you thinking of looking at patterns of qname values/labels or just some number of packets going towards a DNS resolver within a certain time frame? If it is the latter, I think it is out of scope since that type of analysis can be done on any type of traffic. If it is the former, I agree that such analysis can be prevented with encryption of DNS queries going to the resolver. I was thinking of the former, so in scope:-) However, even considering the latter, if we define some confidentiality service and if that does include some form(s) of padding then it may also be possible to mitigate analysis based on message sizes and numbers of packets. That is jumping ahead a whole bunch of steps though. For what it is worth, I did include padding in my spec, specifically to defeat traffic analysis based on packet length. Otherwise it would be easy for an intelligence agency to identify people going to a site by putting in a very long DNS name and looking for queries of a specific length. Now I don't want to make that a point of distinction vs the VeriSign proposal as they could add padding. But I think it does show that a lot of thought has to go into the process and that we cannot 'simply reuse' TLS. If we are going to be padding packets in TLS then why not just do what I do and leverage the expensive, complicated part of TLS, the key exchange and replace the easy part, the packet framing? I am not yet done with my architecture paper. But one of the consequences of Snowdonia is that traffic analysis is now part of the threat model and we have to start getting to grips with it. It is not possible to protect against every type of traffic analysis with end to end security. DPRIV is an end to end security enhancement implemented as a session layer replacement so there will be some types of traffic analysis we cannot defend against. There is more than one level of traffic analysis that is relevant: Network Layer: Packet size, IP address, Timing Link Layer: Packet path If you want to have complete traffic analysis protection then you have to work at the Network and Link layers as well as the session layer because that is where the attacks take place. It is possible to add noise at the session layer to provide a degree of security. But we have to be realistic about what we can achieve. We can certainly neuter mass surveillance and most forms of passive attack. We can't be effective against an active attack without a lot of overhead. Rolling up multiple queries into a single query is another technique I use that helps reduce the information leakage (besides improving efficiency). One thing I would like some help with is understanding what the padding quanta should be. I am not sure this needs to go in the spec but we should have some idea. My naive approach is simply to add a random chunk of data then pad every message to a multiple of 64 bytes or the MTU. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Moving things along...
Responding to Hosnieh: We have to avoid loaded terms like minimal changes. What is a minimal change is a very subjective question. We have middlebox issues. Since a middlebox can't do anything useful to an encrypted message and because my objective is to bypass government censorship schemes, my approach is to bypass the middleboxen wherever possible. So I see no value in port 53 whether UDP or TCP. Changing the port number isn't really a major change in the protocol in my view. Sure we could tunnel e-DNS over DNS. In fact I started off doing that three years ago. I even wrote code for that. But why bother when there are plenty of uncluttered UDP ports? ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] A different way to look at the problem
DNS privacy requires us to make two changes to the DNS protocol. 1) The resolver is acknowledged as being a trusted service 2) Some form of crypto is added between the transport and application layer in the client-resolver protocol. So far we seem to have focused on the second issue. But that is the easy one. There is really nothing at all special or interesting in the way TLS or DTLS or my proposal add crypto to packets. That part of the spec can be implemented in an afternoon. The hard part is the consequences of the first issue. Whether or not we want to trust the resolver to give us the right data (integrity), privacy demands that we trust the resolver not to disclose the data (confidentiality). Question: Is anyone proposing that we can achieve DNS privacy while maintaining the current practice of the client defaulting to the DNS server advertised in DHCP? I don't think that is the case. But I thought best to check. Once we decide that the client is going to have a persistent relationship with a specific DNS service we face the problem of how to establish and secure that relationship. The main difference between my proposal and the VeriSign/USC proposal is how we go about achieving that. We are both proposing to use TLS as a basis for this interaction. The difference being that I am proposing to use the TLS infrastructure and PKI path math once to establish a long term credential and the VeriSign proposal is to use TLS on each client-resolver interaction. Now before making a choice between one approach or the other, I strongly recommend people look at what is being proposed in ACME. While this looks like a completely different problem (PKI credential provisioning versus service discovery), it actually isn't. In both cases we have a hard problem and an easy problem. The easy part being the bit that is different and the hard part being how to establish and maintain the binding between the client and a trusted service. I think that if we could factor that part out and make it a reusable component, we would be doing the IETF a big favor. The reason I don't want to use TLS for this is that neither TLS not PKIX is a good tool for this particular job. PKIX ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A different way to look at the problem
On Thu, Feb 19, 2015 at 1:21 PM, Ted Hardie ted.i...@gmail.com wrote: Howdy, On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker ph...@hallambaker.com wrote: DNS privacy requires us to make two changes to the DNS protocol. I'm a little confused as to why this isn't on DPRIVE, but okay. So was I. I typed in DNS-privacy... it ended up in DISCUSS. :-( So lets continue the rest in DPRIV... So let's agree to the framing a bit. There are two exchanges in the current system: resolver to authoritative and client to resolver. It's important that the resolver to authoritative exchange not leak more information to the authoritative server than is necessary (e,g, passing along the client's IP at single IP granularity). Actually that part of the protocol is currently out of scope. We are looking at the client-resolver link first. If/when we get to that part of the protocol we should probably formalize some sort of mechanism to allow the resolver to tell the authoritative what the BGP ASN number of the IP address is precisely to prevent finer granularity leaking while allowing CDNs to still work efficiently. It is useful if the system allows for the traffic between the two be encrypted so that eavesdroppers cannot read them (for large installations with lots of clients behind them, the leakage in that eavesdropping is diffused by the difficulty of associating it with specific clients, so it may not be used everywhere, but it should be possible). I think the work so far has presumed that this exchange is, however, the less urgent one to protect, and that client to resolver is more urgent. Yes, that is indeed where we are. While I would never design a client-resolver loop without also writing a spec for a resolver-authoritative to make sure that both can be handled in a consistent and clean fashion, it is not necessary for us to be discussing both in IETF at the same time. As you note, protecting the exchange between client and resolver so that it is confidential is one critical aspect; encrypting the exchange does that. Having the client able to perform integrity checking (presumably using DNSSEC) allows it to verify that the resolvers is providing the data entered by the zone maintainer. Whose authentication is relevant depends on whether we are doing a layer 5 DNS lookup (A or ) record or a layer 6 DNS lookup (everything else, including TLSA records). Authentication of A and records is certainly desirable in the now obsolete approach of taking the nearest DNS service because you are taking the data from an untrustworthy source. But once we direct our queries to a service we consider to be trustworthy, it is neither necessary nor desirable. It is actually better to let the resolver do the authentication. An A or record is only a binding of a DNS name to an IP address. Absent a fully deployed and 100% trustworthy BGP infrastructure, that does not provide a secure binding to the endpoint. There are certainly good reasons for wanting to provide DNSSEC records for A/ to the resolver but there isn't a good case for the client checking. [Again, TLSA and other security policy records are a totally different matter.] Allowing the client to rewrite A and records allows a DPRIV resolver to provide DNS64 service so an IPv6 only client can function without any IPv4 support at all. Whenever it tries to access an IPv4 only resource, the resolver gives it an address at NAT64 gateway. But that is a digression. The critical issue here has often been latency--clients have been reluctant to do that in real time, as the resulting increase in latency was bad for operations. There may be ways to improve that--by having the resolver perform those functions but also consistently provide the client with the data used to verify, so that it can cross-check at some configured rate (trust, but verify). In my current proposal, all the crypto in the client-resolver interaction loop is done using symmetric key cryptography and a Kerberos ticket like scheme. The performance impact is negligible. Given the current state of the CFRG discussion on ECC curves, the use of Curve25519 in place of the symmetric crypto is certainly worth considering but it does not change the design very much. The other issue you raise--can you trust the resolver not to forward the data to some third party? That depends on your definition of trust. I define trust as being able to accurately estimate the probability of default and determine that it is within acceptable limits. What is key here is being able to chose your own trust provider. And there are tradeoffs. You can't get privacy in this particular instance by deciding to little red hen it and do it yourself. That is like trying to hide a tree in the desert. You need a large portal like Comodo or Google with a few million customers to be able to hide. boils down to a relationship question for which there are a couple
Re: [dns-privacy] Agenda for DPRIVE in Dallas.
On Tue, Feb 3, 2015 at 11:01 AM, Warren Kumari war...@kumari.net wrote: Hi all, The Dallas meeting is approaching, and we'd like to start getting the agenda organized. Please send us requests for time, etc. We have not made nearly as much progress since Hawaii as we'd hoped for / expected - sorry. Tim and I hope to chat early next week to discuss how to move things forward... The key for me is are we going to design a protocol that is designed to be part of the Internet core and replace legacy DNS for the client-resolver loop or are we just going to produce a protocol that makes privacy possible when needed. My criteria for the two approaches are very different. If we are doing core architecture then what matters is the absolute size of the library needed to implement the DNS-Privacy protocol. If on the other hand we are just trying to provide additional privacy for Web users then what matters is the delta between the standard Web stack and the new. Since writing my original Private-DNS protocol, I have made some improvements that I should be able to share in draft form soon. In particular, progress in the ECC debate in CFRG means I am no longer so worried about putting public key crypto in the client-resolver loop. But I still want to be able to insulate the hosts performing DNS lookup from arbitrary Internet users attempting to connect to them. So I still want to separate the process of validating and credentialing an account at a DNS resolver and making query transactions. I have also made some progress on the problem of using private-DNS in situations where strong privacy guarantees are required but I am not yet ready to disclose these. What I can say now is that if people want to have maximum flexibility in making DNS clients effectively anonymous to resolvers, then the preferred approach is to decouple the application of encryption and authentication to DNS packets from the key negotiation interaction. For obvious reasons, there is a limit to the extent to which we can produce privacy protection protocols in a public process such as IETF that are going to be effective in environments where the network is controlled by a hostile government. So rather tip our hand to the dictators, I would prefer to produce a protocol with one component that can be swapped out to make such changes and clearly mark it as such. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Clean architecture as a requirement.
One of the questions we have to ask ourselves is what sort of DNS privacy solution are we aiming to provide here. Is it meant to be A) A replacement for the DNS client-resolver protocol intended to eventually replace it. B) A scheme that allows those who want to achieve DNS privacy to do so My goal is to achieve A. However given the constraints that any clean architectural solution needs to deal with (UDP port blocking, etc) and the requirement to maintain 100% connectivity, that probably means accepting some sort of plan B as a backup. The reason this makes a difference is that there are a number of engineering approaches that are completely closed off if the objective is A. We can't expect to use a mechanism that tunnels encrypted DNS inside DNS as a long term replacement for the protocol. It also goes to the approach to scoring proposals. If we are looking to only achieve B then the simplest approach is to leverage as much existing infrastructure as possible. But if we are looking at A then we have to propose something that is the smallest possible increment on a minimal TCP+DNS stack. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Non-DNS traffic over port 53?
While tunneling over DNS is interesting, it isn't really the answer to our problem which is how to establish a robust and efficient encrypted DNS protocol. DNS tunnels tend to be used by folk willing to tolerate low bandwidth and low latency. Cramming your requests into BASE32 encoded labels and your responses into BASE64 encoded TXT fields comes at a cost. That is fine if the only lookups you want to do are A and but not so great if you want to do DNSSEC. There are ways to do efficient discovery over a DNS tunnel, in fact that was the original rationale for Omnibroker. Faced with a lossy, low bandwidth channel, I decided to compress multiple queries into one. The much simpler solution is to abandon the use of port 53 for encrypted DNS and negotiate the port number along with the crypto parameters. UDP works fine on non port 53 in over 95% of cases and most importantly, there is no way for British Telecom to know that you are making a DNS query so they can redirect your requests for google.com to their proxy which does SSL stripping - like I found them doing to me over the weekend. Lets just get over the well known port concept. It is not scalable and it is not necessary for what we are doing here. Do the connection establishment over port 80 or port 443 and let the attacker guess what the service port is. For the rare cases where you can't do port 53 then you can either fall back to DNS tunneling or to HTTP/HTTPS. In the first drafts of Omnibroker I suggested both but figures from the TLS faction here convince me that we don't really need both. On Tue, Jan 6, 2015 at 3:28 PM, Tao Wan tao@huawei.com wrote: Hi Warren, You may find the following paper interesting, albeit not exactly what you are looking for: Practical Comprehensive Bounds on Surreptitious Communication over DNS (by Vern Paxson, et al). https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/paxson It analyzed 230 billions of DNS lookups, and found 59 confirmed tunnels established over DNS. Cheers, Tao Wan -Original Message- From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of Warren Kumari Sent: Tuesday, December 30, 2014 12:24 PM To: dns-privacy@ietf.org Subject: [dns-privacy] Non-DNS traffic over port 53? Hi there all, First off, apologies for the lack of activity since Hawaii. We (the chairs) have been procrastinating and got a little sidetracked with day-jobs. We are finally getting our lives organized, getting github setup for issue tracking, etc. One of the open questions is how to deal with / how bad the infamous middlebox problem is. This will somewhat dictate what solutions we are able to consider / will work in the real world. So, I was wondering if anyone has any data / has seen any research on just how well non-DNS traffic works over port 53 - UDP and TCP? So, if one tries to pass $random_protcol over port 53 from behind various CPE / firewalls / IPS / etc how likely is it to work? Many years ago I tried running VPNs and SSH over port 53 to try and deal with broken captive portals (Ok, it was more to avoid paying what I viewed as usury rates / to avoid icky ACLs). This had mixed success (used to work somewhat OK, but then got slowly less likely to work over time) - obviously this was a special case, knowing how this works in general / today would be very useful to informing what solutions are worth pursuing. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE next steps
On Mon, Nov 24, 2014 at 4:22 PM, Tim Wicinski tjw.i...@gmail.com wrote: (I was waiting to confirm the wording with Warren, but I failed to remember he was away last week). Coming out of IETF91, we saw good discussion around the problem statement; the beginnings of a discussion around evaluation metrics; and several different solutions searching for the appropriate problem. And how do we go about that? The reason I am very skeptical of the value of requirements exercises in IETF is that my experience is that they are almost invariably a proxy fight for the solution space and in particular a fight to frame the requirements so that a particular favored solution is the winner. Which is why I believe that requirements capture should be driven by use cases and there should be NO discussion of whether the use cases are valid or not. Bear me out on this, I see no point in spending six weeks arguing about whether a use case is important or not or what the relative order of priority should be. Such efforts are invariably an underhand approach to constraining the solution space so that the favored proposal wins. Rather than developing a requirements document, a Wiki would be much more appropriate. And no need to turn it into an RFC either. I am sure that if you narrow the scope of the work down it is possible to find a viewpoint from which the differences between them disappear. But what is the point in doing that? The point is to make a decision and to make a decision, differences are useful. Then we would like to see some action on the evaluation document. I know when I spoke with Allison they were having some resource scheduling conflicts, and I had offered to assist with the document if there was a working outline. Perhaps others will feel so inclined. I submitted such a framework some time ago: http://tools.ietf.org/html/draft-hallambaker-dnse-02 ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS
On Wed, Nov 19, 2014 at 2:43 AM, Dan Wing dw...@cisco.com wrote: On Nov 13, 2014, at 10:24 AM, Phillip Hallam-Baker i...@hallambaker.com wrote: I see two distinct use cases: 1) Web browsing 2) Everything else. The challenges for (1) are latency, latency and latency. Shaving 10ms off the response of a browser is very important to the Web browser team. Folk can argue that it should not be, but that is the situation. If we are going to do DNS over TLS then looking at the existing Back to my MAC protocol makes sense. But the caveat is that does not look like an application where ultra-low latency is a requirement. There are two ways to address the latency issue for Web browsing: 1) Design a protocol tuned for ultra low latency with 1 round trip over UDP. 2) Combine the DNS requests with other data requests that the browser would make. Private-DNS takes approach 1 (D)TLS 1.3 takes approach 1 with TLS 1.3, which is optimizing for 0 round trip (for servers previously used) or 1 round trip (for new servers). If its 1 round trip then we are talking about DTLS not TLS. The thing I didn't like about using DTLS is that I have to profile pretty severely to make the code footprint minimal. And once you profile you have to rewrite libraries to only use the profile features. TLS has a stateless session resumption option but it would need to be mandatory for DNS over TLS to be viable. And it would have to be possible to set decent sized timeouts for the negotiated sessions. On the performance side, PRIVATE-DNS is providing better performance for the typical approach of doing an A and a record lookup in parallel since these are typically handled in one request/response packet rather than two. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS
On Wed, Nov 19, 2014 at 12:08 PM, Dan Wing dw...@cisco.com wrote: On Nov 19, 2014, at 4:05 AM, Phillip Hallam-Baker i...@hallambaker.com wrote: On Nov 13, 2014, at 10:24 AM, Phillip Hallam-Baker i...@hallambaker.com wrote: The thing I didn't like about using DTLS is that I have to profile pretty severely to make the code footprint minimal. And once you profile you have to rewrite libraries to only use the profile features. Umkay. It is good you have personally concluded that a completely new library and new protocol is better than profiling DTLS, but I don't yet share that conclusion. I don't think it is helpful to thing in terms of the number of libraries or protocols involved. I would rather add a new library of 10K code than grow an existing library from 200Kb to 300Kb. I am really not writing a whole new protocol here. What I am doing is decoupling the key negotiation part of TLS from the framing part by introducing a small amount of JSON. On the performance side, PRIVATE-DNS is providing better performance for the typical approach of doing an A and a record lookup in parallel since these are typically handled in one request/response packet rather than two. If also SRV and arbitrary other resource records invented in the future, that sounds compelling. SRV, TLSA, plus new security policy records to be defined all with DNSSEC. So lets say you want to connect to www.example.com via HTTP, the DNS queries might be: www.example.com ? A www.example.com ? _80._tcp.www.example.com ? TSLA _http._tcp.www.example.com ? SRV _http._tcp.www.example.com ? ESRV (A security policy record TBS) Note that while the existing DNS protocol supports multiple queries in theory, it does not support multiple response codes which makes it pretty useless. So the above would be five separate DNS protocol messages all framed in a single UDP packet. In most cases the results will fit in a single packet as well. Taking away the performance penalty for multiple record lookups would make a huge difference to the viability of proposals to extend DNS discovery services. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS
On Wed, Nov 19, 2014 at 12:13 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Given that the problem statement for the group is stub-to-resolver, and a stub generally uses one resolver, it is quite believable that one would have a TCP connection open to the resolver that is reused for future DNS queries. After the initial TCP connection to the resolver (which is normally done before the first web page request), the speed of the request is the same for an open TCP connection as it is for a new UDP connection. That becomes very problematic when running a big public DNS server. Basically it would require every client to keep a TCP connection open permanently. That is a huge load. I have 40 computers with IP in this house that are used regularly. My network traces are clogged enough without TCP keepalive packets. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS
On Wed, Nov 19, 2014 at 8:09 PM, John Heidemann jo...@isi.edu wrote: On Wed, 19 Nov 2014 22:33:14 +, Mankin, Allison wrote: One small addition. That's an our older tech report, and that link is now broken. The current version is TR-693, at http://www.isi.edu/publications/trpublic/files/tr-693.pdf (the old version is now http://www.isi.edu/publications/trpublic/files/tr-688.pdf for folks who want to wax nostolgic about where DNS-over-TCP and TLS was back in Feb. 2014 :-). Referring to table 7 in the report. This is giving average time for a DNS transaction but as I explained to Alison, the issue for browser providers is how fast their page loads. Any chance you could run the numbers and identify the times for the first load? Even on those numbers, one round trip 62% of the time is not the same as one round trip 97% of the time. I do however strongly agree with Alison that we are going to need more than one protocol because we have to achieve 100% connectivity. And that means being able to bypass hotel and coffee shop DNS. That means either DNS over TLS or HTTP with encrypted content (or both). What I like about DNS over TLS is that we get the ability to use multiple records. I think that is an important feature. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] changing protocol vs. using existing mechanism
On Fri, Nov 14, 2014 at 10:42 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: Hi, There is one question from folks. There are some existing approaches that does not change DNS protocol. There are also new proposal that needs change on DNS protocol. For example, my proposal, cga-tsig, does not change DNS protocol. So is there any decision for the scope of solution space? I don't think anyone is actually proposing to change the DNS protocol. PRIVATE-DNS doesn't. Paul's might but I don't think that makes a difference. Looks to me as if you don't quite understand what my proposal does, I note the following statement in your draft: https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-10#section-1.1.4.1 Private DNS [private-dns] is one of privacy approaches that uses TLS and consider using JSON. To establish a secure communications, many messages needs to back and forth because the assumption is that a node itself needs to verify the TLS certificate. No, that is not at all what is going on. PRIVATE-DNS consists of a one-time device binding operation and that is the only part that involves JSON or multiple round trips. DNS lookups are stateless, single request packet, multiple response packet interactions. - Might not have good performance (number of messages exchanged to establish this secure communication) No, the performance os Private-DNS is optimal, there is no improvement possible over one round trip with no public key operations (or other CPU intensive operations) in the transaction loop. - IP spoofing and MITM might be possible only when there is no CA or predefined Trusted Anchors (TA) so that it makes it possible for an attacker intercepts this communication at the beginning of TLS establishment. Obviously there needs to be some means of authenticating the service or you could be permanently binding yourself to a MITM attacker. There are two main choices: 1) For a public service then a WebPKI TLS certificate is probably the best choice. 2) For an enterprise service in which the user is issued a one time use PIN, the SXS-Connect protocol provides mutual authentication. So the client is authenticated to the server and the server to the client. I have not fully considered the case in which the device does not have a trust root built in for (2). This is important for cases such as a constrained device that might have a ten year shelf life. I have a possible solution but I have to verify it. Since this is TLS we could use any server authentication mechanism supported by TLS. For example DANE. But using DNSSEC to secure the DNS client resolver binding gives us a circular dependency issue. It would probably be better to use a direct trust model. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS
I see two distinct use cases: 1) Web browsing 2) Everything else. The challenges for (1) are latency, latency and latency. Shaving 10ms off the response of a browser is very important to the Web browser team. Folk can argue that it should not be, but that is the situation. If we are going to do DNS over TLS then looking at the existing Back to my MAC protocol makes sense. But the caveat is that does not look like an application where ultra-low latency is a requirement. There are two ways to address the latency issue for Web browsing: 1) Design a protocol tuned for ultra low latency with 1 round trip over UDP. 2) Combine the DNS requests with other data requests that the browser would make. Private-DNS takes approach 1 OmniQuery takes approach 1 and 2 Once you decide to combine data feeds, you have changed the protocol anyway and might as well tune for performance. On Tue, Nov 11, 2014 at 2:45 PM, Stuart Cheshire chesh...@apple.com wrote: I’m unable to attend the DPRIVE meeting in person because it overlaps with TAPS. I see on the agenda discussion of items like Private DNS and DNS over TLS. A historical note: Apple’s Back to My Mac service uses DNS over TLS to provide confidentiality for the queries. This is described in RFC 6281. The client looks up the SRV record “_dns-query-tls._tcp.example.com” to find the target host and port which will answer DNS-over-TLS queries for the domain “example.com”, and then the client sends subsequent queries for “example.com” names directly there (bypassing the local DNS cache). Stuart Cheshire ___ 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] Consensus and Compromise
On Thu, Nov 13, 2014 at 9:41 AM, Paul Wouters p...@nohats.ca wrote: On Thu, 13 Nov 2014, Hugo Connery wrote: 2. Trust between clients (stubs) and recursive resolvers Whether the communication to the recursive resolver is encrypted or not the resolver itself knows all queries (data and metadata). There is an implicit trust relationship between the client and recursive resolver. This is a political rather than technical issue (unless some PIR style solution is pursued) and is probably outside the scope of DPRIVE. I would like to see that any solution would actually tackle this problem. A more and more common scenario is to only use local DNS for bootstrap and then rely on another non-local DNS server outside the control of the local network. For example, if Google DNS could advertise a resolver public key than I could use the hotspot DNS to pay/click ok, and then only send encrypted DNS to Google so the local network cannot see any of it. Actually, we probably want to have a mechanism for using encryption on DHCP as well. It would be a way to close the WiFi evil twin issue. I don't think this area actually has a bearing on choices between proposals as we are all using TLS at the front end. The only divergence is whether to use it on the back end or not. So lets say we are in Panera. The coffee shop is a national chain that wants to assure customers they are going to the real panera. They also want to do a splash screen for TC. Right now the mechanisms for implementing that are folklore which is bad. I see the following approaches: 1) Advertise a DNS name, IP address and URI in a DHCP record. This is the simplest, the hotspot only wants to provide the data for the very limited purpose of TC. Making it part of DHCP allows the platform to present the TC dialog etc. 2) DHCP record for DPRIV DNS This would be for a promiscuous DNS service that can be used for the TC transaction and then ignored thereafter. Problem with this is that it tends to be flaky, it is not clear where the TC bit starts and ends. 3) Regular DHCP with upgrade in the DNS transaction. Some EDNS option to tell the client that DPRIV is available... Caveats: 1) Panera is not going to worry about the cost of an EV cert to establish their WiFi service is genuine. For a small coffee shop or non commercial WiFi this would not be an acceptable cost. Nor would the CA service really add much to a service provider with a single site. For the home user, getting an EV cert is definitely out of the question. 2) Panera is doing DNS interception because they don't want people surfing to sites showing pictures of nakid people in their cafe. Hard to see how to reconcile this with censorship bypass because its incompatible. The coffee shop would still have the option of filtering on IP addresses though. The same scenario would apply to ISPs whose nameservers people would like to not trust or use. 3. Recursive to Authoritative Without the possibility of encrypting this stage, the client becomes anonymous within the community that is using the recursive resolver. Encrypting this step may be too much for now (and it will incur challenges for auth resolvers). If omitted, I hope that the community will re-visit the issue. Agreed. This problem is very hard because it is a DOS against authoritative servers. Paul ___ 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] DNS over TLS
On Thu, Nov 13, 2014 at 10:29 AM, Joshua Smith jsm...@mail.wvnet.edu wrote: On Thu, Nov 13, 2014 at 10:24:13AM -1000, Phillip Hallam-Baker wrote: I see two distinct use cases: 1) Web browsing 2) Everything else. The challenges for (1) are latency, latency and latency. Shaving 10ms off the response of a browser is very important to the Web browser team. Folk can argue that it should not be, but that is the situation. Perhaps this is a case where anyone wishing to make use of the additional privacy/security features provided from using DNS over TLS will need to accept the trade off that the addition comes at a performance cost? No, there is a proposal that meets the performance criteria. I see no reason to force users to choose between security and performance when the simplest, best proposal provides both. Do you? Especially if you consider the case where your local (stub?) resolver caches the responses I would imagine that after the first few minutes of browsing, once the cache is reasonably populated, that the overall performance impact of the changes will approach nil. That would be an incorrect assumption. Talk to the Chrome team. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Scorecard for DPrive proposals.
We have three proposals on the table. The question is how to score them objectively. One approach would be to ask some party that runs a public DNS responder which of the protocols they are most likely to support. So feedback from a Verizon or a Google/8.8.8.8 would be useful. Another point to consider is whether we judge proposals as they stand now or accept modifications. I have been working on my proposal for 4 years. I have developed one code base, abstracted it, generalized and then reified the original problem in the general framework. So I don't expect my proposal to change much unless someone brings up a use case that I haven't thought about. When we get to scoring however, I know that a response to every one of the feature deficiencies I see in other proposals can be fixed. I know because I have travelled that same path before. And the reason I decided on the architecture I did was that it was the approach that required least changes to and least invention on top of existing work. The point is that if we are going to have a fair basis for comparison then either we have to disqualify proposals that don't meet the necessary feature set or we have to agree those features aren't required or we have to let people change their proposals to add the cruft necessary to meet the requirements before a comparison is made. 1) 100% connectivity There are two compliance levels that might be proposed: A) The protocol has to work in any network situation where normal DNS works OVER UDP B) The protocol has to work in any network situation where http works DPLS was originally designed to meet the stronger criteria. Private DNS only meets the second but could easily be extended to meet the first if necessary. The reason for making this change is that there are few places where DNS over UDP works but http does not. The reason that I invented what is now SXS-Connect in the first place was precisely because I can't meet that 100% connectivity requirement without some form of transport agility. It is in effect a super SRV record. Of the proposals on offer, Paul's DNS over HTTPS is the only other one that comes close to meeting this requirement. But do note that HTTPS is banned in a lot of countries. Now this probably does not make much difference if we are talking about a country like Russia or China that has permanent police state apparatus in place. But it does make a very big difference if we are talking about a situation where a government is trying an Internet crackdown to suppress evidence of government corruption ahead of an election or the like. 2) Basis for performance comparisons. If we are looking at privacy then we should be looking at the performance impact on a heavily trafficked public DNS service like 8.8.8.8, Comodo's public DNS, etc. The reason for this is that we need to be able to aggregate client requests sufficiently to avoid traffic analysis giving the game away. Large public DNS resolvers try to reduce in-band lookups to the absolute bare minimum. This is going to be even more important when DNSSEC is finally deployed because its not just about caching the DNS records and avoiding the round trip hit, its about minimizing the inband DNSSEC path math. So large public DNS resolvers will typically prefetch well trafficked DNS records on expiry of the old records. The cache hit rate for labels that exist should be well in excess of 90%. Therefore to compare like with like we have to compare round trips and public key operations for the case where we get a cache hit. Private DNS = 1 round trip, 0 public key operations, 0 server state Everything else is more. 3) DoS resilience There are several different types of DNS DoS attack. There is the attack on the resolver itself, there is the attack on an authoritative through the resolver and there is the third party attack. Private-DNS is the only proposal that considers these at all. Simply adding cryptography to the existing protocol is not a neutral change. You are going to make it impossible for ISPs to mitigate DNS attacks coming out of their networks except by blocking DPRIVE DNS. 4) Building on existing standards. I think I win this one as well. It is not possible to solve this particular problem by just slapping DTLS or TLS onto DNS. Every single one of the proposals has to add some mechanism. I arrived at my approach because it uses the least additional mechanism. It is considerably simpler than TDNS today and is a lot simpler than TDNS with the necessary extensions to address essential requirements. The problem with trying to fit TLS or DTLS into a DNS protocol is that TLS is layered on top of PKIX and the DNS. DANE does not help at all because we hit a bootstrap problem of trying to use the DNS to get records to use the DNS securely. 5) Capable of extension to stricter security requirements. Yes, I have considered cases where very high levels of concern are warranted. The SXS-Connect key exchange is a mutual
Re: [dns-privacy] Verisign patent disclosure
Was anything published? Sent from my difference engine On Nov 5, 2014, at 11:04 AM, Ray Bellis ray.bel...@nominet.org.uk wrote: On 29 Oct 2014, at 18:50, Rubens Kuhl rube...@nic.br wrote: What constitutes prior art, an idea or implementation of the idea ? Would the 2007 implementation of a botnet with a built-in recursive resolver that sends QNAME-minimised queries to the root to find the relevant TLD NS records count? Ray ___ 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] What about CGA-TSIG as a solution for DNS privacy?
On Mon, Oct 27, 2014 at 10:45 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 27, 2014, at 7:36 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: So why do you think it is distraction for the WG that addresses privacy? I said I thought it was a distraction; discussing it further would be more of a distraction. Which is not a polite or acceptable fashion to deal with a proposal. Like many people I have been looking at applying TSIG more generally for many years. I think the approach is architecturally sound from a security point of view but it isn't a complete solution and when you start to extend it to meet the use cases here it soon becomes apparent that reuse is hurting more than helping. TSIG is only authentication so you have to add encryption. And the original TSIG assumed keys would be passed out of band so it needs a key exchange. So lets divide the protocol into two parts, a key exchange that establishes a shared secret and some form of packaging that applies encryption and integrity operations to the DNS messages. The second part is straightforward. People can agree or disagree as to whether my attempts to optimize the transport for DNS deliver worthwhile benefits, we can argue over the specific encoding (I picked the TLS schema). But what is clear is that it should be very simple to describe and implement or its being done wrong. The key exchange is the place where the design choices come in. And here we have two approaches: 1) Reuse something already existing (CGA-TSIG, DTLS). 2) Write something new designing it so that it could be reused elsewhere. I believe the second course is the best approach in this case. I am not re-inventing the TLS crypto but I am presenting it as a JSON web service in a way that allows for reuse. CGA does not meet the use case requirements I see for the Enterprise where it has to be really easy to bind a device to a DNS service. For embedded devices it has to be 'scan a bar code' level of simplicity. And I know that we are not talking about those use cases now. And I don't really want to have to talk about those cases now either. Instead I want to have a mechanism that can be implemented very simply to meet most of the use cases and can be extended later as needed. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Sun, Oct 26, 2014 at 10:59 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Sat, Oct 25, 2014 at 07:35:11PM -0700, Watson Ladd watsonbl...@gmail.com wrote a message of 54 lines which said: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. You seem to consider that DPRIVE = encryption of the stub-to-resolver link and nothing else. But DPRIVE may work on other things that will improve the situation such as recommending local (local = on the user's machine or network) resolvers before, or instead, IAP's resolvers. One of the main reasons we get little done in security is that people tend to derail discussions of the possible with demands for the perfect. The other main reason is reductionism, demanding security solutions that only fit in one box. Traditionally the IETF demanded end-to-end security on a take it or leave it basis. And so today 99.99% of email is not encrypted with PGP or S/MIME. But something like 50% is secured using STARTTLS. The reason I originally designed OmniBroker and PRIVATE-DNS was that I have spent over ten years trying to get browser providers to implement DNSSEC so we could do security policy and I know the constraints they raise. Their #1 concern is to minimize latency. In security concerns, preventing state censorship is probably a higher concern than privacy. But only Mozilla is likely to give a candid answer on that. So we have a hierarchy of security concerns. 0) [Solved] Authenticity of authoritative data 1) Authenticity, Integrity and Confidentiality of DNS stub-resolver traffic 2) Confidentiality of DNS resolver-authoritative traffic 3) Disclosure by the resolver We can address (1) very simply and cheaply and do so in a fashion that is compatible with (3). What we can't do is to provide (3) without severe impact on latency. And if you don't solve the latency problem then you end up with the Harvard TOR-DOX issue. Use of TOR is very thin so any use of TOR becomes suspect. So when someone called in a bomb threat to avoid taking a final that day, all the Harvard police needed to do was to look at the campus network logs, find out who was using TOR when the threat was called in and call them both in for interrogation. We can address 1 and 2 with encryption. But solving 3 properly requires steganography. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Sun, Oct 26, 2014 at 11:09 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 25, 2014, at 7:35 PM, Watson Ladd watsonbl...@gmail.com wrote: Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why? Because we were lazy, and solved the easy problems instead of the worthwhile problems. Or: because we don't have the same threat model that you are proposing, and we want something deployable. Nothing in the current proposals prevents you from proposing your still-academic PIR proposals for a longer-term solution that applies to people who agree with your threat model. Well some of the proposals are better suited to dropping in an alternative privacy protecting transport layer such as TOR than others. This is a use case I have considered in depth for an interested party. SXS-Connect allows a service to specify the transport. While UDP and TCP are the defined values, someone could use TOR. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] Qname minimization IPR
Paul, It is a VeriSign patent, its just being shown on the Google patent serach engine On Sat, Oct 25, 2014 at 1:53 PM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer bortzme...@nic.fr Saturday, October 25, 2014 2:24 AM [Copy to dnsop since the qname minimisation draft is now a WG item at dnsop.] On Thu, Oct 23, 2014 at 10:21:57AM -0700, David Conrad d...@virtualized.org d...@virtualized.org wrote http://www.google.com/patents/EP266A1?cl=en importantly, google's policy is to use patents only in defense. i've requested that they make that explicit in the case of this particular patent, but, that's a small detail. i believe that query minimization should proceed as though this patent did not exist, for the good of the internet economy. (if it fails to reach consensus that's a different matter, but, let it not be because of this patent.) -- Paul Vixie ___ DNSOP mailing list dn...@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A pool is not an onion
On Sat, Oct 25, 2014 at 10:35 PM, Watson Ladd watsonbl...@gmail.com wrote: On Sat, Oct 25, 2014 at 7:04 PM, Phillip Hallam-Baker i...@hallambaker.com wrote: I think that we have to go back to the original goal, to reduce leakage of information so that we only disclose where there is a need to know. The authoritative does not need to know who is making the request. The TLD does not need to know the complete query. At some point a recursive somewhere does need to know that a query is being made. That puts client/resolver leakage in a different category to client/authoritative. Before DPRIV: anyone who owns the DNS box at an ISP can see all dns-queries go through, and know who made them. After: exactly the same. Why? Because we were lazy, and solved the easy problems instead of the worthwhile problems. After the box does not have to be at the ISP. After, you get to choose. Yes protecting that data might warrant investigation. Yes, I and others can suggest schemes that would provide that protection. No, this is not costless. No this is not a low hanging fruit. No this should not be our focus in DPRIV right now. So we shouldn't solve the problem we want to solve, because solving the problem we want to solve is hard, so we should solve the problem we can solve and fool ourselves into saying we wanted to solve it, and hope no one else notices? Put me down as thinking that this is a terrible idea. I am not at all convinced it is a problem that the world does want to solve. By which I mean , wants to solve badly enough to fund the necessary resources. I have a protocol, sure. But I don't have a business model that is likely to drive the deployment for general purpose adoption. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] The case for both ends of 'end-to-end'
On Thu, Oct 23, 2014 at 5:52 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 23/10/14 09:04, Jelte Jansen wrote: To name one: the bigger the shared resolver, the higher the chance the three letter agencies want and might have their taps there. So IMHO Joe is simply shifting trust here, not necessarily in- or decreasing it. Yes, that's possible and we should figure out what's likely to be better in terms of deployment. But out first job is to define an agreed interoperable way of getting confidentiality. When we're done I'm sure people will figure out how best to (ab)use that;-) The objective here is to greatly reduce pervasive surveillance rather than eliminate all possibility of vulnerability. Forcing an adversary to perform an active, intrusive attack rather than a passive attack is a substantial increase in work factor and increases the risk of disclosure of the attack. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Padding (Was: Re: Confidentiality from Iterative to Authoritative resolvers.)
On Thu, Oct 23, 2014 at 8:08 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: I think the answer to this question may be a simple no, don't but it if were not, it might be something that'd improve privacy for both stub-recursive and recursive-authoritative without changes to the DNS, but probably requiring some new protocol to run alongside. Anyway... On 23/10/14 12:36, Hugo Maxwell Connery wrote: DNS information is clearly public information. But that does not mean that one needs to publish *who* is accessing that public data. Another way in which one could conceivably do that is by issuing bogus requests, (i.e. padding) which attempts to mask not who is asking but which answers are of interest. That isn't what I would call padding. Increasing the length of genuine request packets to resist traffic analysis has a lot less cost than generating spurious traffic. Yes, I might do that sort of thing in an application designed for people who are surveillance targets but the cost/benefit really does not justify generating traffic noise as a general rule. In Private-DNS I support padding to obfuscate traffic analysis based on the length of a request because this can actually leak rather too much information. So for example, consider the case in which someone is going to www.cnn.com, or www.bbc.com or the like. Short domain names are valuable and so most are used by sites that generate a lot of traffic. Folk who are visiting such sites are probably not doing anything unusual. The longer the domain name, the more likely someone is doing something unusual. Padding request packets to a multiple of 64 bytes greatly reduces the value of collecting this data and imposes negligible additional cost. That wouldn't have to be a case of sending queries for randomly generated names, but could be based on some form of gossip between a bunch of e.g. recursives or something. So the bogus request that one sends out might actually be for a domain that was a real request from another gossipy recursive a while ago. I don't like the idea of makework traffic but one potential benefit of DNSSEC is that such traffic could well become rather useful. I suspect that there's not much to be gained by doing that in the end, and it'd clearly have costs, (though with gossiping one might limit those by getting a lot of cache hits) but I wonder if anyone has looked at this kind of thing in detail already? Back in the early days of the Web there was a project called Harvest that made use of such approaches. That project led to the technology behind Tucows. It also spawned the squid reverse proxy. This was HTTP layer rather than DNS, but the architecture worked fine. This isn't something I would necessarily endorse for general use. But if I have a resolver that gets a request packet from Iran and a cache miss, I might well want to disguise the contact to an authoritative by routing through a sister resolver. But preventing that being spotted would probably require me to be doing enough chatter with the sister for other purposes to hide the traffic. This is one of the reasons I designed Private-DNS the way I did which is as a general purpose layer supporting fast Web Service transactions. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] The case for both ends of 'end-to-end'
On Wed, Oct 22, 2014 at 4:08 PM, Paul Ferguson fergdawgs...@mykolab.com wrote: Apologies for the top-post and the length of quoted text, but I wanted to retain some context of Vixie's remarks. I would also like to express my concern on the similar issues that Vix expressed here, but perhaps a dprive implementation and architecture document would be a good idea? I am afraid that this efforts gets too far down the path before realizing how some implementation of the privacy path before realizing that the scheme breaks things like passive DNS collection. For security operations folks, pDNS data collection is an imperative in how we do reputation, etc., especially consider where the encryption path is implemented: What on earth is passive DNS and what is the use case for it? [I know, but I am certain most folk here don't or the conversation would be different] Your 'passive DNS' is just another form of intercept. I am not obliged to trust your good faith and promise not to abuse that information any more than the NSA, KGB[1] or PLA. Calling it imperative does not excuse having collected it without explicit consent. No, the fact that some folk like visibility into the system to collect data does not mean that they get to keep that data channel open in perpetuity because they got there first and have 'dibs' on that data. The data should not have been visible in the first place. Has anyone gone through a human subjects review before collecting this data? Seems to me the fact that RFC 1262 hasn't been updated in quite a while should worry a few people. [1] Like Windscale they rebranded when the name became notorious but its the same thing as before. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNScurve limits (Was: Agenda time.
On Mon, Oct 20, 2014 at 10:02 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 20, 2014, at 1:25 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Tue, Oct 14, 2014 at 10:04:14AM -0400, Paul Wouters p...@nohats.ca wrote a message of 80 lines which said: I understand your wish for dnscurve to be useful, but it is unfortunately not more than that. dnscurve authenticates and encrypts traffic from stub to auth servers. It's core to its design. If you take that away, you are left with some specific ECC curve encryption. I disagree here. The work to port DNScurve to the stub-to-resolver link has already been done. It is called DNScrypt http://dnscrypt.org/. It is actually deployed http://www.opendns.com/about/innovations/dnscrypt/ And, after many attempts by people here, it is still undocumented. The is a bit of a protocol description, but it is fairly incomprehensible, other than we're using great crypto!. +1 The task here isn't to produce a great protocol. It is to document a great protocol in such a fashion that others can produce interoperable implementations with minimal effort and confusion. And by great we mean that it is efficient and secure, but also it should follow a design pattern that is compatible with the IETF approach. Designing a crypto protocol is not the difficult part, documentation and deployment are. By compatible with IETF approach I don't necessarily mean 'follow existing practice' but any new approach should have clear advantages over existing. So in TRANS, the spec is built into PKIX and uses ASN.1 where this is appropriate. But noting that TLS is built on a different encoding and schema language which is better (in the same way that stopping hitting yourself on the head with a hammer is better than continuing), TRANS uses the TLS approach rather than ASN.1. I don't see using DNSCurve as it is to be an option. At minimum we would need thorough documentation. But I think we would also want to align DNSCurve with the rest of the IETF infrastructure. In particular consider using existing DNSSEC or TLS or PEM code points to describe algorithms. Once you get into documenting a protocol, the need for a schema language becomes clear. In the 18 years its been public I have never once heard anyone say that the TLS schema or encoding was problematic in any way. It certainly makes the spec a lot easier to follow. People can of course argue that the logical conclusion of being IETF compatible would be to 'simply' use DTLS. But that is only the easiest approach if you are already committed to having a TLS library. Which is fine for a desktop but a really bad commitment for an embedded device. My proposal does cheat by reusing TLS right now and that is a completely defensible long term strategy for desktops, mobile devices etc. I do not think that is a defensible long term choice for DNS which needs to be a very simple protocol that can be implemented in a few thousand lines. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoption: draft-bortzmeyer-dnsop-dns-privacy
I support adoption and have made some comments to the list already. I am not sure if we need to eventually publish the document as an RFC however. In particular I don't think we should try to get that doc perfect before going on to the real work of building protocols. It should be a running summary of the design rationale for the current proposal(s) we are working on, not a rationale for something we plan to build. In my view, it is exactly the type of document the RFC series was originally intended to publish. But getting such docs through IESG last call can be rather wearing. On Fri, Oct 17, 2014 at 12:41 PM, Warren Kumari war...@kumari.net wrote: Dear DPRIVE WG, This starts a Call for Adoption for draft-bortzmeyer-dnsop-dns-privacy. [ Please note: I am assuming that Stephane and DNSOP are both OK with us adopting this. It is referenced in our charter, and so might be adopted by reference, but figured might as well appease the process gods by doing this officially... Short CfA because it seems obvious...] The draft is available here: https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/ Please review this draft to see if you think it is suitable for adoption by DPRIVE, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends Fri 24-Oct-2014. In addition, to satisfy RFC 6702 (Promoting Compliance with Intellectual Property Rights (IPR)): If you are personally aware of any IPR that applies to draft-bortzmeyer-dnsop-dns-privacy, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] DPRIVE is officially a WG.
I didn't even know that it was optional. Certainly namedroppers wasn't allowed to keep its name despite a twenty odd year history. On Sat, Oct 18, 2014 at 11:58 AM, Warren Kumari war...@kumari.net wrote: On Fri, Oct 17, 2014 at 5:10 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 17, 2014, at 11:59 AM, Phillip Hallam-Baker i...@hallambaker.com wrote: Won't we need to move to the dpr...@ietf.org list to start the WG discussion? No, the announcement of the WG being formed said that this list is the WG's list. Yup, as does the datatracker / charter page. However, many people automatically assume that the list for a wg is wg_n...@ietf.org. I don't really want to do this, but Phillip does make a good point... What would y'all like to do? A: keep the list name as dns-privacy@ B: request that the list be migrated / renamed / whatever to dprive@ I was hoping that we could charter, figure out what we are doing, document that and shut down fast enough that it wouldn't matter, but... W --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNScurve limits (Was: Agenda time.
On Mon, Oct 13, 2014 at 12:17 PM, Paul Wouters p...@nohats.ca wrote: On Mon, 13 Oct 2014, Phillip Hallam-Baker wrote: I think we can maybe clarify the charter a little here. Protecting the integrity of the messages between the stub and the resolver should be a requirement for any spec. Yes. But authenticity of the authoritative zone data is a completely separate problem. For that purpose we want to be able to do offline signing. This is completely out of scope. We have DNSSEC for that. Which is why it would be appropriate for the charter to exclude it. I want the charter definition to be precise and put out of scope only what DNSSEC actually does rather than 'authentication' in general which it does not. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Why authentication and encryption are essential
On Sun, Sep 7, 2014 at 11:00 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Sun, Sep 07, 2014 at 08:34:33AM -0400, Phillip Hallam-Baker wrote: Seems that they are intercepting ALL external DNS and sending their own responses when they see an NXDOMAIN. Yes, some networks do that. What makes you think that privacy will help? Why isn't it more likely that Verizon will just intercept anything on port 53 and break it anyway? Unless we tunnel everything on the Internet in a single port (443?) and thereby foil all analysis by operators, both legitimate and otherwise, I don't see that there's any way to defend against Verizon's activities. It seems to me that there are possible downsides to that, too. Lets face it, port 53 is hopelessly compromised. I don't want to run everything over port 443 either. But I am happy with a scheme where I use a randomly assigned UDP port with fallback to port 443 if the network attempts to block. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Overview of DNS privacy and encryption proposals
On Fri, May 23, 2014 at 9:31 AM, W.C.A. Wijngaards wou...@nlnetlabs.nl wrote: Thanks for doing this. hallambaker-dnse: kerberos-like scheme with tickets and keys. Just to be clear, my DNSE paper is a requirements document that addresses the space, it is not a proposal. Private-DNS is the proposal. http://tools.ietf.org/html/draft-hallambaker-dnse-01 http://tools.ietf.org/html/draft-hallambaker-privatedns-00 With respect to the questions, at this stage I am focusing on the approach. To make this into a full scheme we would obviously need to drill down into details etc. UDP? TCP? trustanchors? signalled by? performance: ? UDP: Yes, this is supported using the UYFM framing. Each request has to fit into one packet but responses can have up to 16 packets. TCP: Yes, a JSON web service is supported for cases where UDP cannot get through. SXS-Connect also works over the UDP transport in theory but I have never tried it. But the ticket provision is a one time operation, it probably does not matter. Performance: As fast or faster than traditional DNS with lower load on servers. Yes, Private DNS is faster than the traditional DNS protocol because instead of making separate A and record requests, these are combined in one round trip. So the resolver is only handling one request not two. The application performance can be improved even more because it is now practical to perform SRV and ESRV requests as well. My standard query set is A, , SRV, ESRV, if the server signals that it accepts geo-data I will send that as well. This information allows the server to route my application straight to the best service to deliver the content. Asking the right query is no longer more expensive than asking the simplest one. There is no latency penalty. Servers are completely stateless. The ticket contains the encrypted session key. trustanchors: Short answer: whatever you like. Long answer, you do have to make choices to get the security controls you want. There are no external trustanchors required in the Private-DNS protocol, the client binds to the service using the SXS-Connect protocol once and then continues for years or decades. But SXS-Connect has options. Which options to use depends on whether we are talking about the client-resolver interaction or the resolver-authoritative For resolver-authoritative the obvious approach would be to bind to a trust anchor in the DNS itself by publishing a cert. For the client-resolver, the questions are much more involved as the resolver is a trusted service. It is possible to use SXS-Connect without any trust anchors at all using the PIN distribution mechanism. That would be the approach to use in an enterprise deployment. In a consumer environment the simplest approach is to simply leverage TLS for authentication. Right now I am also leveraging TLS for the confidentiality of the key exchange but I plan to change that very soon by adding in an extra DH layer into the kerberos-like key setup. So in the consumer environment we only rely on the WebPKI trustanchors for the one time setup and after that only rely on them for the integrity of the exchange (i.e. an attack would have to be active). Once the DH exchange is implemented it is arguably acceptable to use Private-DNS in a 'secure after first contact' mode. It is possible to do everything in DNS space but most of us would want our DNS service to be backed by a stronger demonstration of accountability than the provider obtained a DNS name. I do have a proposal that would mean that a user would only need to use the TLS scheme once for their first device after which they would 'connect' new devices using a separate protocol. But that is not really designed for Private-DNS alone, it is designed to allow the user to bind their device to all their services. So the idea would be I buy a new iPad and when I turn it on I say 'configure this to account settings from ph...@hallambaker.com' and then I get a confirmation request on my phone that asks me if I really want to. If I say yes then the new iPad gets my whole crypto credentials set: * My set of PGP/SMIME decryption private keys * My Private DNS connection * Generates and registers a signature key for confirmation service * Generates and registers a signature key for signing mail These are also configured for ongoing management. Which is essential for the mail decryption keys as they currently change once a month. Now I fully accept that not everyone is going to want to enter the full world of PHB security. Which is why I have divided up my proposal into small, manageable bit sized pieces. This is the confirmation portion: https://datatracker.ietf.org/doc/draft-hallambaker-sxs-confirm/ You don't have to do this bit to do Private-DNS but if you are also looking for a second factor protocol as well as DNS privacy then why wouldn't you want the two protocols to use a consistent approach to syntax, bindings etc.? signalled by? For the
Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
On Fri, Apr 25, 2014 at 10:46 AM, Ralf Weber d...@fl1ger.de wrote: Moin! On 25 Apr 2014, at 16:22, Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote: Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ? Wat? Because it is defined in the RFC. RFC1035 may not been totally clear on that. IMHO the language is strong enough, but if not there is RFC5966: All general-purpose DNS implementations MUST support both UDP and TCP transport. Any more questions?! Also all this new DNS stuff like DNSSEC and mitigating DNS amplification attack with RRL or similar techniques require that the TCP transport works. So long Yes and RFC quite definitely says that I get a pony. The existing DNS works as far as the people running their firewalls are concerned. The failure of TCP fallback in practice has been an understood problem for 20+ years. If people want to design a protocol that is going to be usable, they are going to end up having to accept some constraints that are not in the specs. -- Website: http://hallambaker.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
On Thu, Apr 24, 2014 at 11:19 AM, Joe Abley jab...@hopcount.ca wrote: On 24 Apr 2014, at 10:53, Phillip Hallam-Baker hal...@gmail.com wrote: If you want to use TLS with DNS then use port 443. One of the effects of firewalls is that we now only have three ports for all protocols: Port 80/UDP: Non SSL traffic Port 443/TCP: SSL traffic Port 53/UDP: DNS I think it's important to frame the problem space. I suspect that the firewall challenges you cite most often apply to communications between stub resolvers and recursive resolvers, for hosts that are using an off-net resolver (directly, or via a proxy). I also suspect that any ISP who has ever decided to install firewalls or other packet-mangling middleware in front of their resolver service (and is still in business) has by now collected many reasons not to do that, and that the network path between ISP resolver and authority servers is very likely to be clean. For ISP, read campus, enterprise, etc as appropriate. My interest at the start was censorship prevention so my interest is almost exclusively client-resolver. It does look like a totally different protocol to resolver-authoritative though. Since what we are concerned with here is (also) privacy, I agree that the resolver-authoritative loop is also in play. But that is a vastly lower priority than the client-resolver loop. If you don't solve that, you don't have any solution. The two problems are completely separate from a trust point of view. For key management in the Resolver-Authoritative loop you almost certainly want to use DNSSEC. But in the client-resolver loop you might well want to use WebPKI because you would want accountability. I have no science to back up my suspicions, here. Given that others apparently have different suspicions, equally plausible, perhaps science is needed. However, I'll note that the conversations surrounding the problem statement in London all seemed to support separating these two uses of the protocol. I don't think it's worth butchering the protocol if it turns out that we have an easy and clean solution that works for a significant part of the problem space (resolvers talking to authority servers), which is what t-dns/draft-hzhwm-start-tls-for-dns looks like to me. You know when people use loaded terms like 'butchering the protocol' to mean 'do it a different way to me' I start to get a little cross. For me the idea of putting TLS traffic over the same port as non TLS traffic without careful attention to how the upgrade is achieved would be 'butchering the protocol'. Changing the port number to one that is known to work is a cleaner approach. -- Website: http://hallambaker.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
