Subject: [dane] Review of draft-osterweil-dane-ipsec

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Feb 2014 17:04:21 -0500 (EST)

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.

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?

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.

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?

    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.

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.

The bootstreap is unclear. DANE uses DNS yet you plan to encrypt DNS?

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???

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.

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.

    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 )

    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.

Section 2

This section specifies the IPSECA record. As I already said, I see no good
reasons for introducing PKIX into this mix.

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.

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.

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.

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".

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.

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?

    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.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Tue, 18 Feb 2014 16:50:07 +0000

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:

>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.

> remote resolver? What's special about DNS compared to using IPsec to

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?

> 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?

> 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.  

> 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?

> used to be stub resolvers only. There is no need for new technology for last-mile

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?

> 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?

> 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.

> 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.

> 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.

> 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?

> reasons for introducing PKIX into this mix.

I'm totally amenable to changing that.  Do you have some suggestions?

> IP address ranges. It is not very clear IPSECA is meant only to appear

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?

> 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?

> 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.

> "there is no operational impact as long as our protocol is not deployed

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?

> IP addresses. It does not mention anycast issues, load balancers, crypto

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?

> 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?

> 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