Thanks for your review, Paul! I made some detailed comments below, but ahead of those, one of the core things that we were trying to facilitate with this draft is the notion that services may want to enable privacy protections selectively. While IPsec is a network layer service, we feel that this approach + DANE could be leveraged to let operators enable these protections separately per service. For example, a cloud provider could enable this for some of the clients that are virtualized on an instance (an IP) w/o necessarily doing so for all. This, we felt, was a fundamental opportunity, and helped motivate the new work (in our minds).
More comments below: On Feb 16, 2014, at 5:04 PM, Paul Wouters <[email protected]> wrote: > > Review of draft-osterweil-dane-ipsec > > I'm heavilly involved with Oportunistic Encryption using IPsec with The > Libreswan Project. We opted to first gain more experience with running > code before attempting to write a draft. As such, we have found many > corner cases that need to be handled that are completely left out of > this document. I think it's a good idea if the authors of this document > talk to people in the IPsec and DANE working groups. > > This draft introduces an overly complex and bad coupling of DNS, PKIX > and IPsec with the very limited goal of encrypting _some_ DNS traffic. > > It seems to make a lot more sense to use (D)TLS to encrypt DNS traffic > using the existing TLSA records at the _53.{tcp|udp} prefix. >From a defense-in-depth perspective, we felt it was prudent to offer operators >and security practitioners multiple options form which they can create their >own security posture. When we effectuate our security posture in our network, >we like to have multiple tools and configurable opportunities to create the >security policies that best fit our needs. Securing protocols at different >layers offers different benefits and drawbacks, and may even provide additive >protections. I think the [D]TLS discussion is orthogonal: that is, I think >it's totally a good idea, but not in conflict with securing the IP layer. > > Further comments below, > > Paul > > Abstract > > It is not clear from the document what is being attempted. Is it > encrypting all DNS traffic? The stub to the local resolver? Stub to a > remote resolver? What's special about DNS compared to using IPsec to > encrypt everything? The goal was being able to specify IPsec encryption on a per-service basis (this draft focused on DNS), and allowing the server operators to specify whether they offer IPsec. So, resolver operators _could_ offer it to stubs, and name server operators _could_ offer it to resolvers, but it doesn't mandate that anyone deploy anything anywhere. Rather, it's opportunistic about securing communications between networks. Does that run afoul of OE? > Introduction > > Don't use the word meta-data. It's just data. We don't need to give > TLA's more justification for the redefinition of the term meta-data. Actually, the reason for this phraseology is that I had thought this was specifically protecting meta-data leakage (i.e. the presence and timing of txns vs. their content), no? The idea that an adversary can see the presence (and nature of) of a txn is what the meta-data discussions are about, and those are not protected by https. By contrast, obfuscating the participants (i.e. the zone) of a transaction that is being attempted between transacting parties protects meta-data. That was the rationale, anyway. I'm not hung up on the wording, and if it is unpalatable, how would you suggest to draw the distinction? > The introduction makes clear only (some?) DNS data is being targeted for > encryption. Why would protecting DNS using OE-IPsec be treated > differently from protecting ALL traffic using OE-IPsec? In the event that you only wanted to pay the transaction overhead for some services (DNS), or for some service addresses (only some name servers), or just for some high priority transacting parties. This seemed to be useful knob for those that run very large infrastructures and have operational overhead concerns. Was the Section ``Operational Considerations,'' helpful, or did it not convey this clearly? We felt that being able to offer a nuanced security policy was one of the real advantages we saw in this approach. > For example, the information leakage exposed by observing DNSSEC > transactions, could enable an adversary to not only learn what Second > Level Domains (SLDs) a user is querying (such as their bank, a > funding agency, a security contractor, etc.), > > How does encrypting the DNS help? So now you don't see I was going to > "nohats.ca", > but you see port 443 packets to 193.110.157.102. DNS information that is > encrypted > yet acted upon, leaks per definition. This is like encrypting visits to > Google Maps > while broadcasting your GPS coordinates. Observing DNS transactions is a completely independent way to monitor someone's behavior. In a defense-in-depth security mode, this approach plugs the information leakage that is completely unaddressed by 443. True, if you have a root-kit on a system, you can see everything, but if you passively monitoring DNS, you would no longer learn info from transactions. Perhaps I'm missing the objection, but as you've outlined above, OE for DNS seems to plug a very expressive hole, right? > The last-mile protection argument is very weak. DNSSEC validators are moving > to what > used to be stub resolvers only. There is no need for new technology for > last-mile > protection. I have heard this, and talked to many people about it. I've also heard many obstacles being encountered, and I have noted that some are not as eager to do this as others. That said, the deployment base of those who _don't_ run recursive resolvers on their stubs is much larger right? Why would we not pursue a solution that would benefit the larger constituency? I think there are lot of benefits to running recursive resolvers on stubs, but I don't think we should abandon those who aren't doing it (i.e. most everyone today) and I don't think we can count this large change in the immediate future or mandate it. By contrast, this draft would allow OE between resolvers and name servers or stubs and resolvers (which would secure the last mile in either case). > > The bootstreap is unclear. DANE uses DNS yet you plan to encrypt DNS? I think we were hoping that the Section that discussed the bootstrapping clarified this, but perhaps not? The first transaction with the resolver would be to learn its IPSECA RR from the reverse zone, and then create an SPD entry. The 00 draft needs more details in Appendix B on this, but we had hoped the section describing the high-level conveyed this. Was it unclear, or was there an error that would need addressing? > Section 1.1 > > This section introduces using PKIX certificates for binding DNS to IPsec. > IPsec does not require X.509 and has support for bare public keys. Why > drag in the whole TLS style Certificate, Usage and Selectors? Unlike TLS, > there is no legacy base that needs to be accomodated. It makes no sense > to deviate from bare public keys. It adds all the complexity without much, > if any, benefit over the traditional IPSECKEY record. > > In fact, even the authors themselves see that: > > The advantages of using DANE for IPsec OE also include other > simplifications that the DANE protocol inherently offers all of its > protocols. Such as, the automatic deauthorization of certificates > that happens when they are removed from a DNS zone , which may (under > many circumstances) obviate the need for extensive use of revocation > mechanisms (OCSP [RFC6960] or CRL [RFC5280]) > > Storing public keys in DNS removes the need for things like PKIX expiry times, > CRL, OCSP... So why introduce PKIX at all??? Fair point. Do you think the text should simply accommodate PKIX certs, but defer to bare keys? Any chance you would be willing to suggest some text? > Section 1.2 > > This section talks about IPSECKEY and dismisses its use because it is limited > to > IP-centric networks. This is not the case when one places IPSECKEYs in the > forward > DNS (as the current Libreswan IPsec Opportunistic Encryption uses). For > example, > one can build a OE-IPsec tunnel to the host bofh.nohats.ca using the IPSECKEY > published for bofh.nohats.ca. No new IPSECA record is needed for that. Yeah, I definitely understand that. The intent of this discussion was mainly to outline that IP-centric lookups could be improved. The discussion was motived by the prescription to place IPSECKEY RRs in the reverse zone for lookups. That said, as a DANE protocol, it seemed to make sense to harmonize the RR w/ the architectural directions that seemed to be forming, no? Also, this draft was aimed at trying to enable service-level policies. > Section 1.3 > > When an IPSECA record is discovered by a resolver, that resolver SHOULD > follow > its configurations and setup an SPD entry. > > If your approach uses a local resolver to setup IPsec security, then > your approach could be much simplified using the same method we are > curently experimenting with, which is IPSECKEY records in the forward DNS > zone. If you are using a modified validating resolver on the host, it > also undermines your statement in the Introduction about this solution > being needed for last-mile authenticity of DNS - you already run a > validating resolver on teh stub. I think there are a couple of points you're making in the above, but perhaps I misunderstand: - This approach is designed to be incrementally deployable and service based. I mentioned this above, so I don't mean to be too terse, but I don't want to be repetitive: this was about differentiation protections for service, and it was being illustrated for DNS. - Validating resolvers don't provide the same transactional security model as IPsec, so I don't follow the comment about local validating resolvers. > When using IPSECA resource records to verify OE tunnels, clients MUST > perform full DNSSEC validation of the DNSSEC chain of trust that > leads to IPSECA RRs > > This looks like a big bootstrap issue. The old FreeS/WAN IPsec OE also > had isues with bootstrapping and DNS. It was so bad that when starting > freeswan, you would be dead in the water for about a minute while DNS > lookups for OE hit the OE machinery causing more OE lookups and it took > time to deal with all the failures before lines to DNS servers were > either encrypted or marked as cleartext (as opposed to block until we > know if we need to do crypto to it ) Interesting. How did you solve this? The idea behind the ``MUST'' was to avoid spoofing during the bootstrap (as w/ other conversations in the wg). Is the suggestion to not use DNSSEC for bootstrapping? I would definitely worry about that, but would definitely like to hear your thoughts. > Trust anchors (which may be distributed during dynamic host > configuration) may be useful for bootstrapping. > > Securing DHCP is a really hard problem. accepting trust anchors from DHCP > seems a security nightmare. It goes on to note that it is okay when using > RFC1918 space, but that is also dangerous. I might have VPN connections > that use RFC1918 that I don't wish to yield to a wifi-based trust anchor. I think the wording must have been unclear. The local TA/1918 discussion is the same thing, and is just a for-instance. Nominally, we have the ability to provide these details to clients in our corporate image, so we might look at that option. In the draft, however, we were trying not to be overly prescriptive. We had imagined that different installations would have different approaches here. For example, if you were to have local validating resolvers (as you championed above), you would have to solve this for the root TA anyway. Do you see a substantive difference? > Section 2 > > This section specifies the IPSECA record. As I already said, I see no good > reasons for introducing PKIX into this mix. I'm totally amenable to changing that. Do you have some suggestions? > Additionally, the use of a GATEWAY option means that these record MUST > NOT be used in any forward DNS, but only in the reverse, otherwise I > can put malicious entries into my forward DNS to steal other people's > IP address ranges. It is not very clear IPSECA is meant only to appear > in the reverse. Can you help me understand this? I would be able to send my clients to someone else's IP address for tunnel setup, but that would allow _them_ to steal _my_ traffic, right? I don't think I can steal their traffic this way, right? Resolvers would come to me to ask about my branch of DNS, I could lead them away, or answer them. So, if I point my zone to your name servers, you are the winner, not me, right? > Our experience with FreeS/WAN is that the reverse is just not good enough > apart for a few big players in data centers. And with IPv6, it becomes > even harder for people to put records in (resulting in amusing situations > like that I cannot email Paul Vixie). Depending on the reverse tree > means this will only be deployable by enterprises, and not by home users. Yeah, I think we were only talking about the reverse tree for stub-to-resolver lookups (and we imagined many of those would be in 1918 space). It was only our suggestion for last-mile DNS. Was that one of the design goals of FreeS/WAN? > IPsec is an IP to IP protocol. It can be used to hide port > numbers. Deploying IPsec using _prefix constructions that expose port > numbers defeats part of the security that IPsec offers over inline > encryption such as TLS or STARTTLS. Again, we felt that offering a defense-in-depth solution was useful because these security protocols have different profiles/benefits/drawbacks/etc. We have a mosaic of security policies in our operational network, and we find it useful to have multiple cooperating options to configure. From an OpSec perspective, I look at these security protocols as quite cooperative (especially as each entity's security posture can be motivated by their unique needs). Those that run operational networks ought to be able to use network layer security and transport layer security. > Section 3 > > The operational considerations are really weird. They basically state > "there is no operational impact as long as our protocol is not deployed > widely". I don't think that's completely true. Maybe the wording was unclear? We mention that the overhead can be managed and scales with the deployment. The scale drops to 0 under non-deployment, true. Maybe the wording was confusing? > It does not mention anything about additional latency for the end user. It > does not talk about the IPsec NAT-T and clashing/overlapping internal > IP addresses. It does not mention anycast issues, load balancers, crypto > offloaders, etc. True. What level of discussion of these do you think would make sense? There are almost certainly a myriad of situations in which it does not make sense to deploy this, or to only deploy it incrementally. Do you have any suggestions for how to structure these discussions in the draft? > Section 5 > > I'm not sure what the "cooperative benefits with TLS" are? What advantage > does this solution provide over using DNS (D)TLS with TLSA? I'm sure you know that there are tradeoffs to when and where I might want to use these different protocols, so I feel like I must be missing your objection. Are you intimating that IPsec has no advantages over [D]TLS, or just that there's a nuanced distinction here? > > Any combination of these types of > protections offer both defense-in-depth (securing transactions at > multiple levels) and offer security practitioners a larger mosaic of > security tools from which to construct and maintain their security > postures. > > This is a rather weak argument for adoption. So, this doesn't make sense to me. We use defense-in-depth models in our operations, and we find it very important in our daily operations. Why do you see this as weak? Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
