On Tue, 24 Mar 2015, 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:
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.
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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
