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

[Paul Wouters <[e-mail]>]

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.