Re: [dns-privacy] DNS over DTLS (DNSoD)
On Apr 24, 2014, at 8:39 AM, Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote: No, the draft states that the DNS server will send no response. Please refer to section 5 of the draft http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls-00#section-5 snip After performing the above steps, the host should determine if the DNS server supports DNSoD by sending a DTLS ClientHello message. A DNS server that does not support DNSoD will not respond to ClientHello messages sent by the client, because they are not valid DNS requests (specifically, the DNS Opcode is invalid). /snip Sorry, you are right, and I had misread that. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt
Greetings. I created a new proposal on a simple way to do DNS over TLS between stubs and resolvers. Comments are appreciated. --Paul Hoffman A new version of I-D, draft-hoffman-dns-tls-stub-00.txt has been successfully submitted by Paul Hoffman and posted to the IETF repository. Name: draft-hoffman-dns-tls-stub Revision: 00 Title:Using TLS for Privacy Between DNS Stub and Recursive Resolvers Document date:2014-08-18 Group:Individual Submission Pages:6 URL: http://www.ietf.org/internet-drafts/draft-hoffman-dns-tls-stub-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dns-tls-stub/ Htmlized: http://tools.ietf.org/html/draft-hoffman-dns-tls-stub-00 Abstract: DNS queries and responses can contain information that reveals important information about the person who caused the queries, and it would be better if eavesdroppers were unable to see DNS traffic. This document describes how to use TLS for encrypting DNS traffic between a system acting as a DNS stub resolver and a system acting as a DNS recursive resolver. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt
[[ Combined PaulW's and Jacob's responses ]] On Aug 19, 2014, at 2:01 PM, Paul Wouters p...@nohats.ca wrote: On Tue, 19 Aug 2014, Paul Hoffman wrote: I wonder this 'MUST' may be too strong (or I don't fully understand the sense of this MUST). Since the upstream recursive resolver may or may not support the TLS extension, the DNS forwarder may end up giving up the resolution altogether. But depending on the stub clients' policy it may be still better to provide encryption between the stub and the forwarder. Good catch. Proposed replacement to handle the case where the recursive resolver doesn't do TLS: A stub resolver cannot tell whether it is sending queries to a recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder that acts as a TLS server for DNS requests MUST also attempt to act as a TLS client for queries to its upstream recursive resolvers, but MAY use the normal DNS protocol on port 53 if an upstream recursive resolver does set up a TLS session. A resolver at a coffee shop is mostly concerned about protecting the DNS in the public wifi, and might not worry at all about its DSL uplink, especially when it has no real reason to trust its own uplink. So I would just make it very generic: a DNS forwarder that acts as a TLS server for DNS requests SHOULD attempt to use TLS with its upstream resolver(s) to maximize the anonymity of its stub clients. I'm fine with that as a replacement for my suggestion above. Sure, let's be explicit. Proposed addition to the policy section: If a recursive resolver does not respond on port 443 or set up a TLS session, the stub resolver MAY use the normal DNS protocol on port 53. MAY sounds a little odd here. If there is no preconfiguration for authenticating this resolver, I don't think we should advise stubs to refuse to do DNS completely, which is what the MAY is suggesting as a valid option. (this is breaking the opportunistic security design pattern recommendation advise :) How about: If a recursive resolver for which an authentication method is available does not respond on port 443 or fails to set up a TLS session, the stub resolver SHOULD NOT use that resolver over unencrypted DNS using port 53. If no authentication method is available for the recusive resolver, the stub resolver SHOULD fallback to using cleartext DNS on port 53. That seems mixed up. I think the policies we want to list are: a) Must have authenticated TLS, otherwise don't get any DNS responses b) Try to do authenticated TLS, but use unauthenticated TLS if possible, otherwise don't get any DNS responses c) Try to do authenticated TLS, but use unauthenticated TLS if possible, but allow cleartext on port 53 if TLS cannot be established Does this seem like the whole list? On Aug 19, 2014, at 1:02 PM, Jacob Appelbaum ja...@appelbaum.net wrote: I'm not a fan of making it possible for an attacker to downgrade with a single (non-cryptographically protected) TCP RST packet. If I configure a resolver and declare it to be secure (and use it as such), why not fail closed? Because then hosts that use stub resolvers will not be able to use the DNS at all. That is correct and that is exactly what I expect when my network is attacking me. Rather than leaking that I'm being visited an ad name that implies I've visited a gay dating site, I want it to fail closed. If I declare it as secure, I want it to remain secure - where the security here is all about *confidentiality* and DNSSEC does the rest with regard to integrity, etc. I think that would policy (a) listed above. Does that work for you? Why not detect that as an attack or as outright network censorship? We could add such detection, but only if the value outweighs the complexity and possible failure modes. If the TLS connection fails to complete (authenicated or not), it should be as simple as returning something like E_CENSORSHIP_DETECTED. It is reasonable for the policy to suggest that a later API might be able to detect which level of protection, if any, the user has gotten. An error like Unable to connect securely to resolver, please contact your ISP would be fine. And you might want to only use applications that use that later API. Most OSes don't do anything remotely helpful when DNS fails. It might be nice if that failure mode was privacy preserving... It might be, yes. This seems to fail if there is an active attacker that blocks TLS traffic - is there a way for the resolver to somehow learn in-band on port 53 that this attack is happening? Probably, but you still haven't said what value there is in knowing that. A stub resolver has no log and no way of alerting anyone that it discovered something important. If my resolver allows upgrading to a secure method of communication, I'd like to know. Furthermore, I'd like to automatically upgrade to that secure communications path
[dns-privacy] Authenticating the resolver
On Aug 27, 2014, at 12:46 PM, Wes Hardaker wjh...@hardakers.net wrote: But what's the solution? How do we authenticate that resolver? PKIX won't help us, as there is no name. Say what? That draft clearly says that the resolver can have a PKIX certificate with its IP address as the name. DNSSEC won't help us, as half the time you're behind a nat so the reverse tree can't be used [ipv6 actually might help here]. Right, but irrelevant, since the stub is assumed not to be a validating stub because so few are. Leap of faith is probably better than nothing if you frequent that coffee shop. I don't think secure dhcp has gotten that far, but I'm admittedly out of touch. Secure DHCP is just moving the egg around. The likelihood that you have the coffee shop's DHCP server's credentials are zero. You also forgot other options, such as preshared signing key. That would work fine for enterprises or ISPs with a help desk and a few thousand users. Paste this into that dialog on your computer works OK. But PKIX with IP addresses is probably more scalable. We simply keep moving this chicken/egg problem of secure bootstrapping from one protocol to the next. It's like one egg that keeps changing chickens. Please look at the draft again; I don't think it is as bad as you are saying. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] WG Review: DNS PRIVate Exchange (dprive)
On Oct 10, 2014, at 2:02 PM, Mankin, Allison aman...@verisign.com wrote: After a little bit of online discussion with the chairs-to-be and the AD, I’m following my earlier email up with a couple of small suggested edits to the charter. EXISTING: Milestones: Dec 2014 - WG LC on an problem statement document Mar 2015 - WG selects one or more primary protocol directions Jul 2015 - WG LC on primary protocol directions SUGGESTED: Milestones: Dec 2014 - WG LC on an problem statement document Mar 2015 - WG selects primary protocol directions May 2015 - WG LC on privacy evaluation document Jul 2015 - WG LC on primary protocol directions The suggested privacy evaluation draft would describe methods for assessing the results of the DNS private exchange mechanisms. Is the application of one or several mechanisms an effective choice for mitigating against pervasive monitoring in particular operational configurations or use cases? I argue that this is important to help with the two cases I posed in my first message, where a channel encryption mechanism could be applied between End-system and Iterator but not mitigate at all. Additional suggested wording about privacy evaluation for the charter body, addition of one sentence: EXISTING: The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. Some of the results of this working group may be experimental. SUGGESTED: [Add to the end of the above paragraph] The Working Group will also develop a privacy evaluation document to provide methods for assessing how well the goal of mitigating against pervasive monitor is met, and to provide example assessments for common use cases. This sounds like a good addition. We already have at least three proposals that look similar but have slightly different privacy properties. Having a document that catalogs these (which is different than what is in the problem statement) would be useful for both the WG and the larger community. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DPRIVE is officially a WG.
On Oct 18, 2014, at 8: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. And, when they are wrong, their mail bounces in an obvious fashion. I don't really want to do this, but Phillip does make a good point... No, he doesn't. Ten years ago, that was common; today, a large percentage of WGs that started as BoFs have the mailing list name different from the WG name. 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@ Please do A. B makes things harder for everyone, particularly those who want to see the discussion to date. Other WGs in the same situation as us have done *just fine*, and this seems like senseless process that will hinder our work. --Paul Hoffman ___ 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 Oct 21, 2014, at 2:18 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Mon, Oct 20, 2014 at 07:02:01AM -0700, Paul Hoffman paul.hoff...@vpnc.org wrote a message of 23 lines which said: And, after many attempts by people here, it is still undocumented. The is a bit of a protocol description, but it is fairly incomprehensible, I did not say it was documented, just that it was deployed. Without documentation, we have no proof of that. When I look at the supposed documentation for the supposed port, I see something that is not a port of DNSCurve at all, just something that uses the same encryption algorithm. This is important because DNSCurve is not just an encryption algorithm, it is also a key exchange mechanism, and its proof of security relies on both parts. --Paul Hoffman ___ 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 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. --Paul Hoffman ___ 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 Oct 27, 2014, at 1:03 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com wrote: I guess you have heard about CGA-TSIG. What do you think about the approach explained there? Is still has many confusing dependencies that make it hard to understand, and it vastly oversells the IPv4 capabilities. What do you think? It is a distraction for this WG and should not be considered. --Paul Hoffman ___ 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 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. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [dprive-problem-statement] Clearly marking privacy considerations?
On Nov 2, 2014, at 12:57 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: A reviewer told me privately that it is not clear, from draft-ietf-dprive-problem-statement-00.txt, what are the actual considerations/issues/problems. They are mentioned but not highlighted enough, he said. I did not have the problem that that reviewer did, but WGs in the past have had problems with the problem statement document indicates X vs. it doesn't say that. He suggested to add prominent CONSIDERATIONS from time to time, for instance when discussing source IP addresses, having: CONSIDERATION NNN: exposing source IP addresses of DNS queries raises privacy risks Advice? My preference is not to have three categories, but just one: problems. Problems are issues, and problems have considerations, but what the WG needs is a list of problems that it needs to try to solve. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Verisign patent disclosure
I moved the discussion to the dnsop mailing list because it is that WG, not this one, which is discussing the draft-ietf-dnsop-qname-minimisation draft. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS and framing
On Nov 12, 2014, at 9:03 PM, Francis Dupont francis.dup...@fdupont.fr wrote: Does DNS over TLS use the TLS framing (aka TLS Record Protocol) or does it prefix messages by a two byte length field as for DNS over TCP (cf RFC 1035 4.2.2 TCP usage)? I believe it is the second but *no* DNS over TLS proposal specify this point. This is a good question, one that I realized needed to be answered after I turned in the -00 drafts. I came to the same conclusion, and will add the following wording to the three drafts: The DNS message format uses the TCP version of the format, namely with the two-octet length at the beginning of each message, as described in Section 4.2.2 of RFC 1035. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS
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. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Moving things along...
On Feb 18, 2015, at 11:56 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Feb 18, 2015 at 02:48:25PM -0500, Warren Kumari war...@kumari.net wrote a message of 48 lines which said: We now have 2 primary document sets under consideration: What is your assessment of draft-hoffman-dprive-dns-tls-* Ah, sorry, I should have said so in public. I'm dropping the draft-hoffman-* ideas because one (new port) is now part of hzhwm-dprive-start-tls-for-dns. If others really think that the ALPN or HTTP-wrapping are a good idea, I'm happy to have them move those forwards, but personally, I think both are less likely to succeed than hzhwm-dprive-start-tls-for-dns. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Review of dprive-problem-statement-01
On Feb 19, 2015, at 12:04 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Now published but only in french. Interesting Internet governance issue :-) Can I add a reference to a document in non-english? Yes. And you should. (And I say this as someone who is unable to read French.) There is precedent for it: RFC 4357 has normative references to documents only in Russian. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A depraved test
On Jan 12, 2015, at 7:31 PM, Warren Kumari war...@kumari.net wrote: Please report back the results if you do test. I think having some data on how well things like TLS will traverse CPE on port 53 will be useful / interesting... If that's what you want, then you need to run TLS on that port, not HTTP. You apparently aren't doing that, so people getting negative results will think that they are being blocked when in fact you set the test up incorrectly. It is great that people want to do tests. Can we maybe agree to the test methodology before people start saying this shows that doesn't work? --Paul Hoffman ___ 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 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
Re: [dns-privacy] Moving things along...
On Feb 25, 2015, at 4:11 PM, Warren Kumari war...@kumari.net wrote: Are you interested on working on CGA-TSIGe and would you like to devote some (10 minutes) of the meeting time in Dallas to a presentation / discussion on CGA-TSIGe? No. ___ 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.
On Apr 19, 2015, at 5:19 AM, Ralf Weber d...@fl1ger.de wrote: On Fri, Apr 17, 2015 at 03:48:59PM -0700, manning wrote: exercising line item veto… I think #3 is ready to proceed. The other two suggest fundamental changes to the DNS which need more thought. I disagree. Switching DNS from 0.001% of queries over TCP to 100% is IMHO a far greater change to DNS then the other proposals. I think we don't know enough yet to adavance just one proposal. Just to clarify: draft-hzhwm-dprive-start-tls-for-dns does not propose to switch 100% of DNS to TCP. It only proposes switching the traffic between stubs and recursives that agree to the new TCP-based protocol. If a recursive doesn't want to do TLS, it simply doesn't advertise that it is willing to do so, in the same way that in the other proposals, if the recursive doesn't want to encrypt, it simply doesn't advertise that. --Paul Hoffman ___ 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 Apr 27, 2015, at 12: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 sure about the way to carry enough state in each request. 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. 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. --Paul Hoffman ___ 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 Apr 30, 2015, at 9:21 PM, Watson Ladd watsonbl...@gmail.com wrote: If the anycast changes then you are going to have to timeout and resume. This is also true for HTTP. I still don't see why DNS needs more routing stability than HTTP. DNS doesn't. But proposals like DNS over TLS rely on extremely long lived connections. I'm still confused about this. Why does the connection need to be extremely long lived for stub-to-resolver? From everything that I have heard in TLS over the years, if you have to tear down and re-establish the connection, it goes quite quickly. Is there research that shows differently? --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] How many mechanisms in draft-ietf-dprive-start-tls-for-dns?
On May 13, 2015, at 3:52 AM, Simon Josefsson si...@josefsson.org wrote: Paul Hoffman paul.hoff...@vpnc.org writes: Having two parallel mechanisms for a latency-sensitive protocol leads to the necessity of doing a happy eyeballs approach in implementation to decrease latency. That's only true of the specifications don't say what to do first. However, draft-ietf-dprive-start-tls-for-dns *does* say what to do first, so there is no happy-eyeballs issue. Are you referring to the following text? DNS clients first try port-based DNS-over-TLS. If that connection fails, they try upgrade-based DNS-over-TLS. Yes. That approach is what dual-stack IPv4+IPv6 applications did before people realized defining fails is non-trivial and came up with the happy eyeballs approach to let the quickest path win, and not bother waiting for the fail to be determined. And if we later change to that type of wishy-washy operations, you will be correct at that time. We are not there yet, and I will fight strongly against getting there. If we need more definition of fails, I'm happy to work on that. Determining success and failure here is completely different than for dual-address applications. There is quite some complexity in getting that right. Compare RFC 6555 for that approach on a IPv4+IPv6 level. DNS is relatively latency sensitive, unlike IMAP/SMTP/XMPP. draft-ietf-dprive-start-tls-for-dns is not about all of DNS: it is about the stub-to-resolver link. The latency you discuss is a one-time issue, because you rarely change your resolver unless your network link changes. Good point. If indeed latency is not an issue, what's wrong with only defining upgrade-based DNS-over-TLS? Because we know for a fact that some firewalls inspect traffic on TCP port 53, and that they block traffic that they don't understand. They will not understand STARTTLS. A better question is what's wrong with only defining new-port-based DNS-over-TLS. My personal expectation is that there are far more firewalls that do stupid things with trying to understand port 53 traffic than those that block all unknown ports, but we do know that *some* firewalls are configured to block all unknown ports. That is, if the WG wanted to only pick one, I would bet we would end up with more successful encryption with new port than with STARTTLS. However, I still disagree that try A, and try B if failure is reasonable here, certainly more reasonable in the IPv4or6 case. What I'm basically wondering, and advocating, is if perhaps one method would be sufficient. This would reduce complexity on the protocol and implementation level. It would indeed reduce complexity, but at the risk of having more unencrypted DNS traffic. True, but the document needs to find a balance. We did. :-) That is, your preferred balance point seems to be different than the one we picked, and thus there is now a WG discussion of balance points. With the same line of argumentation, you could suggest that the document should include a third mechanism DNS-over-HTTPS because it is common for middle-boxes to interfer with both DNS traffic and special-port TLS traffic, and HTTPS often works. Correct, it could. And we chose against that balance point. I don't believe that is a good path to follow. Good, we're in agreement there. It leads to an explosion of mechanisms. Therefor I disagree that the risk of having unencrypted DNS traffic trumf the complexities in having multiple mechanisms. And we do. None of us can prove anything, of course, but we can discuss our opinions. so I suppose that would be the choice of least resistance. The only reason against that in your document is a vague maybe interact poorly with middle boxes that inspect DNS traffic -- and I would like to challenge that this is sufficient motivation to introduce the complexity of having both port-based and upgrade-based DNS-over-TLS. Certainly middle boxes that inspect traffic may interact poorly with port-based DNS-over-TLS as well. Such boxes may do anything, but we have seen no evidence that boxes that watch unassigned ports act differently if TLS is negotiated on those ports. On the contrary: I would say that tampering with non-common ports is frequent. There are many public/hotel wifi networks that only allow port 53, 80, 143 and 443 for example. That's not tampering, that's blocking, and I agree that happens sometimes, but much more rarely now than five years ago, at least from the anecdotal evidence (that is, insufficient research) that I hear from firewall vendors. If you try to do IMAP-over-TLS or SSH you notice this, they would be completely blocked. I POP-over-TLS and SSH whenever I travel, and I am rarely blocked, whereas ten years ago it was common. Firewall vendors I have spoken to say that they stopped recommending 53/80/443 setups long ago. They still exist, of course, and always will; that's why we
Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt
On May 12, 2015, at 11:40 AM, Simon Josefsson si...@josefsson.org wrote: This document define essentially two mechanisms: port-based DNS-over-TLS AND upgrade-based DNS-over-TLS. I may have missed earlier discussions about this design choice. However I want to understand why you want/need this complexity, to make sure there really was a good motivation behind that choice. Great. For SMTP, IMAP, POP etc the reason for having both port-based and upgrade-based is legacy and historic reasons: back in the days the STARTTLS approach wasn't invented, so following HTTP(S) footsteps, new ports were allocated for secure protocol variants. Modern protocols does not have this issue; compare XMPP. That's not accurate for SMTP: during discussion of RFC 2487, there was no alternate port for SMTP-over-TLS. It's also not accurate for IMAP and POP: both of those got STARTTLS-like extensions because that's how SMTP works. Having two parallel mechanisms for a latency-sensitive protocol leads to the necessity of doing a happy eyeballs approach in implementation to decrease latency. That's only true of the specifications don't say what to do first. However, draft-ietf-dprive-start-tls-for-dns *does* say what to do first, so there is no happy-eyeballs issue. There is quite some complexity in getting that right. Compare RFC 6555 for that approach on a IPv4+IPv6 level. DNS is relatively latency sensitive, unlike IMAP/SMTP/XMPP. draft-ietf-dprive-start-tls-for-dns is not about all of DNS: it is about the stub-to-resolver link. The latency you discuss is a one-time issue, because you rarely change your resolver unless your network link changes. What I'm basically wondering, and advocating, is if perhaps one method would be sufficient. This would reduce complexity on the protocol and implementation level. It would indeed reduce complexity, but at the risk of having more unencrypted DNS traffic. The preference in IETF has been for the inband STARTTLS approach, ...except for the most popular use case, HTTP... :-) so I suppose that would be the choice of least resistance. The only reason against that in your document is a vague maybe interact poorly with middle boxes that inspect DNS traffic -- and I would like to challenge that this is sufficient motivation to introduce the complexity of having both port-based and upgrade-based DNS-over-TLS. Certainly middle boxes that inspect traffic may interact poorly with port-based DNS-over-TLS as well. Such boxes may do anything, but we have seen no evidence that boxes that watch unassigned ports act differently if TLS is negotiated on those ports. I would go further and say that middle boxes that interfer with DNS traffic should be considered part of the problem, not part of the solution. Fully agree, and the draft says nothing about them being part of the solution. --Paul Hoffman signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] privacy respect... ICANN!!
On Jun 27, 2015, at 6:21 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: But it is completely unrelated to this working group: whatever ICANN decides on this matter, the DNS will leak information (and we are here to limit this leak: let me remind you that qname minimisation is currently in Working Group Last Call in dnsop). +1. If you want to have a constructive discussion about this topic that has some chance of changing the outcome, you should probably do it in ICANN, not in an unrelated WG in the IETF. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call For Adoption: draft-wing-dprive-dnsodtls
On May 25, 2015, at 6:54 PM, Guangqing Deng dengguangq...@cnnic.cn wrote: Resolution latency is very crucial for DNS system and the latency of DNS-over-DTLS is relatively low compared with DNS-over-TLS. Is the latency for an established TLS connection any worse than for a DTLS connection? It would be good to see numbers if this is the case. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
On 10/23/15, 1:35 PM, "Simon Josefsson" <si...@josefsson.org> wrote: >Hi. I believe the document is in relatively good shape. I have one >high level concern, and one concern with the document itself that is >related to the higher-level concern: > >1) I believe it would be a mistake to publish this without synchronizing >the TLS-related aspects of DNS-over-TLS and DNS-over-DTLS. The >documents solve roughly the same problem, with rougly the same >technology. One important difference is how they approach >authentication of the peer in TLS. Given the similarities of the >protocols and solutions, this seems like a recipe for implementation >frustration. An implementer would prefer to implement DNS-over-TLS/DTLS >as similar as possible. Having different X.509 (etc) certificate >verification code paths depending on whether TLS or DTLS is used appears >bad to me. > >2) On TLS verification, this document should reference RFC 6125 and >describe how naming information should be compared with the locally >known data with what is being presented by the server. See >draft-ietf-dprive-dnsodtls for one way (not necessarily the best one or >the most readable or complete way) of doing this. > >If merging DNS-over-TLS and DNS-over-DTLS is not an option, another >possibility is that TLS-related aspects are deferred from both documents >to another third new document that describe how to perform TLS >credential verification for DNS-over-(D)TLS in a generalized way. Then >there would be harmony in the TLS-related aspects, and the respective >document can focus on the DNS-related aspects. If document editor >cycles is limiting factor, I would volunteer to help write this. Fully agree on all counts. If the WG wants to move both -TLS and -DTLS to the IETF, it makes no sense at all to have them have different crypto properties. I don't care if the answer is "harmonize each before finishing" or "harmonize them by reference to a third document". --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
On 13 Nov 2015, at 3:31, Tim Wicinski wrote: The WGLC has finished, and it appears to be rough consensus on moving forward. I want to touch base with my co-chair and AD on one issue, but I will work on the Shepherd write up over the next few days and submit it into the pipeline. I plan on mentioning the issues raised about waiting for other documents before moving forward in my shepherd notes. Just to be clear: do the chairs read the rough consensus to be that the draft needs to remove Sections 3.2 and all of Section 4, and move them to a new document? --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
Whoops, Sara is right and I was wrong. What the WG agreed to was in the slides in Yokohama: = Explicitly state that an upcoming document will define further authentication profiles Draft in development, will be submitted ASAP This draft will document Opportunistic and briefly cite the risk-benefit for it This draft will provide a brief sketch of authentication in the case where there is a two-way active relationship between the client and the server (e.g. enterprise) = Unlike what I said a bit ago, we obviously can't pull out the current security requirements and point to a future document: that will never fly with the IESG (and nor should it). --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Please review documents...
On 30 Sep 2015, at 11:53, Ted Hardie wrote: Howdy, A quick question about draft-ietf-dprive-dns-over-tls-0: Some previous drafts used ALPN (RFC 7301) tokens to negotiate the use of DNS as an application layer protocol user of TLS. This draft seems to assume that because it is using a well-known port, it does not need to specify an ALPN token to indicate that the protocol being negotiated is DNS. It strike me as utterly harmless to include such a token and possibly beneficial (since you might eventually use different tokens for EDNS level, for example). Is there a strong objection to using both that I'm missing? Your proposal would restrict initial deployment to clients and servers whose TLS stack has ALPN. Instead of doing this, we could gate the next version on ALPN instead, causing more early deployment. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] RE I-D Action: draft-ietf-dprive-dnsodtls-08.txt
(Glad to see the interaction between Sara and Tiru; responding on just one point.) On 8 Aug 2016, at 5:21, Sara Dickinson wrote: With regard to the separate https://tools.ietf.org/html/draft-wing-dprive- profile-and-msg-flows-01 I’ll re-iterate my question from the Yokohama WG: Is there anything DNS specific in the draft? I don’t recall anything particularly DNS specific. I definitely see value in a draft comparing message flows between TLS and DTLS in general, but my feeling is it might be better progressed though another working group with more (D)TLS experts - TLS or UTA ? I don't think other WG will care enough for this draft, maybe the chairs can request reviewers from the above WG’s. I’d be interested to know what others think about this. I disagree with Tiru: I think other WGs *will* care about it. It could go in the TLS WG, but I suspect it will get moldy there waiting for TLS 1.3 to finish. I think SAAG could take this on, or maybe spin up a short, narrow WG for it. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Review of draft-ietf-dprive-dtls-and-tls-profiles-03
This document seems ready for WG Last Call. The comments I have hear can be dealt with before or during WG Last Call. --Paul Hoffman = The following text from section 4.2 still seems wrong: Since Strict Privacy provides the strongest privacy guarantees it is preferable to Opportunistic Privacy. Strict Privacy is only preferable to users who would rather have an unusable Internet connection: an Internet connection where every DNS lookup in every application fails. Currently, that size of that set of users is incredibly small, although it might grow over time. The sentence above could lead developers to implement Strict Privacy without also implementing Opportunistic Privacy to the detriment of the vast majority of current Internet users. Proposed replacement: Strict Privacy provides the strongest privacy guarantees and therefore should always be implemented along with Opportunistic Privacy. The negative implications of the two types of privacy are so radically different (a possibly-unusable Internet service for Strict Privacy; complete control of DNS responses for Opportunistic Privacy) that neither option can be considered a good default for all users. = I have a significant concern about the discussion of draft-ietf-dprive-dnsodtls, which is listed as an informational reference. That document seems to be stalled again, which is unfortunate. If, during IETF review, someone insists that the DTLS document is in fact a normative reference (which would make sense if that document were finished), draft-ietf-dprive-dtls-and-tls-profiles will be blocked from publication. Proposal: remove any mention of draft-ietf-dprive-dnsodtls from draft-ietf-dprive-dtls-and-tls-profiles. When (if?) draft-ietf-dprive-dnsodtls goes through WG Last Call, it can have a paragraph that says that the RFC that draft-ietf-dprive-dtls-and-tls-profiles has become applies to it. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] DNS over TLS for zone transfers?
On 17 Jan 2017, at 2:47, Mukund Sivaraman wrote: On Tue, Jan 17, 2017 at 06:22:29PM +0800, Shane Kerr wrote: Note also that it might be worthwhile building a new zone transfer protocol that can perform better in areas where AXFR and IXFR don't work well today (unnecessary data in IXFR of signed zones, inefficiency for synchronizing lots of zones, automatic fallback to full zone transfer on IXFR failure, and so on). That's not really something for DPRIVE, of course, but adding TLS to the protocol could be rolled into such an activity. On a side note, because any encryption will require a change to the DNS protocol (i.e., putting things into a crypto box which isn't backwards compatible) IMO it would be worthwhile to consider revisiting the DNS message format. Shane was talking about wrapping the DNS traffic in TLS. This does not "require a change to the DNS protocol", as we have already seen in this WG. --Paul Hoffman ___ 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-dtls-and-tls-profiles-08.txt
Thanks! This version fixes the problem I brought up in WG Last Call, and I like the new table as well. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.
Greetings. I have read the -10 draft, and think it is ready for moving to the IETF. The authors have done a good job of incorporating comments from the WG. Because draft-ietf-dprive-dnsodtls might be abandoned in favor of RFC 7858 after someone implements it and compares the two, it is appropriate that this is set to become an Experimental RFC. After testing, if implementers think that there is value to the DTLS version, it can be put on Standards Track. It will be interesting to see how that testing goes when it happens; I'm particularly interested in the tradeoff of "TCP state is kept in the kernel" vs. "session state is kept in the application stack" vs. DoS-by-CPU-exhaustion. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile
On 7 Oct 2016, at 2:48, Stephane Bortzmeyer wrote: The document seems to use "X.509" and "PKIX" as synonyms. Is it really the case? No. PKIX is an extension of X.509 (but almost no one uses unextended X.509 certs). Changing them all to PKIX is probably best. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] After the DNS-over-DTLS WGLC...
On 16 Aug 2016, at 10:08, Warren Kumari wrote: At the moment we are expecting to meet in Seoul, partly to discuss the Profiles document, but also as a “BoF style” discussion on the Phase 2 work. Thoughts? Views? etc. A BoFy kind of discussion about recursive-to-authoritative would be very useful. The privacy advantages are obvious, but the various types of costs are important too. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: configuration
On 26 Oct 2016, at 6:24, Sara Dickinson wrote:
On 23 Oct 2016, at 00:26, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
Greetings. Someone reading this document for the first time might not
understand where the DNS name that is being discussed in the main
body of the document was found. It is not until Section 8 ("Out of
Band Sources of Domain Name") that this is mentioned, and that feels
much too late.
The document might be much more approachable if Section 8 was moved
to immediately after Section 3, and if it was re-titled
"Configuration of the Domain Name for Verification
Hi Paul,
This is a good point. As suggested in my other email I propose
including a definition in the Terminology section of ‘authentication
domain name’. Here is what I suggest:
* Authentication domain name: A domain name that can be used to
authenticate a DNS Privacy enabling server. Sources of authentication
domain names are
discussed in Section * and Section *.
And then also moving sections 7 and 8 to immediately after section 4.
I suggest after section 4 rather than 3 because 4 is currently the
‘Discussion’. However I’m not averse to splitting the
Discussion section up as it is rather large now….
Good point. Maybe moving 7 and 8 to be after 4.1 would make sense ("here
is how you start, and here are what profiles are"). You could split
Section 4 up or make it longer; it doesn't really matter as long as you
don't go beyond three levels of heading there.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile
On 26 Oct 2016, at 6:23, Sara Dickinson wrote: Section 1: "The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter." This document will long outlive the WG, so everything after the first comma should be removed. So…. this got added after multiple comments of ‘why is recursive to auth not in scope?”. It is also lifted directly from RFC7858 (DNS-over-TLS) as it was the wording used to justify the scope at the time of publication of that document. But there have been several comments on this sentence and that is the response I have given every time :-) If the charter is changed before this document is published I agree this should be updated but I happen to think this gives useful context for future readers. But would like to hear what others think. Saying "The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers" should be sufficient to say "it's not like we didn't think about it". If people really want to have the charter discussion in this long-lived RFC, at least change the second clause to "but this application was out of scope for the Working Group charter at the time this document was finished". Section 1: "How a DNS client can verify that any given credential matches the domain name obtained for a DNS server." "obtained" is somewhat difficult here because there are many ways that the name is determined. Proposal: "matches the domain name of the DNS server”. We used the word ‘obtained' here as in the early discussions there was confusion about what domain name (or names) a DNS server serves, and what the domain name that is used for authentication is. We wanted to be clear there is no correlation between the two. Hence the rather clumsy wording that is at least consistent between the first and third bullet points. OLD: o How a DNS client can obtain a domain name for a DNS server to use for (D)TLS authentication. o What are the acceptable credentials a DNS server can present to prove its identity for (D)TLS authentication based on a given domain name. o How a DNS client can verify that any given credential matches the domain name obtained for a DNS server. NEW: o How a DNS client can obtain an ‘authentication domain name' for a DNS server to use for (D)TLS authentication. o What are the acceptable credentials a DNS server can present to prove its identity for (D)TLS authentication based on a given domain name. o How a DNS client can verify that any given credential matches the ‘authentication domain name' for a DNS server. In fact maybe it would be better to define ‘authentication domain name’ in the terminology an use it throughout? That would be good, yes. But "obtained" still sounds like it might come from the DNS itself, not from configuration or DHCP. Section 4.3.1: "Bootstrapping" is not a widely-understood term. Really? A quick Google finds RFC4173 from 2005 which has Bootstrapping in the title. "Pulling yourself up by your own bootstraps" is a difficult idiom for people even if English is their first language. It would be nice to keep it unless there are general objections as it more accurately describes the specific issue addressed in that section. In this specific case, it's more "chicken or egg" than "bootstrap" because you actually do first use the unsecured DNS. Maybe just "Startup" for the title and leave bootstrap in the body text (which does describe the problem quite well). --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy
On 27 Oct 2016, at 11:03, Bob Harold wrote: On Thu, Oct 27, 2016 at 12:43 PM, Sara Dickinson <s...@sinodun.com> wrote: So I’m not sure here. The aim here was to try to keep this section flexible in terms of the interpretation of OS but perhaps this needs discussion. It seems like it does need discussion. RFC 7435 says "An OS protocol first determines the capabilities of the peer with which it is attempting to communicate. Peer capabilities may be discovered by out-of-band or in-band means. (Out-of-band mechanisms include the use of DANE records….” and then allows for the hard failure if the capability isn’t as described. So this seems to leave the door open for clients to choose to hard-fail in certain circumstances which seem relevant to this document (I don’t see any caveats about this only happening if users know what is going on). It seems overkill to completely override that here with something like "Opportunistic clients MUST fallback to clear text…” unless there is consensus that that is how it should work for DNS in all cases? It seems that there are levels of Opportunistic Security (OS), either falling back to TLS to an un-authenticated server, or falling back to clear text (no TLS). We should make it clear that there are various levels, and that there should be some way to choose what minimum level is allowed. I will admit that I thought there was just one bottom level of OS in our discussion, cleartext. If there are two (cleartext; no communication), the document needs more discussion in multiple places because it would be surprising to any implementer who didn't follow the long discussion during the end stages of RFC 7435. Which users do we think would not want to negotiate weak TLS (such as DES-MD2) but would be willing to go to cleartext? For other than crypto experts (who are likely to only want Strict), how would weak TLS be worse than cleartext? It feels like this is adding a layer of operational complexity for an audience who probably doesn't exist. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy
On 28 Oct 2016, at 3:21, Sara Dickinson wrote: On 27 Oct 2016, at 19:28, Paul Hoffman <paul.hoff...@vpnc.org> wrote: I will admit that I thought there was just one bottom level of OS in our discussion, cleartext. If there are two (cleartext; no communication), the document needs more discussion in multiple places because it would be surprising to any implementer who didn't follow the long discussion during the end stages of RFC 7435. As the draft stands it is clear about what Strict is and allows for all flavours of OS, essentially leaving it as an implementation choice. If, because of the nature of DNS, the feeling is it makes more sense that Opportunistic _always_ falls back to clear text in order to get service then I can see the value in that. It is just a question of spelling this out clearly in the draft. Right. However, the draft currently says in a few places that you choose opportunistic if you want to be sure you get DNS service. So you either have to remove those, or remove the possibility that OS will not go to cleartext. Which users do we think would not want to negotiate weak TLS (such as DES-MD2) but would be willing to go to cleartext? For other than crypto experts (who are likely to only want Strict), how would weak TLS be worse than cleartext? There was some discussion in Buenos Aires (I think) about an intermediate ‘Relaxed’ mode where a client is willing to use a (weakly) encrypted connection but not willing to fallback to clear text so as to have some protection against passive monitoring. But IIRC the consensus was ‘keep it simple, Strict or Opportunistic’. I don't remember the conversation, but I really don't remember anyone advocating for "more complicated". Strict, Opportunistic-only-to-good-crypto, and Opportunistic-to-cleartext is more complicated than Strict and Opportunistic-to-cleartext. Users don't know how to set "good crypto". For me the other ‘intermediate’ case I was really thinking of in the hard-fail case for Opportunistic is when the client does have authentication information configured (as opposed to having none) but the authentication fails. That's Strict, yes? Should there be scope for the client to decide in that case that something is wrong enough it doesn't want to continue? As you say, maybe this is complicating the picture too much. We can make this as complicated as we want. My goal is to prevent people from turning it off when the Internet doesn't work and they find out it's because DNS-over-TLS was turned on. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy
On 28 Oct 2016, at 8:27, Bob Harold wrote: In Section 5 on Opportunistic Privacy, I am not sure "MAY" is correct. If the user chooses Opportunistic, I would think the server MUST try to be secure, in whatever ways are possible, but MAY fall back to less secure, only if those fail. In TLS, it's not the server that tries to be secure, it's the client. The server offers a bunch of stuff, but only once. The client picks, but only once. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: configuration
Greetings. Someone reading this document for the first time might not
understand where the DNS name that is being discussed in the main body
of the document was found. It is not until Section 8 ("Out of Band
Sources of Domain Name") that this is mentioned, and that feels much too
late.
The document might be much more approachable if Section 8 was moved to
immediately after Section 3, and if it was re-titled "Configuration of
the Domain Name for Verification".
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: SPKI pinning
Greetings. The draft can't make up its mind about SPKI pinning. In Section 3, it says that SPKI-pinset-based authentication "is out of scope", but then immediately admits that "Section 10 does describe how to combine that approach with the domain name based mechanism described here". However, the draft also talks about SPKI pinning in 4.2, 4.3.2, 5, 6, and then 10. Those sections suggest (sometimes indirectly) that you might want to check both DNS name and SPKI, but Section 10 then disavows specification of what to do if only one of the two identifier types match. This is a mess. Either the draft has to give consistent, followable guidance or defer to a different document. The latter seems much more likely to get consensus than the former. Proposal: In Section 3 about what is out of scope: o SPKI-pinset-based authentication. This is defined in [RFC7858], and that document gives an example of a profile that uses them. The use of SPKI-pinset-based authentication is not discussed in this document, but might be addressed in a future document. Then remove any mention of SPKI from the rest of the document (including the definition in Section 2). Also remove the bullet about raw public keys in Section 11, which seems completely out-of-place in a document about DNS name matching. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile
Greetings. I apologize for this being late, but I kinda wanted to see what topics other reviewers focused on. However, other than Stéphane's review, nothing has been said. There are some big topics for the document that I have split out into other messages. Some may be considered rehashing of earlier discussions, and I'm totally open to "nope, that's not what the WG wants", but I think it is worth making sure we all still feel that way. The rest of this message are nits. Section 1: "The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter." This document will long outlive the WG, so everything after the first comma should be removed. Section 1: "How a DNS client can verify that any given credential matches the domain name obtained for a DNS server." "obtained" is somewhat difficult here because there are many ways that the name is determined. Proposal: "matches the domain name of the DNS server". Section 1: "DNS-over-TLS draft" should be [RFC7858]. Section 2: "forwarder/proxy" (used twice) The rest of the sentence talks only about forwarder, and it's not clear how a proxy differs from a forward, so maybe just change these to "forwarder". Section 4: In Table 1, change "N (D)" to "ND". I cannot figure out what the parentheses mean, and all three N situations are ND. Section 4.3.1: "Bootstrapping" is not a widely-understood term. Proposal: replace it with "Configuration". Section 8.3: The "[NOTE:" is not really a note, it is a full statement. Proposal: remove "[NOTE:" and "]". Section 11: The first paragraph covers multiple topics; it could be broken after second sentence. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Draft minutes form IETF97
On 25 Nov 2016, at 11:38, Warren Kumari wrote: Hi all, I have uploaded draft minutes from the DPRIVE meeting in Seoul Please take a look and send any corrections / clarifications. https://www.ietf.org/proceedings/97/minutes/minutes-97-dprive-00 Thanks to Suzanne and Dan. The minutes for the Profiles discussion doesn't reflect the mic interactions on the open topics that Sara brought up. In specific, there seemed to be general agreement on leaving the fallback terminology alone, and on removing hard-fail from the options. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoption: draft-mayrhofer-dprive-padding-profile
I support the adoption of this document, knowing that there is still a bunch of research that needs to be done before we can specify good profiles. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile
On 27 Oct 2016, at 7:35, Sara Dickinson wrote: On 27 Oct 2016, at 15:06, Paul Hoffman <paul.hoff...@vpnc.org> wrote: On 27 Oct 2016, at 5:35, Sara Dickinson wrote: That would be good, yes. But "obtained" still sounds like it might come from the DNS itself, not from configuration or DHCP. Well it could come from DNS via a SRV lookup. How could it come from SRV? I am thinking (perhaps incorrectly) that it has to only come from configuration or DHCP. Ah, in the case where the client only has the name configured I’m thinking that there has to be a look up to know which server the domain name is valid for. So the name<-->IP mapping is what is ‘obtained’ from the DNS. How about: * How a DNS client can obtain the combination of authentication domain name and IP address for a DNS server. Yes, that's good. "Obtain" makes more sense there. Thanks! --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: SPKI pinning
On 27 Oct 2016, at 5:35, Sara Dickinson wrote: On 23 Oct 2016, at 00:25, Paul Hoffman <paul.hoff...@vpnc.org> wrote: Greetings. The draft can't make up its mind about SPKI pinning. In Section 3, it says that SPKI-pinset-based authentication "is out of scope", but then immediately admits that "Section 10 does describe how to combine that approach with the domain name based mechanism described here". However, the draft also talks about SPKI pinning in 4.2, 4.3.2, 5, 6, and then 10. Those sections suggest (sometimes indirectly) that you might want to check both DNS name and SPKI, but Section 10 then disavows specification of what to do if only one of the two identifier types match. This is a mess. Either the draft has to give consistent, followable guidance or defer to a different document. The latter seems much more likely to get consensus than the former. I agree that the current draft is muddied with these additional references but I think this is actually a relatively easy fix. The intension in the document was to treat as out of scope the details of _how_ to do SPKI authentication as they are described in RFC7858. What is (implicitly) in scope is how SPKI authentication can be used as an authentication mechanism within the general Usage profiles. So I would proposed clarification following lines: - Re-word the Scope along the above lines - Clarify that the Usage Profiles depend on the outcome of authentication (and encryption). - The authentication outcome is the result of one or more authentication mechanisms. Currently available mechanisms include SPKI authentication as described in RFC7858 and the domain name based authentication as described in this draft. - These mechanisms may be used independently or together. If used together all mechanisms must succeed for the authentication outcome to be successful. - tidy up the references you pick out based on this, for example, update references to ‘a valid domain name or SPKI pinset’ to ‘a valid authentication mechanism’ or similar I hope that would provide a clear and consistent picture? If so I can work on that update. Yes, that seems fine, if the tidying-up is complete. I was completely thrown by the "Scope" part, but this sounds reasonable. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile
On 27 Oct 2016, at 5:35, Sara Dickinson wrote: That would be good, yes. But "obtained" still sounds like it might come from the DNS itself, not from configuration or DHCP. Well it could come from DNS via a SRV lookup. How could it come from SRV? I am thinking (perhaps incorrectly) that it has to only come from configuration or DHCP. Do you prefer acquired/determine/derive? No, because none of those sound like "gotten locally". --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Step 2] More discussion needed: state your opinion
On 13 Dec 2016, at 6:46, Shane Kerr wrote: IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec may have problems traversing NAT. It is also usually implemented by the kernel, which may cause deployment issues. I *want* IPsec to be an option here, but realistically I don't think it is. IPsec will always have worse characteristics for DOS than DTLS, and probably worse than TLS. Why do want it to be an option here? The other alternative is to invent some novel crypto (fun but ill-advised) If what we invent has better characteristics than DTLS or TLS, that means that the TLS WG failed to find something that we could. That seems *incredibly* unlikely, given the people active in the two WGs. or steal some equivalent (like the crypto part of DNScurve, also mentioned in the draft). The "crypto part of DNScurve" could be added to (D)TLS. After TSIG, DNSSEC, DNS cookies, and the rest, it would be weird if DNS used something standard, but maybe we can try it for once? ;) Yes. 2) Which authentication(s) to use? I really like the CGA approach, but realistically I don't think that would be accepted. If we think that it would be, then I'm all for it. Why do you think it would not be accepted? It could be used where available, and fall back to current authentication when it isn't. Otherwise I think we should lean towards putting authentication tokens in the DNS itself. OK, now I'm confused. I thought this is what you meant by "CGA approach". Can you explain the difference? AIUI the draft, if we want to use DNS the problem is that we want to know how to encrypt a session to a name server, but we can't look up anything about the name server in the DNS because we don't yet know how to encrypt a session to the name server. The draft drifts towards that, but I don't think it is the right problem statement. Instead, we should be going towards "encrypt wherever possible, but don't limit yourself if you can't." --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Step 2] More discussion needed: state your opinion
On 14 Dec 2016, at 3:34, Shane Kerr wrote: IPsec seems desirable because somehow it seems better to be able to layer on top of security at the lowest level possible? Layer 3 instead of layer 4? Although I guess the only extra information we would be exposing with TLS or DTLS would be the port numbers, which seems minimally useful to an attacker. Exactly. Further, you have to negotiate in IPsec which ports and addresses within the "range of one target address" the client has access to, and that (you would think simple) negotiation has proven too difficult for some IPsec developers in the past. 2) Which authentication(s) to use? I really like the CGA approach, but realistically I don't think that would be accepted. If we think that it would be, then I'm all for it. Why do you think it would not be accepted? It could be used where available, and fall back to current authentication when it isn't. CGA requires IPv6, and the hash is only 60-some bits long, so maybe it is both too futuristic and not future-proofed at the same time. Like I said, I really like it but I can see push-back. Got it. I thought you meant "CGA-like DNS", not actual CGA. DNScurve's method of having he key in a DNS label is "CGA-like DNS" to me. I happen to like it a lot. --Paul Hoffman ___ 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-padding-policy-01.txt
On 3 Jul 2017, at 14:29, Alexander Mayrhofer wrote: i've updated the Padding Policy draft - the main change is the inclusion of an actual recommendation, essentially a blunt copy of Daniel's recommendations from his empirical research work. I'm looking forward to hearing a discussion around these recommendations - I will subsequently update the draft based on the outcome of those discussions. The new wording seems fine to me. I know we'll get people complaining about how long the suggested defaults are, but they are just suggested defaults, not demands. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] dprive (bar) BoF?
On 6 Nov 2017, at 9:28, Allison Mankin wrote: I think we should sign up for one of the breakout rooms on an evening and use Hangout to bring in Sara and Europeans. We can't keep everyone happy but I think a lot of US folks are attending, and also we can write up some notes. How about the evening after the Plenary? That's probably the best evening and I suspect we can find later-night food after the call. --Paul HOffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote: On Mon 2017-10-30 13:11:41 +, Sara Dickinson wrote: if it ends up just being a MAY (although I would like to see SHOULD as a minimum for opportunistic). SHOULD validate, but with what failure mode? +1 to the question: we're talking about Opportunistic mode here. are we really saying that opportunistic SHOULD deliver a DoS instead of a loss of privacy? Some of us are most emphatically not saying that. . . . sure, but this is the case for non-private DNS as well, right? So the mitigation in this case is with respect to the features that "private DNS" is supposed to offer. Whatever those features are, they are absent given an attacker-controlled DNS resolver. So if the DNS-over-TLS server is intended to also provide integrity protection, yes, that would also be lost. I think we're agreeing here, right? I apologize if "loss of privacy" is a misleading shorthand. Take the case where the DNS server from DHCP really is legitimate. The fact that the meta-query answer _could_ be spoofed provides a vector for an opportunistic client to be directed to an attackers' DNS server. Note that this attack is not possible on a ’normal’ client that directly uses the DHCP provided server, the attacker has to attack each individual query. My concern here is that without DNSSEC validation of the re-direct Opportunistic clients have an additional risk of this kind of attack than ’normal’ ones. ok, i think i understand. The concern is that a non-network-controlling attacker who can spoof DNS responses but can't spoof DHCP responses can now take over full DNS resolution of opportunistic clients just by racing (and winning) the legitimate metaquery response. This is true, but the threat model we're worrying now include all of the following characteristics: * attacker does not control the client's network (otherwise, they could redirect the port 853 queries anyway) * attacker cannot (or has failed to) race the client's DHCP connection (otherwise, they'd point to a different DNS server anyway) * attacker *can* race the legitimate response to the client's opportunistic metaquery. * client is in opportunistic mode. So the question is, in this particular corner case, what is the right mitigation to the scenario where "if DNSSEC validation of the opportunistic metaquery fails…" ? if the answer is "…proceed as though it had not failed (trying to connect to the preferred server's proposed address), but continue listening for another response to the metaquery; prefer subsequent metaquery responses that do have DNSSEC validation over those responses that are not DNSSEC validated." Then i'd be ok with it, but it's not specified in the draft. If the answer is "…hard-fail and deny DNS service", then i think that's incorrect given the goals of opportunistic mode. Agree. And fully agree that an attacker who can do the third bullet *but not the second* is a very obscure corner case. Having this document say, in essence, "you don't get opportunistic encryption unless you add a DNSSEC validation stack" feels like a regression to the original goals of this WG. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
On 30 Oct 2017, at 6:11, Sara Dickinson wrote: I’d disagree that connecting to a server for which the meta-query response failed DNSSEC validation results in _just_ a loss of privacy for Opportunistic in this case. If the answer was BOGUS then it seems reasonable to assume the server is not legitimate and so connecting also results in the clients' entire DNS service being controlled by the attacker. There are many ways to get a BOGUS response that have nothing to do with the information being "not legitimate". Typically today, BOGUS comes from misconfigured servers such as expired keys, some nameservers out of sync, and so on. You cannot infer from a BOGUS response about why it is bogus. Take the case where the DNS server from DHCP really is legitimate. The fact that the meta-query answer _could_ be spoofed provides a vector for an opportunistic client to be directed to an attackers' DNS server. Note that this attack is not possible on a ’normal’ client that directly uses the DHCP provided server, the attacker has to attack each individual query. My concern here is that without DNSSEC validation of the re-direct Opportunistic clients have an additional risk of this kind of attack than ’normal’ ones. Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to me. Also this is only a guaranteed DoS for the case where there is only a single server configured. If there are multiple servers then the attacker must spoof the meta-query answers for _all_ the servers to achieve DoS. If it only spoofs one then the client can still get service. ...unless the attacker can spoof the (typically) two servers that the client has addresses to. So one way to look at the trade-off seems to be is it worse that an attacker can block your DNS service or gets an extra chance to control all your DNS answers? I think you are arguing that for opportunistic the latter is preferable because a principle of Opportunistic is that it shouldn’t fail? If the WG decided that to be the case then it needs to be clear in the document this choice comes with an additional risk (and yet still not guarantee of privacy). It is only an "additional risk" for a very limited attacker who can only attack one of a set of addresses. If the WG wants to go down the path of making Opportunistic encryption even more difficult in order to feel that we offered the best security, requiring DNSSEC on the client is a good way to do that. I would still prefer more ubiquitous encryption. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] Still interested in recursive-to-authoritative
While we wait for the charter update, I'd still like to find out who is interested in pursuing draft-bortzmeyer-dprive-resolver-to-auth. Personally, I think it is a good start on an important topic, but I don't hear others supporting it on the list... --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] IETF 102 Agenda topics
Given the large number of responses to the thread about DNS-over-TLS for recursive-to-authoritative, I would hope that this topic would have a significant part of the meeting. The biggest open topic is authentication of the server. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] IETF 102 Agenda topics
On 11 Jun 2018, at 9:24, Russ Housley wrote: Given the large number of responses to the thread about DNS-over-TLS for recursive-to-authoritative, I would hope that this topic would have a significant part of the meeting. The biggest open topic is authentication of the server. Should there be something in the server certificate that makes it clear that the server is an authoritative DNS server? I do not think that an arbitrary Web PKI certificate is sufficient. At a minimum, I think there should be an extended key usage in the certificate. This would be a good discussion to have on a thread about the draft, not a thread about the agenda topics. :-) --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Re: [Editorial Errata Reported] RFC7858 (5375)
On Jun 1, 2018, at 11:45 AM, Brian Haberman wrote: > > Terry, > Unless the authors state otherwise, this looks like an error at > publication time and the erratum can be marked Verified. I'm pretty sure it was correct at publication time (I think I checked it); I suspect they changed it. Either way, is should be marked as Verified. --Paul Hoffman signature.asc Description: Message signed with OpenPGP ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Resolver to authoritative discussion guidance
So, with padding policy now in the RFC Editor's queue, it would be grand if the WG could put more energy into resolver-to-authoritative. The chairs started a bunch of topic-specific threads that got a bit of response, but then silence fell. I care a lot about this, and hope others do as well. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Recursive Resolver Operator Perspective
On 25 Jul 2018, at 18:07, Paul Wouters wrote: On Jul 25, 2018, at 12:37, Paul Hoffman wrote: Some resolver operators have recently spoken of a new use case: giving assurance of results in unsigned zones, and assurance of child NS and glue records in signed zones. This use case is not about privacy. That should not be considered a valid use case for privacy or otherwise. No one should trust data delivered over the internet without origin security, regardless of which protocol we are talking about. This use case has origin security. That is, the authoritative server must be fully authenticated. It is similar to web content over TLS. --Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
The user scenarios that I can think of are: 1) Users want DNS transaction privacy if possible 2) Users need absolute DNS privacy 3) Users want DNS transaction authentication if possible 4) Users need absolute DNS authentication #1 is basically opportunistic encryption: the resolver keeps going even if the server can't be authenticated. A MITM can see the transaction, but a passive observer cannot. Widespread use of #1 would reduce the ability to snoop on resolver traffic. I cannot think of a real use case for #2. That is, I cannot imagine a way for a user to usefully signal to a resolver "you must have authenticated transaction privacy with all authoritative servers; if any of the servers cannot do that, don't continue and return an error to me". #3 does not help prevent any attacks I can think of. #4 is a new use case that has been discussed recently to give assurance of results in unsigned zones, and assurance of child NS and glue records in signed zones. This use case is not about privacy. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Recursive Resolver Operator Perspective
Some resolver operators care about their customers' general privacy. In such a case, they would want to prevent passive snooping of communications between the resolver and authoritative servers. Preventing passive snooping would require encryption, but does not require authentication. Some resolver operators have recently spoken of a new use case: giving assurance of results in unsigned zones, and assurance of child NS and glue records in signed zones. This use case is not about privacy. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for Adoption: draft-dickinson-dprive-bcp-op
Yes, please! --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Potential re-charter text
The new charter text seems fine, even if we don't actually do all four work items. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Maybe a new URI scheme dnss: ?
On 12 Apr 2018, at 9:59, Brian Haberman wrote: Erik Kline posted about this about a month ago on this list. In general, I think this appears to have some interest behind it. Gh, I can't believe I forgot that, particularly given how recently it was. Apologies to Erik. And I'll work with him on a proposal based on the discussion on the list. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Maybe a new URI scheme dnss: ?
On 17 Apr 2018, at 2:38, Erik Kline wrote: And looking at this thread I see I missed Stephane's response that perhaps I should have asked uri-review@. Having a full proposal (even if it is one that will be abandoned) is the best way to approach that list. I'm happy to work on that with you. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for minute takers and Jabber scribes
I can do minutes, as long as you like wordy and possibly TMI. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Rough Agenda for IETF103
On Oct 22, 2018, at 1:12 PM, Tim Wicinski wrote: > Here's a rough agenda for IETF103. We're going to follow through on the > discussions from the mailing list on the User Perspective, and Recursive / > Authoritative Perspective. > > https://datatracker.ietf.org/meeting/103/materials/agenda-103-dprive-00 Does this mean that there will be no discussion of draft-ietf-dprive-bcp-op? --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Rough Agenda for IETF103
On Oct 23, 2018, at 7:06 AM, Brian Haberman wrote: > > Hi Paul, > > On 10/22/18 4:37 PM, Paul Hoffman wrote: >> On Oct 22, 2018, at 1:12 PM, Tim Wicinski wrote: >>> Here's a rough agenda for IETF103. We're going to follow through on the >>> discussions from the mailing list on the User Perspective, and Recursive / >>> Authoritative Perspective. >>> >>> https://datatracker.ietf.org/meeting/103/materials/agenda-103-dprive-00 >> >> Does this mean that there will be no discussion of draft-ietf-dprive-bcp-op? > > The authors indicated that they had received a lot of good feedback, but > haven't had time to turn those comments into actual document changes. Ah, OK. I was hoping we could maybe give the more at the meeting. :-) --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Authoritative Server Operator Perspective
On Oct 9, 2018, at 2:28 PM, Brian Haberman wrote: > Sorry for the delay in getting this week's thread started. I would > like the focus for this week (10/8-10/14) to be on clarifying the > technical requirements from the authoritative server operator's > perspective. This will encompass the technical issues for all servers > responding to DNS queries (i.e., *LDs). 1) An interoperable specification for how to encrypt messages 1a) If it is layer 4, it is likely to be TLS 1b) If it is layer 7, it is likely to be CMS 2) An interoperable method to tell resolvers who might want encrypted responses how to send them. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> >> I do not have a scenario where the client (the resolver in this case) >> needs downgrade protection for privacy. > > In that case there's no need to worry about authentication at all. > (But I disagree.) And I disagree that there is "no need to worry". As I said in my initial message, a resolver operator might want to take advantage of it if it is available. > More generally, I don't think the term "opportunistic" is very helpful, but it is the hard-fought agreement of the IETF. See RFC 7435. The abstract is quite simple: This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 2, 2018, at 11:26 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> On Oct 2, 2018, at 3:12 AM, Tony Finch wrote: >>> Paul Hoffman wrote: >>>> >>>> I do not have a scenario where the client (the resolver in this case) >>>> needs downgrade protection for privacy. >>> >>> In that case there's no need to worry about authentication at all. >>> (But I disagree.) >> >> And I disagree that there is "no need to worry". As I said in my initial >> message, a resolver operator might want to take advantage of it if it is >> available. > > I don't understand: first you say you don't need downgrade protection, > then you say you want authentication. Yes, exactly. > This isn't consistent. Yes, it is. Note the difference between "need" and "want". > You aren't > taking advantage of authentication if you are vulnerable to a downgrade > attack. If I have a path with authentication and a path without, and I prefer (not demand) the path with authentication, I am taking advantage of it. > In that case the authentication is worthless. We disagree. To me (and clearly to many others), it has worth when it is used. > >>> More generally, I don't think the term "opportunistic" is very helpful, >> >> but it is the hard-fought agreement of the IETF. See RFC 7435. > > Yeah, and the point I am making is that it is important to pick apart the > teo options described in RFC 7435's abstract. They have very different > deployment characteristics and security guarantees. For protocols like > SMTP or DNS there isn't an easy identifier that can be reliably > authenticated, Why not? IP addresses work just fine in both of those cases. The web world has decided that domain names are good enough identifiers for them, so other worlds might use them as well. > so authenticated encryption needs extra deployment work > (e.g. DANE) to be reliable, DANE works as well, but it is not the only possibility, depending on your use case. If you want to stay within the single-root DNSSEC model, DANE works great today, and there have already been proposals here for protocol extensions to make domain names and IP addresses work as well if we authenticate them on the parent side of a zone cut. > and if you do that work you get downgrade > protection as a bonus. If you don't do the extra work you can do > unauthenticated encryption, but you remain vulnerable to active attacks. > If you do the extra work without including downgrade protection then you > might as well not have bothered. Again, we disagree. Some resolver operators want to get good security when they can get it, and are willing to do a little work to get it. > Perhaps I should say that this strict security can only apply if both the > server advertises it and the client looks for it; if either of those don't > apply then you get unauthenticated opportunistic encryption, which is OK, > but we can do better when both ends want to be secure. Yes, that would be good to say. :-) It then does not denigrate the people who don't need strict security but want to use what RFC 7435 describes as opportunistic. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 1, 2018, at 8:50 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> >> During earlier discussions of opportunistic encryption in the IETF, >> attempted-but-not-required authentication was strongly preferred over >> "don't even attempt to authenticate". > > This is only worthwhile if there is downgrade protection, i.e. the client > needs to be able to tell if it is supposed to be able to rely on an > authentication mechanism (e.g. using DANE). Without downgrade protection > it's equivalent to encryption without authentication. We have to be careful when we are talking about recursive resolvers. By "client" above, I think you mean "customer of the recursive resolver" and not "the side of the recursive resolver talking to authoritative servers". Brian asked for this thread to be from the perspective of a recursive resolver operator. If I were running a recursive resolver, I want to do the best job I can for my customers, in this case giving them better privacy. I cannot guarantee them great privacy, but I can make good efforts even if they don't understand those efforts, and attempted-but-not-required authentication is better effort than "don't even attempt to authenticate". Personally, I do not know of any resolver customers that require downgrade protection unless they are running the recursive resolver for just themselves. That is, "downgrade protection" means "if you cannot get an authenticated answer, you literally want no answer at all". Answers for some RRtypes, notably TLSA, require DNSSEC authentication that must have downgrade protection, but that is not what we are discussing here. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Authoritative Server Operator Perspective
> On Oct 10, 2018, at 2:55 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> >> 1) An interoperable specification for how to encrypt messages >> 1a) If it is layer 4, it is likely to be TLS >> 1b) If it is layer 7, it is likely to be CMS >> >> 2) An interoperable method to tell resolvers who might want encrypted >> responses how to send them. > > 3) An interoperable method to tell resolvers how to authenticate an > authoritaive server. Yes, definitely. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 1, 2018, at 10:49 AM, Tony Finch wrote: > > Paul Hoffman wrote: >> On Oct 1, 2018, at 8:50 AM, Tony Finch wrote: >>> >>> Paul Hoffman wrote: >>>> >>>> During earlier discussions of opportunistic encryption in the IETF, >>>> attempted-but-not-required authentication was strongly preferred over >>>> "don't even attempt to authenticate". >>> >>> This is only worthwhile if there is downgrade protection, i.e. the client >>> needs to be able to tell if it is supposed to be able to rely on an >>> authentication mechanism (e.g. using DANE). Without downgrade protection >>> it's equivalent to encryption without authentication. >> >> We have to be careful when we are talking about recursive resolvers. By >> "client" above, I think you mean "customer of the recursive resolver" >> and not "the side of the recursive resolver talking to authoritative >> servers". > > No, I'm thinking in terms of client = recursive, server = authoritative, > which are the ends of the connection that we want to improve. I do not have a scenario where the client (the resolver in this case) needs downgrade protection for privacy. We have no privacy now. If we start having privacy, there might be resolvers who only want to send queries that are private, but that feels like a different DNS than what we have today. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Recursive Resolver Operator Perspective
On Oct 1, 2018, at 6:36 AM, Brian Haberman wrote: > > All, > Thanks for a productive set of exchanges on the user perspective > last week! I would like the focus for this week (10/1-10/7) to be on > clarifying the requirements from the perspective of the recursive > resolver operator. So far, I have seen: > > * DNS transaction privacy w/o authentication > * DNS transaction privacy w/ authentication of the authoritative server(s) > > Do others have additional requirements? A third one is DNS transaction privacy with attempted-but-not-required authentication. This is the opportunistic encryption scenario: a resolver wants the best transaction privacy they can get. If example.com has two nameservers, ns1.example.com and ns2.example.com, and I cannot authenticate ns1.example.com, I will prefer to use ns2.example.com because doing so make a system-in-the-middle attack harder. I might sometimes try to authenticate with ns1.example.com again so that I can then choose between them based on other attributes such as speed, but I will prioritize ability to authenticate. During earlier discussions of opportunistic encryption in the IETF, attempted-but-not-required authentication was strongly preferred over "don't even attempt to authenticate". --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] User Perspective
On 24 Sep 2018, at 7:08, Brian Haberman wrote: > All, > I would like the focus for this week (9/24-9/30) to be on > clarifying the requirements from the user's perspective. So far, I have > seen: > > * DNS transaction privacy, if possible > * User willingness to send PII if transaction is encrypted > > Do others have additional requirements? Not a requirement, but a strong desire: ability for a resolver to efficiently discover whether an authoritative server has privacy enhancements turned on. With that ability, given a list of NS records, a resolver might choose the privacy-enhanced one first. > If you agree with the above, could you describe a scenario to highlight > the requirements? The requirement for "DNS transaction privacy, if possible" is simple: it is known that malicious third parties will snoop the network for DNS traffic, and some resolver operators want to thwart that for the benefit of their customers. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Authenticating DoT nameservers for insecure delegations
On 28 Sep 2018, at 8:32, manu tman wrote: > I have been thinking of a way to authenticate DoT servers for delegations > that cannot be validated using DANE as describe in Stephane’s draft > https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth-01 > > The idea is to leverage both DNSSEC and SPKI to authenticate a zone but by > relying on the parent to validate the public key. I have documented it at > > https://datatracker.ietf.org/doc/draft-bretelle-dprive-dot-for-insecure-delegations/ > > Feedback is welcomed. Thanks This approach (putting the SPKI in the parent) seems fine, as long as the parent is signed. If I read it correctly, it would not work securely if the parent is not signed, correct? Also, I disagree with the logic in Section 3.1 on using PKIX. Using PKIX certificates does not mean using the same CA structure as the web PKI, and trusting CAs for nameservers could be made a lot better than the current CABForum rules. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Issues with encoding keys in nameserver DNS names
On Dec 14, 2018, at 10:12 AM, A. Schulze wrote: > > Am 11.12.18 um 06:38 schrieb Mukund Sivaraman: >> There was some discussion in last night's meeting about encoding keys in >> the DNS name of a nameserver, similar to DNSCurve. There are at least >> some issues with it: >> 1...4 > > 5. Encoding a key as DNS name of a nameserver makes key rotation harder. > Not impossible, but really much harder. More generally, encoding a key anywhere else makes key rotation harder. It doesn't matter if it's a NS record, an HTTP header, or a text list of current keys. All of these can be automated, and that automation will mostly work, and will cause massive problems in the rare times it doesn't. Having a second place to assure the value of a key is valuable, but that inherently adds some fragility. 'Twas always thus. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] DNS PRIVate Exchange (dprive) WG Virtual Meeting: 2018-12-10
On Dec 5, 2018, at 6:25 AM, Paul Wouters wrote: > > On Fri, 30 Nov 2018, Paul Hoffman wrote: > >>> I am not sure I see a need for a different TLS/DTLS profile compared to >>> regular (web) based (D)TLS connections. What do you or Karl think would >>> be different? >> >> (D)TLS is not the only option. Using message security instead of connection >> security would eliminate the need for keeping TCP and crypto state on the >> server, and could maybe reduce the amount of CPU usage as well. > > Is there a draft that describes this message security? Or is that part > of the work to be started? The latter. > It seems that before dprive publishes a (D)TLS profile, that this path > should be considered first? Maybe, or maybe they can be done in parallel. There are already plenty of message security standards to start from (COSE, CMS, OpenPGP), and "encrypt a simple DNS message body" is trivial. What is less trivial is weighing the costs and benefits to resolvers and authoritative servers, which is the work that is going to start happening soon. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] DPRIVE Phase 2 Milestones and Requirements for WG Virtual Meeting 2018-12-10
On Dec 10, 2018, at 6:37 AM, Erik Nygren wrote: > After some discussing with some colleagues, a few topics that came up which I > added to the wiki for discussion: The changes you added all assumed that TLS was going to be the protocol chosen. I have edited (hopefully politely) to indicate that the WG might still choose a connectionless protocol such as sending COSE-based messages. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 23, 2018, at 2:45 AM, Vittorio Bertola wrote: >> Please stop with the "IETF is disrupting" stuff. No one forces anyone to use >> DoT or DoH. Both were features that the user communities asked for, and the >> user communities will ask for changes when they get deployed. > Which user communities are you referring to? Users of browsers. > It doesn't look like there is much request for DoH in the ISP and DNS > operator community - actually, I see more and more pushback. The current round of pushback, all of which appeared after the standard was finished, seems to mostly be coming from DNS vendors, not ISPs or DNS operators. During the development of the DoH standard, people from many DNS vendors (including the one you work for) contributed to the spec without objection in the WG. > If you talk about the end-users of the Internet, where and when did they ask > for this, and how many users actually want this? By choosing a browser. That's the best metric we have, unfortunately, since most of them can't choose their ISP based on the type of DNS service their ISP offers. > Because I am quite sympathetic with any dissident community under > authoritarian regimes, but in Europe there currently are millions of > end-users that use DNS-based security and parental control filters, for > example. The ratio would be something like 10'000 people who happily and > voluntarily ask their ISP to, as you say, "lie" on DNS queries (and will lose > this service if their browser starts to direct their DNS queries somewhere > else) We cannot be sure that they will lose such a service: we still have no idea how browser vendors will offer DoH. I suspect that if they offer it in a way that causes users to get fewer of the services that they have now, those browsers will (correctly) get castigated. > for every dissident that absolutely needs Cloudflare to get all his DNS > queries by default because he is planning to overthrow the government but > does not know how to get into Firefox's preferences and manually set the name > server to 1.1.1.1. (Technical note: Firefox never sent DoH queries to 1.1.1.1.) > Sorry if I am being sarcastic, but these DoH "pro user" claims sounds quite > unrealistic to me, and just an excuse for business interests and more Silicon > Valley data greediness - or, as a minimum, they reflect an incomplete, > partial view of what users want. We fully agree here. There are no good metrics for why users pick one browser over another. In their absence, we have to assume gross overall usage which is absolutely "an incomplete, partial view of what users want". But the same is true fo how they pick an ISP based on that ISP's DNS service offerings. As PaulW pointed out earlier in the thread, we know that many ISPs give local addresses to a resolver that simply forwards to 8.8.8.8 (or presumably to other open resolvers). Users have zero visibility to those practices as well. This thread comes down to "we think applications should not do X", as if we have now become the application police. It's fine to say "doing X has these negative effects" so that the application vendors will become aware of that, but we still have no idea if any application will even do X at this point. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 22, 2018, at 2:03 AM, Vittorio Bertola wrote: > > > >> Il 21 novembre 2018 alle 21.17 Christian Huitema ha >> scritto: >> >> You make it sound like some aggressive attack, but it is a trade-off. >> The IETF is working to enhance the privacy of DNS users, > > I'd argue the opposite - what the IETF is doing is in the overall reducing > the privacy of DNS users, by trading some more privacy in transport with much > less privacy due to more centralization of DNS resolution operations on a > global scale, and to an uncontrollable mess of applications each one starting > to send DNS queries to whatever server they like without the user having any > practical control mechanism, or even knowing what's happening. DoH did not suddenly allow browser vendors to do something new: they've been able to do exactly what DoH is standardizing for more than 20 years. Saying that the IETF is reducing the privacy is completely incorrect. What the DoH standard did is make it so that browser vendors (and, to a much smaller extent, web applications) could reach a larger variety of DNS servers in a standardize way. If you want to prevent over-centralization of queries going to a small number of large resolvers, you should be making it easier for resolver operators of all sizes to become DoH servers. It looks like your company is doing exactly that: thank you! >> and the >> authenticity of DNS responses. Doing so inevitably affects the >> operations that relied on the lack of privacy or lack of security of DNS >> operations. > > Well, no. Except for a few cases (e.g. transparent DNS proxying), DNS-based > security techniques do not rely on the "lack of privacy of DNS operations", > and the proof is that they would continue working perfectly well with DoT or > DoH, as long as the user continued to use the resolver on the local network. Saying that transparent DNS proxying (firewall capture and re-writing) is "a few cases" belies what people in the firewall industry have known for years: DNS rewriting (also known as "DNS lies") is an extremely popular feature in firewalls of all sizes. > Instead, DNS-based security techniques rely on the assumption that there will > be only one name server for all the applications on the user's device, and > that that server will be, at least by default, the one advertised by the > local network. If we had universal deployment of organizational VPNs, that could be true. Even after 20 years, we are sadly far from there. > This is the assumption that the IETF is disrupting, and that breaks a lot of > stuff that has full rights to exist and has nothing to do with invading the > user's privacy. Please stop with the "IETF is disrupting" stuff. No one forces anyone to use DoT or DoH. Both were features that the user communities asked for, and the user communities will ask for changes when they get deployed. > >> Also, if you analyze the enterprise scenarios, you observe a need for >> both management and privacy. Enterprise managers would rather not see >> employees perusing frivolous web pages during work time, but they also >> don't want outside parties to analyze their web activities. Leaking DNS >> usage patterns to third parties can reveal work in progress, internal >> research, etc. > > Which is exactly what happens if the enterprise's users start being > automatically connected to a DNS resolution service outside the local network > and managed by a third party, which is what DoH is doing. If a browser's use of DoH breaks its users resolution of organizational names, it will get fixed or turned off. (I'm betting on the latter, but others have more faith in the browser vendors fixing than I do.) --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 22, 2018, at 4:29 AM, Barry Raveendran Greene wrote: > The irony is that this work is operationally destabilizing to the Internet > and Telecom. We’re moving to an environment where the strength of a resilient > ASN recovering communications in a disaster will be tested over and over > again. How will an ASN keep critical services on-line when they are > disconnected from the “cloud,” disconnected from their upstream, and now > “disconnected from the DNS resolution path? > > Exasperated customer calling after a hurricane, “ISP customer service, I need > to get to emergency services, but my app will not work.” The ISP responds > with “sorry, that app will not work in a situation where we’re struggling > with emergency services.” > > The “trade off” to move the DNS architecture away from residents to privacy > is going to get people killed. If a browser forces DoH in cases where there are no working DoH servers, that will absolutely be the case. It will even be the case if the user can manually turn off DoH, but only if the user know the correct UI incantation. It is reasonable to assume (but not assured) that browser vendors are aware of this. --Paul smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Doh] [Ext] DNS over HTTP/3?
On Nov 26, 2018, at 6:31 AM, Ray Bellis wrote: > > On 23/11/2018 16:45, Paul Hoffman wrote: > >> The current round of pushback, all of which appeared after the standard was >> finished, seems to mostly be coming from DNS vendors, not ISPs or DNS >> operators. > > There was _plenty_ of pushback when this got presented at UKNOT, > especially among those ISPs that are currently using government- > mandated DNS-based blocking of CAI sites. Ah! That is interesting to hear. Any links that you have to that would be greatly appreciated. > >> During the development of the DoH standard, people from many DNS vendors >> (including the one you work for) contributed to the spec without objection >> in the WG. > > I wouldn't say it was "without objection", because there were clearly some > significant impedance mismatches to resolve, both between the HTTP and DNS > people, and between the HTTP and DNS protocols. You may feel differently, but I saw no comments during WG or IETF Last Call that indicated that any mismatches still existed. If you feel that they do, the DOH WG is still open, and a draft describing the problems could garner interest. > Personally, I thought we were working on a means to provide an *ad-hoc* > DNS resolution and validation method in certain environments, and along > the way allow JS web-apps to perform proper DNS lookups. Fully agree. That is indeed what the RFC says. > The objections started when we heard that a particular browser vendor > wanted to make this ubiquitous for *all* DNS lookups. Then why aren't the objections aimed at that implementer instead of the spec? Any implementer can misuse any spec badly: that doesn't make the spec itself bad. The operational documents that come to the DNSOP WG are often about those situations. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Call for adoption: draft-bortzmeyer-dprive-rfc7626-bis-02.txt
On 27 Mar 2019, at 15:29, Brian Haberman wrote: > All, > This is a call to judge consensus on adopting: > > Title : DNS Privacy Considerations > Authors : Stephane Bortzmeyer > Sara Dickinson > Filename: draft-bortzmeyer-dprive-rfc7626-bis-02.txt > > as a DPRIVE WG document. Please voice your opinion on the WG adopting > this document by April 17, 2019. This is a very useful draft and should be part of this WG's work efforts. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] IETF 104: Call for agenda items
The WG adopted draft-ietf-dprive-bcp-op, which was last updated in December. It would be good if that was on the WG agenda, and if we could hear where the authors think they need input from us so we can discuss that before the draft cutoff, or maybe in Prague. I would love to see draft-bortzmeyer-dprive-rfc7626-bis progress, given the new focus of the larger community on the problems presented by some DoH deployment scenarios. Maybe the WG could discuss adopting that document in the WG meeting. If people are still interested in opportunistic TLS between recursive and authoritative servers, I can toss together a short draft that touches on some of the ideas from other earlier drafts and that could be discussed in Prague as well. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Call for Adoption: draft-hal-adot-operational-considerations
On Aug 15, 2019, at 12:24 PM, Henderson, Karl wrote: > > To be clear, ADoT is not a new standard. This is simply DNS over TLS as > specified in RFC7858, RFC 7858 makes it clear that it is for stub-to-recursive. That is called out in the Abstract and the Introduction. > further defined as ADoT in > https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-02, That is a, um, "creative" reading of the phrase "later defined". --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On 11/1/19 2:09 PM, Eric Rescorla wrote: > It seemed like it might be a good idea to take a step back and talk > about threat model to see if we're all on the same page. > > The set of threats I am concerned with is primarily about an on-path > active attacker who learns the query stream (i.e., the domains being > queried) coming out of the recursive resolver. It's of course mostly > inevitable that the attacker learns which authoritative servers are > being queried, but I think we can all agree there's still plenty of > information to leak here [0]. > > > In the current DNS, such an attacker can of course just perform a > passive attack by listening to the DNS query traffic. It's possible to > straightforwardly exclude this attack by opportunistically attempting > DoT [1] to the authoritative. However, an active attacker can mount a > downgrade attack on the negotiation, forcing you back to > cleartext. So, unless you have a secure way of: > > (1) knowing the expected name of the authoritative for a given query > and that it supports DoT > (2) verifying that the server you are connecting to actually has > that name > > Then the attacker can just mount a MITM attack on your connections and > collect this data by proxying the traffic to the true authoritative. > > Do people agree with this assessment of the situation? Is this form > of attack something they agree should be in scope? This is one threat model, definitely. Another is passive snooping, such by someone who is watching at a point on the resolver's upstream connection to interesting authoritative servers. Another is passive snooping, such by someone who is watching at a point near interesting authoritative servers. One small modification I would make to your mode is to change #1 from "knowing the expected name of the authoritative" to "knowing an expected identifier of the authoritative", and #2 to "...actually has that identifier". Given the current landscape of resolvers and authoritative servers, using long-lived IP addresses for identification might be better; that would need to be hashed out during protocol discussion. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On 11/2/19 9:58 AM, Eric Rescorla wrote: > Generally, I would expect that a solution which addressed the active threat > model would also address the passive one. Of course, but there are many threat models that have different solutions. The passive threat models might be addressable more quickly than the active threat model. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
Given that we are (still supposedly) talking about requirements and not solutions, I would be unhappy with a requirement that prevents a resolver that is not validating from being able to use encrypted transport to authoritative servers. Any protocol we develop for ADoT capability discovery should prevent downgrade attacks but should also work fine for resolvers that do not validate. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] ALPN protocol ID for DoT
On Dec 12, 2019, at 7:01 AM, Reed, Jon wrote:
>
> Hi all,
>
> I'm planning to request a registration of an ALPN ID[1] for DNS-over-TLS.
> One primary use case we have is supporting both DoT and DoH on port 443, when
> port 853 is blocked between clients and the servers (this is by mutual
> agreement, as discussed in RFC 7858 § 3.1). I plan on requesting the
> protocol ID 0x64 0x6F 0x74 ("dot"), following the conventions of using all
> lowercase in registrations.
>
> Per discussion with one of the expert reviewers, I'm polling the list to see
> if anyone has objections -- if so, please let me know. I'd be interested in
> hearing the objections, and what alternatives might be proposed.
>
> Thanks,
> Jon
>
> [1]
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
This was discussed during the creation of RFC 7858. I would summarize the WG
discussion as follows:
- It is fine technically.
- It will cause confusion because there will be two ways to do DoT, so a client
might have to test each way in order to know if the resolver supports DoT.
- It is easier for clients to configure a different port than to configure
ALPN. In fact, many clients cannot configure ALPN at all.
Others may have different summaries from the discussion. Certainly, some folks
will have strong support or objections to those points; WG consensus was not
particularly easy on this topic.
Having said that, Jon brings up a good point that we did not predict four years
ago, namely that some resolvers might already be offering privacy services on
port 443.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29
On 10/25/19 6:25 AM, Brian Haberman wrote: > https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/ > > On 9/25/19 10:45 AM, Brian Haberman wrote: >> All, >> We are going to hold a DPRIVE virtual interim meeting on Oct. 29th >> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items are: >> >> - Review updates to the BCP based on WGLC comments, >> - Review updates to 7626bis based on WGLC comments, >> - Discuss recursive-to-authoritative requirements (-00 draft forthcoming). Will we be able to review the forthcoming recursive-to-authoritative requirements draft before the interim meeting? --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] ADoT requirements for authentication?
Greetings again. I was surprised, but happy, to not see a requirement in the list for authentication of servers in the list. However, I suspect that this might have been an oversight, and the endless debate on authentication requirements will start as soon as there is a proposed protocol document. My preference would be that the core requirement is that ADoT servers use either IP address or DNS name authentication in their certificates, but that the certificates can be issued by any CA, including being self-issued. The core requirement could also go on to say that resolvers be able to authenticate servers for logging purposes, but not be required to break TLS connections if the server's identity cannot be authenticated against the resolver's set of trust anchors. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29
Here are a few responses to the initial draft. I will try to be on the call unless we lose power again. There are many parts of the "core requirements" that seem out of place. - Resolvers have never had to understand the different between the root zone and TLDs and SLDs and "other", so introducing that here might cause bikeshedding and lack of adoption. A simpler core requirement would be that DoT is required between resolvers and any interested authoritative server. - QNAME minimization is orthogonal to adding cryptographic privacy. If you have a cryptographic tunnel, QNAME minimization adds overhead and the risk of additional round trips. On the other hand, some resolvers are perfectly happy using QNAME minimization all the time, so they shouldn't have to know whether to change settings if DoT is in use. - The aggressive caching requirement mixes up aggressive caching and normal caching in the all-caps bit. Aggressive caching will reduce the number of TLS connections you need to set up, so it is a positive, but it is unclear how requiring it in order to use ADoT could be enforced. - DNSSEC validation is orthogonal to adding cryptographic privacy. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
On 10/29/19 8:02 AM, Ted Hardie wrote: > To be sure I understand you correctly, in the second case, the connection > would be made to some IP address (e.g. NASA's 198.116.4.181). The recursive > resolver logs the details of the certificate, but it continues with the > connection even if the CA NASA uses for the certificate is not known to the > resolver? What does it do in the face of other certificate errors like > expired certificates or certificates presenting a different name? It continues. This is exactly how opportunistic encryption is defined. > I have to say that I'm pretty surprised by the idea that TLS in this context > should behave any differently than TLS in application layer contexts, and I'm > a little concerned about having configuration options for this that amount to > "ignore errors of types $FOO". TLS in application layers can specify that opportunistic encryption, yes? > Accepting self-signed certificates is a known configuration, so I get that, >but if someone has configured roots of trust, accepting other certificates >outside the roots of trust in the configuration is pretty odd practice. Do you feel that there is a requirement that all recursive resolvers use the same set of trust anchors? If not, and if you are against the use of opportunistic encryption in this case, who will decide what set of trust anchors all resolvers in all jurisdictions will use? --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Fwd: New Version Notification for draft-huitema-dprive-dnsoquic-00.txt
Thank you for continuing this interesting work. However, a reader might not realize that many other folks would prefer DNS/HTTPS/QUIC until the get all the way to Section 3.4. Also, the title of that section seems a bit unbalanced, given that the text says that people might prefer DNS/HTTPS/QUIC for reasons other than hiding from firewalls. For a future version of this draft, please consider moving the comparison to DNS/HTTPS/QUIC, and the discussion of not knowing which one folks will prefer, up to the Introduction. That would leave Section 3.4 just about the stated design goal. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] [Last-Call] Review of draft-ietf-dprive-rfc7626-bis-03
On Jan 9, 2020, at 7:41 PM, Eric Rescorla wrote: >>>> Section 3.5.1.2 >>>> >>>> I admit that I don't understand the purpose of this section. Concentrating >>>> on minutiae, like the details of DHCP or ARP/NDP spoofing, is far too low >>>> level. If we were to simply assume the usual threat model [RFC3552], then >>>> the conclusions here are obvious: if you fail to authenticate the server, >>>> then you get the server that an attacker chooses. >>>> >>>> I would remove this section in favour of improving Section 3.5.1.4, which >>>> addresses the most pertinent question. >>> >>> RFC7626 included Section 2..5.3 >>> https://tools.ietf.org/html/rfc7626#section-2.5.3 ‘Rogue Servers’. This >>> section is just an update of that text to improve context and remove the >>> phrase ’rogue server’. Since the majority of OS implementations still use >>> these mechanisms today it seems to still be relevant. >>> >>> Well, as MT says, this is just the 3552 threat model. The basic fact is >>> that you need a reference to a server that is (1) securely obtained and (2) >>> verifiable against the server itself. Absent that, you are subject to >>> attack by the network. >> >> Suggest adding a sentence at the start of the section “[RFC3552] provides >> guidelines for describing Internet threat models. This section specialises >> the discussion to the case of DNS resolver configuration.” >> >> Well, that's a start, but the problem is still that it's too low level. If >> you insist on having this section, you should lay out the implications of >> the situation rather than (or at least in advance of) digging into the >> details. > > The level is detail is entirely comparible to that in the original RFC (much > of the text is still the same). > > That doesn't seem like a particularly strong argument. We're revising this > document and the question is what is good now. > > > > As I said to Martin, the section focusses on the impact on the DNS resolution > path that results from the attack: diversion of traffic and traffic capture.. > Are there other implications you think should be included? Please suggest > text. > > I would replace the entirety of this section with: > > The Internet Threat model, as described in RFC 3552, assumes that the > attacker controls the network. Such an attacker can completely control any > insecure DNS resolution, both passively monitoring the queries and responses > and substituting their own responses. Even if encrypted DNS such as DoH or > DoT is used, unless the client has been configured in a secure way with the > server identity, an active attacker can impersonate the server. This implies > that opportunistic modes of DoH/DoT as well as modes where the client learns > of the DoH/DoT server via in-network mechanisms such as DHCP are vulnerable > to attack. In addition, if the client is compromised, the attacker can > replace the DNS configuration with one of its own choosing. Given that this topic is one where there is rampant confusion, I think brevity and clarity are best for this document. I believe Ekr's words cover exactly what is needed here, and agree that the rest of the section should be eliminated. I aslo agree with earlier comments that this document referring to draft-arkko-arch-infrastructure-centralisation is a bad idea. We have no idea what that document will end up saying when published as an RFC. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
