Re: [dane] IPSECA
Paul Wouters <paul@nohats.ca> Wed, 25 March 2015 18:38 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F1E1B2A07 for <dane@ietfa.amsl.com>; Wed, 25 Mar 2015 11:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byMl1nY6QNF1 for <dane@ietfa.amsl.com>; Wed, 25 Mar 2015 11:38:23 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE9A1B2A10 for <dane@ietf.org>; Wed, 25 Mar 2015 11:38:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lByr70HV3zGXC for <dane@ietf.org>; Wed, 25 Mar 2015 19:38:15 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=lT+tGWEB
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id o8xQNNcW_Ms7 for <dane@ietf.org>; Wed, 25 Mar 2015 19:38:13 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dane@ietf.org>; Wed, 25 Mar 2015 19:38:12 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8956B803E0 for <dane@ietf.org>; Wed, 25 Mar 2015 14:30:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427308200; bh=wQR/n7G///vNcZ4tsQamMoW8pwx89ZFGVW6erKX4Q2A=; h=Date:From:To:Subject:In-Reply-To:References; b=lT+tGWEBK8DEiEah5XSvV/opGd3X4p4V9xhtc0+3AAlhG2E8h4Tbd+VkxjwkkLI91 /XuAqJDWXoT4EeRbr9fTrWrunlSI1zP/49AUs6epJTvPQqZoqAWrY5HeKDf1pIe/AK BP4v9eyvr2Rb3d5y9qEG8tBHH8V+g+IGkNTvVKuE=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2PITxoK011145 for <dane@ietf.org>; Wed, 25 Mar 2015 14:30:00 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 25 Mar 2015 14:29:59 -0400
From: Paul Wouters <paul@nohats.ca>
To: dane WG list <dane@ietf.org>
In-Reply-To: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com>
Message-ID: <alpine.LFD.2.10.1503251223330.22291@bofh.nohats.ca>
References: <9735F7C2-D87A-4A33-9302-49C54A644EDA@verisign.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/SHY5DVtDyNeBaoxXz7USu2xZ2yM>
Subject: Re: [dane] IPSECA
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 18:38:26 -0000
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] IPSECA Osterweil, Eric
- Re: [dane] IPSECA James Cloos
- Re: [dane] IPSECA Osterweil, Eric
- Re: [dane] IPSECA Viktor Dukhovni
- Re: [dane] IPSECA Nico Williams
- Re: [dane] IPSECA Nico Williams
- Re: [dane] IPSECA Paul Wouters
- Re: [dane] IPSECA Paul Wouters
- Re: [dane] IPSECA Osterweil, Eric
- Re: [dane] IPSECA Nico Williams
- Re: [dane] IPSECA Paul Wouters