Re: [dane] IPSECA

["Osterweil, Eric" <[e-mail]>]

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 <[e-mail]> wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane