Subject: [dane] IPSECA

From: "Osterweil, Eric" <[email-masked]>
Date: Tue, 24 Mar 2015 22:50:11 +0000

Hey Chairs & WG folk,

Given the discussion on milestones re: IPSEC DANE work at the beginning of the DANE session today we’d like to request working group adoption of the existing IPSECA document:
	https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02

We’ve been working on a couple of different flavors of implementation.  We’re hoping to push those out soon too and it’s already benefited from a great deal of discussion here, and we believe it’s definitely ready to become a WG product.

Can the chairs please progress as appropriate?

Thanks,

Eric

---

From: James Cloos <[email-masked]>
Date: Wed, 25 Mar 2015 11:40:13 -0400

I support the wg adopting this draft.

It needs a bit of work and discussion; such work is relevant here and
worth doing.

In §2.1.2 it has what looks like a copy-paste error, where it labels
Selector 2 as DANE-TA, whereas in both rfc 6698 and the acronyms draft
that is unassigned.

The IPSECA record here is identical to a TLSA except only in name.
If it does not need anything more than TLSA offers, why not just use
TLSA?  (Even if the answer is that that is the only way to signal ipsec
vs tls, it needs discussion.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 25 Mar 2015 15:55:56 +0000

> Selector 2 as DANE-TA, whereas in both rfc 6698 and the acronyms draft

Oops. . .   Fixing it.

> vs tls, it needs discussion.)

My 0.02 is that having different record types for different protocols gives us very useful flexibility (both if the RRs may need to evolve, and during DNS resolution).  It is, on the other hand, interesting that the IPSECA looks this way.  It was from wg feedback that we pulled the gateway information out (which the IPSECKEY RR has).  There seemed to be a potential MitM attack vector in there.  Regardless, I think we want to follow the wg’s direction on these issues.

Thanks for the feedback!

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Mar 2015 16:30:44 +0000

On Tue, Mar 24, 2015 at 10:50:11PM +0000, Osterweil, Eric wrote:

> Given the discussion on milestones re: IPSEC DANE work at the beginning
> of the DANE session today we?d like to request working group adoption of
> the existing IPSECA document:
>

I find the abstract and introduction to be an impenetrable jumble
of obstruse jargon.  These need radical surgery to make them clear
and concise.

    EXAMPLE:

	The suggested usage of this document is to aid in discovering
	where OE IPsec tunnels exist, and to act as an out of band
	verification substrate that can validate the certificates
	received during IPsec key exchange.

    First attempt at making it better:

	This document explains how to use DANE/DNSSEC to discover
	OE IPsec tunnels along with the associated authentication
	keys.

Why is so much of the focus on DNS confidentiality?  Is this the
primary use-case for opportunistic IPSEC?  Is IPSEC in fact likely
to be used to add confidentiality to DNS? Is that what the document
is about?

Once the jargon is simplified, the technical content is rather
light.  There is no detailed discussion of whether this is intended
to provide protection against passive attacks only, or also active
attacks.  The text about what to do with "bogus" responses is
unclear.

Finally, what I think is the biggest issue:

--- IPSEC and forward DNS

    [ The below was explained to me by Paul Wouters in London,
      thanks Paul.  Any mistakes in the below are mine, so if I've
      got the wrong end of the stick, that's not Paul's fault. ]

Creating IPSEC security associations based on forward DNS names
is rather problematic.  There is no discussion of the associated
issues.  Suppose we have:

	ns1.saint.example. IN A 192.0.2.1
	_53.saint.example. IN IPSECA 0 1 1 <saintly-digest>

serving the saint.example domain.  Clients secure their connections
to this nameserver by creating an IPSEC association with 192.0.2.1
using the given key material.  Along comes:

	ns1.evil.example. IN A 192.0.2.1
	_53.evil.example. IN IPSECA 3 1 1 <evil-digest>

publishing the same IP address as a nameserver for his own evil.example
domain.  Now clients create a replacement IPSEC tunnel to 192.0.2.1
(there can only be one) and suddenly evil.example is free to
intercept saint.example's traffic.

The many-to-one mapping from DNS domain names to IP addresses,
makes it unsafe to derive IPSEC keys from "forward" domain names.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 13:10:01 -0500

> 	https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02

You need to explain a lot of details about how the PAD, SPD, and SAD are
manipulated to obtain secure behavior.

In particular, simply adding PAD entries (with the IPSECA keys)
identified by IP address (so that traditional IPsec implementations just
work) would result in a catastrophic security failure: each zone
answering forward A & IPSECA lookups could give you their keys for
someone else's IP address!

You don't mention the PAD nor the SAD, so I assume that you missed their
significance when reading RFC4301.

You really need to study the IPsec architecture [RFC4301] closely and
carefully.  Also, any work like this absolutely needs review from
whatever WG has IPsec as its remit.

What you need to do is state that the client must follow a sequence of
steps like this[*]:

0. Lookup the peer's IP address and IPSECA RRs by forward name
1. insert a PAD entry identified by the peer's FQDN (NOT IP address!)
2. request an IKE_SA between the local and remote peer
3. atomically obtain/lock a 5-tuple (with that peer) not currently in
   use by other processes/sockets on the system
4. setup a *narrow* SA pair for that 5-tuple, and insert the SA pair
   into the SAD
5. add narrow entries to the SPD for that 5-tuple to PROTECT
6. connect() your socket (even with UDP, of course)

7. use the connected socket

8. tear down the socket, SPD and SAD entries; the PAD entry can stay as
   long as the RR's TTL says.

Or something along those lines.

That's just the conceptual part.  Then you need to figure out how
applications will cause this dance to happen -- the API.  Perhaps you'll
need to add a socket option for requesting the use of IPsec with narrow
SA pairs and a specific peer ID and public keys.

Without a socket option for this (or a pseudo address family that
relieves applications of the need to do DNS lookups) the most likely API
scenario (perhaps for a PoC) would be that the application must use
PF_KEY to talk to the IKE daemon to get it to do a lot of the above
sequence of steps.  But then you have to worry about how to tear down
state when the application crashes.

Once you have a proof of concept you need to test that it does not fall
to the attack described above.  Setup two forward names pointing to the
same IP address and with different public keys, then race clients and
show that they always get their traffic protected by SAs with the
correct peer ID.  In particular, the peer should not have the private
keys for the "attacker"'s name, and so clients trying to speak to the
attacker always fail.

[*] This is a suggestion as a starting point, and to illustrate the
    complexities involved.  I only just thought that up in a few
    minutes; there could be mistakes there too.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 13:16:46 -0500

I do not support inclusion of this work item in this WG.

The DANE-ish aspects of this work are much simpler than the IPsec ones.

I will support inclusion of this work in an IPsec-specific WG (IPsecme,
or perhaps HIP) when a new version of the individual submission I-D is
submitted that addresses the substantive comments I just posted.  Even
then, review from this WG would be a good idea.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 14:29:59 -0400 (EDT)

> We’ve been working on a couple of different flavors of implementation.  We’re hoping to push those out soon too and it’s already benefited from a great deal of discussion here, and we believe it’s…

TL;DR - This document makes a straight copy of the TLSA record and
         assumes host based IKE/IPsec works like application based TLS.
         It handwaves the IKE protocol and isn't clear why it is limiting
         itself to DNS, or what DNS traffic it wants to protect or how it
         could ever do a secure bootstrap. It still does not support
         NAT'ed clients or (DNS) servers and does not explain the AUTH
         and ID payload that the client is supposed to send during IKE.
         It does not explain what traffic selectors are used on the IPsec
         SAs. It provides no defense against DOS attacks. It suffers from
         a great disconnect with the IPsecME Working Group. I do not
         support adopting this document.

I have reviewed this document before and most of my concerns still
stand:

https://www.ietf.org/mail-archive/web/dane/current/msg06436.html

It's good to see that my conversation with Eric resulted in the removal
of the insecure gateway option. But more serious fundamental problems
remain in this draft. Specifically:

1) Limiting the scope of IPsec protection using DANE to only one
    protocol or one application makes no sense in an IPsec context.

2) This draft is not sure if it wants to be generic (IPSECA vs
    IPSECDNSA) or specific (IPSECA on _53.* == IPSECDNSA)

3) If you want to protect DNS using IPsec, just use an IPsec
    host-to-host tunnel and have the DNS server filter port <> 53.
    That allows for this method to be usable for endusers with the
    technical knowledge of watching netflix on any currently deployed
    device (iphone, android, windows, OSX, Linux, etc without needing any
    new RFC or patents. Google could use publish an IPSECKEY with "."
    gateway in the reverse of 8.8.8.8 and the forward of dns.google.com.

4) _53.example.com makes no sense. Is this UDP, TCP or both. Are traffic
    selectors in use? Are you aware traffic selectors cannot have 2
    protocols and that you will end up requiring multiple child SA's?

5) IPSECA is basically the same as the TLSA record. It incorrectly
    assumes that X.509 is the only method of authentication desired.

6) It takes about "interaction" with the SPD without understanding or
    specification. It does not clarify what the IKE daemon is supposed to
    do - or if it intends to extend the PF_KEY API.

7) Hoes does this document support the clients remaining anonymous? It
    fails to specify the IKE negotiation and AUTH and ID payloads involved.

Section 1.1

    "This can be especially complicated
    if different IPsec certificates need to be discovered for different
    services that are running on the same IP address."

What is an "IPsec certificate"?  Why do you need more than one?
What AUTH method does the client use to (not) identify itself?
How are traffic selectors negotiated? ANY to 53 ?

    "This can become
    complicated if certificates are learned solely by the IP addresses of
    networked-services. "

    [and all of section 1.2]

dns.google.com. IN IPSECKEY ......

This section, which is the justification of this document is based on
the misconception that public IPsec keys can currently only be discovered
by IP address.

    "The advantages of using DANE for IPsec OE "

What is "DANE for IPsec OE" ? I guess OE means Opportunistic Encryption.
Note the lack of "for DNS" in the description here. Are we talking about
DNS or generic _XXX.example.com protection?

    "Such as, the automatic deauthorization of certificates
     that happens when they are removed from a DNS zone"

There is no text describing what clients should do once they learned
this certificate from DNS and connect. Isn't it valid until its X.509
signature if certain Usage Types that include PKIX validation are used?

Section 1.3:

    "using a specific key exchange protocol, like [RFC2409], [RFC5996], etc."

RFC2409 is suggesting using IKEv1. IKEv1 has been obsoleted by IKEv2
since RFC 4305 in 2005. The IPsecME WG has a very strict policy that
no new documents related to IKEv1 be published. (again this illustrates
the disconnect of the authors of this document and the IPsecME WG)

    "when it receives a referral it SHOULD query name servers for
    corresponding IPSECA resource records."

What is "receives a referral" ? Is this suggesting the client
implementing this document attempts to talk IPsec to every new NS record
target it receives? Or is it meant to talk about a DHCP Nameserver
option? The end of the document suddenly talks about protecting
authoritative servers in the example section, so I think it means when
it receives a delegation via NS. If so, how will it find IPSECA records
_to_ that server without first talking to that server in the clear? Is
this record support to live in the parent like the DS record? If not,
how does the DNS server and IKE/IPsec server interact when the record is
received to kick start the IPsec encryption? And how does a new query
get handled when the IPSECA record expired from the local cache?

    "that resolver SHOULD follow its configurations and setup an SPD entry,"

This is really just handwaving, "and it should do some IPsec magic".
This really needs to say what IKE parameters are being negotiated and
what outcome is expected. And what to do when the IKE negotiation
fails and what to do during IKE negotiation and how the DNS server and
IKE server can possibly coordinate these actions.

    "Note, this document does not specify a new, or any modifications
     to any existing, IPsec key exchange protocols."

    "Rather, after adding an SPD and after a
    successful tunnel establishment, the credentials used for the
    Security Association with the name server SHOULD be cross-checked
    with the IPSECA resource record(s)."

First of all, one does not "add an SPD entry". Second of all, if you
reach the point in the IKE protocol where you update the SPD/SAD
database, it means the kernel is told to encrypt/decrypt packets. That
is, the IPsec tunnel is fully up and running. There is no more IKE
to be done. Saying one should THEN cross-check the X.509 AUTH payloads
of IKE is completely invalid AND a serious breach of the IKE protocol.

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

If using IPsec fails, the DNS client is going to send cleartext packets
anyway. Wouldn't a non-DNSSEC IPSECA record provide more privacy than
just defaulting to clear? [Hint, read draft-ipsecme-ikev2--auth-null
and RFC 7435]

       "certificate association for [IPsec]"

       "If the DNSSEC validation state on the response to the request for
       the [IPSECA] RRSet is bogus, this MUST cause IPsec not to be
       started or, if the IPsec negotiation is already in progress, MUST
       cause the connection to be aborted."

The use of "certificate association for [IPsec]", "IPsec not to be
started" and "IPsec negotiation" again shows the workings of IKE versus
IPsec are not understood.

       "Trust anchors (which may be distributed during dynamic host configuration)"

I guess that would be a whole set of RFC's in itself. How can one
securely obtain trust anchors via DHCP? Because the DNSOPS and HOMENET
people would also love to get that going.

    "The intuition behind this reasons
    that if the first (configuration) step was already where the local
    resolver was configured, then the security of the DNS transactions
    already hinged on learning the valid resolver this way.  "

Here, the document suggest that after describing all these security
MUST's related to DNSSEC, the whole chain of trust starts with a
completely insecure DHCP packet. Again, you might as well just do
draft-ipsecme-ikev2--auth-null at that point. This undermines all the
previous security requirements required in this section.

    "So, this
    step is already used to convey trusted configurations
    (bootstrapping)."

Uhm no. No one has ever claimed DHCP is "trusted".

    "Adversaries attempting to subvert an end host have
    only the narrow attack window that is associated with learning
    configurations. "

Uhm no. And even so..

Section 2

    "The IPSECA resource record is modeled heavily off of the IPSECKEY RR"

That is no longer true with the removal of the gateway option. The only
things left now are TLSA items. In fact, it's now identical to a TLSA
record and the new IANA registry created by this document would also
be an unnecessary duplication.

Section 2.1

References to ietf-dane-registry-acronyms should be updated to be RFC 7218

Section 2.2

This does not show the presentation format. Note that there is not even
a section describing the wire format.

Section 2.3

See above regarding completely missing the traffic selectors and multiple Child SA's
issues.

Section 2.4:

    "They MAY
    be used in verifying Security Associations, but a protocol to do this
    is beyond the scope of this document."

I do not understand what is being said here.

Section 2.4.1:

    Suppose a DNS zone example.com is served by the name servers
    ns1.example.com and ns2.example.com.  If the zone operators want to
    advertise their willingness to offer OE to their name servers using
    IKEv2 [RFC5996], then the following domain names MUST be placed under
    the example.com zone

Ok, so now out of nowhere we are talking about Authoritative Servers,
and not recursive ones. That would require its own section with a very
important component on security and how to prevent DOS attacks. Not
only that, note the "under". To talk securely to ns1.nohats.ca, you need
to talk insecurely to ns1.nohats.ca to get the IPSECA record, where upon
you will get almost all records related to nohats.ca in the clear. In
other words, by the time your tunnel is setup, 90% of the DNS traffic
has already happened in clear text. (Unless you want to put the IPSECA
record in the parent zone like the DS record - if you want to do that,
you'll have to go to dnsops)

    This example illustrates how a zone MAY indicate where an SPD entry
    and SA establishment endpoints exist for its name servers (note, they
    are not required to be the name servers themselves).

So if these are not the nameservers themselves, where do I send the port
53 query to? This is probably an artifact of the now removed gateway
option.

    "the IPsec certificate"

IPsec has no certificates. You mean IKE.

Section 3

First of all, this section completely misses the bootstrap issue or how
one is to lookup IPSECA records if one is trying to setup IPsec to its
only DNS server.

        If a resolver enables OE, but no (or relatively few) name servers
        provision IPSECA records, then no IPsec tunnels will be
        established, and the load will remain static (or marginally
        increase).

This is a weird statement. "If we are not successful in deploying this
as a standard, there will be no scalability issues"

        If an authoritative name server provisions IPSECA record, it will
        only result in additional load if querying resolvers are
        configured to attempt OE.

And again. "If nothing bad happens and we don't deploy much, we're good".

        Using white-listing techniques (such as those used during pilot
        deployments of AAAA records) would allow authoritative name
        servers to only return IPSECA responses to clients that have been
        white-listed.

Hoes does that work when the zones are (as is mandated by this document)
DNSSEC signed? You would be returning BOGUS results or need to have two
signed zones to return signed answers. Which any attacker could then
replay to the user to force them onto the clear text version of DNS.

This section is completely missing the actual DOS and load issues that
can be expected to happen.

Section 4

    Any future use or modification of an IANA registry for that resource
    record will have similar effects on this resource record.

This only shows again that this document should not be defining IPSECA
which is just a copy of TLSA.

Section 5

This section does not actually address the real concerns. It does not
talk about fallback to clear versus hard fail. It does not talk about
handling thousands of IKE SAs and IPsec SAs.

Conclusion

As I stated to the dane chairs before and again during yesterday's
meeting, there are IPsec people working on updating/replacing the IPSECKEY
RFC. However, proper implementation runs into various complicated issues,
mostly related to NAT and failure modes, that the authors of this draft
have not addressed - and frankly needs a lot of discussion in the IPsecME
working group and not so much in the DANE working group. There are good
reasons the Libreswan Project has been working on this for a few months
_without_ submitting a draft.

For example, as part of moving towards an actual real solution, the
libreswan IPsec team submitted the following draft to the IPsecME WG:

https://tools.ietf.org/html/draft-antony-ipsecme-oppo-nat-00

The split of IKE and IPsec and the fact that applications are not
necessarily aware of the security of the transport when IPsec is used
makes me think that work for this belongs much more in the IPsecME WG
than in the DANE WG. This draft is clearly written by people that lack
enough understanding of IKE and IPsec.

Creating a solution for IPsec that only protects DNS makes no sense. IKE
and IPsec is not application level based, but host based. Additionally,
this document mixes up authoritative and recursive DNS server
protection, resulting in something that works for neither.

Having been heavily involved in IPsec and DNSSEC for the last 15
years within the IETF and the opensource community in general, I do not
appreciate the author's inappropriate joking about patents to me in the
hallway - especially when this document gives the appearance of being just
a quick attempt at justifying a pending patent, instead of the authors
actually talking to the IPsec community in an attempt to write something
that is actually deployable and secure.

I do not support adopting this document.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 14:38:27 -0400 (EDT)

> intercept saint.example's traffic.

Actually, you cannot intercept the traffic. Assuming the real IKE daemon
on 192.0.2.1 is configured with the "saint key", the client will see
that the server fails authentication. But this does provide a
denial of service against both the client and the saint server. And if
the client would fail to clear based on evil.example, than it could
potentially cause all saint traffic to end up in the clear as wel.

Paul

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 25 Mar 2015 23:58:59 +0000

Paul, Nico, and Jim,

Thank you all, very much, for your detailed feedback on the IPSECA draft.  The draft authors and I have met and are preparing a very major overhaul of the current text and our related prototypes.  We are addressing the excellent comments and will have the -03 version out within four weeks.

Thanks again for the feedback!

Eric

On Mar 25, 2015, at 1:29 PM, Paul Wouters <[email-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 18:59:19 -0500

Also, it appears that part of the motivation for this is to provide
confidentiality protection to DNS.  The DPRIVE WG is chartered to work
on confidentiality protection for DNS queries and responses:
http://datatracker.ietf.org/wg/dprive/documents/

Any IPsec-based proposals for DNS confidentiality would seem to belong
in DPRIVE WG, not DANE WG.  DPRIVE's approach seems to be: secure the
stub resolver to recursive resolver connection.  IPsec fits in that
approach, and all that's needed is traditional IPsec configuration
learned from DHCP or DHCP plus DNS.  Even then, implementation-wise it's
much easier to use TLS[0] as all the current proposals in DPRIVE WG do.

For other use cases, IPSECA would only help if it were utterly trivial
to use, and -better yet- if it could just be used automatically.  But
the latter is non-trivial: existing applications use connect() and they
don't tell it the name of the server they want to connect to, only an IP
address.  ISTR hearing someone say that "hey, the system could match
lookups to connects", but I don't believe that's a good idea.  So you
can't have this just happen; new APIs would be required, full stop.

[0] Because using IPsec from applications is just ETOOHARD, even for
    system applications like a name services daemon.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Mar 2015 21:58:19 -0400 (EDT)

On Wed, 25 Mar 2015, Nico Williams wrote:

> learned from DHCP or DHCP plus DNS.

You can already connect using Opportunistic IPsec to oe.libreswan.org
using AUTH_NULL, which is as secure as trusting a random key from a
random dhcp server.

I've added a DNS resolver on it, which is open to anyone that connects
with AUTH_NULL IKE/IPsec.

Paul