From nobody Thu Aug 4 03:31:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4FB12DA09 for ; Thu, 4 Aug 2016 03:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 XLiw2xPHpVvD for ; Thu, 4 Aug 2016 03:31:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD5312D9F3 for ; Thu, 4 Aug 2016 03:31:30 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u74AVP05013299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Aug 2016 13:31:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u74AVPH0025399; Thu, 4 Aug 2016 13:31:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22435.6525.41734.580296@fireball.acr.fi> Date: Thu, 4 Aug 2016 13:31:25 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Cc: Kathleen Moriarty Subject: [IPsec] IPsecME status update 2016-08-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 10:31:33 -0000 Here is the current status of the IPsecME WG as I see it as WG chair. ---------------------------------------------------------------------- Charter update New version posted to list 2016-07-20, no objection in list, should go forward. Document Status: - draft-ietf-ipsecme-ddos-protection WGLC should be done, ready to go forward. - draft-ietf-ipsecme-rfc4307bis Should be ready for WGLC, new version with changes agreed in meeting done. - draft-mglt-ipsecme-rfc7321bis New version posted what should align with 4307bis. This is agreed item on the charter, so we should do adoptation call for this document to be WG document. - draft-ietf-ipsecme-safecurves Document expired. Waiting for new version (either justs to refresh it, or fix the nists posted to list), and then it should be ready to start WGLC. - draft-nir-ipsecme-eddsa I think this is still waiting for the curdle to decide for OID, but we could start WG adaptation call, as this is now in our charter, and this is good starting point. - draft-ietf-ipsecme-tcp-encaps This should also be ready for WGLC. New work: - Quantum Resistance We need to start discussion about the requirements and then when we have those decided on the list, we should adopt document. - draft-pauly-ipsecme-split-dns This was accepted as charter item, but need few more reviews before taking it as WG draft. - draft-mglt-ipsecme-implicit-iv This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. -- kivinen@iki.fi From nobody Thu Aug 4 09:57:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C1A12DA9C for ; Thu, 4 Aug 2016 09:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 vWDetpe0waK8 for ; Thu, 4 Aug 2016 09:57:42 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8D712DA9F for ; Thu, 4 Aug 2016 09:57:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3s4x2667MjzBb; Thu, 4 Aug 2016 18:57:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1470329854; bh=wvBVcKm3KrV0FF+R6Uz1JopkLWpKUWV/P0/4eLLjxP0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LvCmuZ5sWyZ2ZUyS7sHV5Y0go0u3qPatE45k3XtCMktoPeKOWVjgpFqrQkOARaA3j Tl/bgnHW9MGlDOAQflJPOtkevDEyqizT09nBiH6VvdseyB6j5+4n/T8RcDy2ODUwxr LPBEDTLwB2srLZ3gZ/94W+N/Xx27T+CdsAP4wjYg= 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 aKr6R7PZejNH; Thu, 4 Aug 2016 18:57:33 +0200 (CEST) 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; Thu, 4 Aug 2016 18:57:33 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4904292D; Thu, 4 Aug 2016 12:57:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4904292D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 34A5440D7294; Thu, 4 Aug 2016 12:57:32 -0400 (EDT) Date: Thu, 4 Aug 2016 12:57:32 -0400 (EDT) From: Paul Wouters To: Tommy Pauly , Daniel Migault In-Reply-To: Message-ID: References: <82CD09B9-5B50-4C36-9390-A0DF4C303E2E@nohats.ca> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] review of draft-pauly-ipsecme-split-dns-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 16:57:45 -0000 Daniel, Thanks for the review. We will pickup the reported nits and textual clarifications. See comments below on some of your protocol questions. > > I think the motivation should be better exposed. The reason > > you need the options are: > >    - 1) When you have multiple interface to be able to define > >         for which domain name the DNS query MUST be sent to internal resolver. I don't think the protocol depends on "interfaces", so I would avoid adding that now. It is all about "views", and changing the view. > > Note, that the architecture implies that my resolution goes through > > the internal resolver. In other words, the mobile cannot have a > >  resolver that directly queries the authoritative servers. Maybe that > > would be good the NS are also provided by a INTERNAL_NS_DOMAIN It can do that if it wants to, by using the supplied resolver. But the way a mobile works is by adding "forwarders" for certain DNS domains. I do not see why it would need to insist on talking to the authoritative internal DNS servers? so unless he can come up with a real use case why that would be needed, I would not want to add INTERNAL_NS_DOMAIN. > 3.  Protocol Exchange > > > MGLT: I think the section is missing text that provides an > > overview of the protocol. > > The purpose of the information exchanged between the VPN > > client and the gateway are expected to provide the necessary > > information so the VPN client be informed properly of the > > domains that resolve differently internally than externally. > > In addition, some extra material should be provided so the > > resolution can appropriately be performed. I think that belongs in the introduction, and should not be repeated in Ssection 3 that specifies the protocol. > > MGLT: My understanding is that INTERNAL_IP4_DNS and INTERNAL_IP6_DNS > > only concerns the resolution. As resolution could be performed through > > the resolvers as well as by the client I would treat this aspect and > > the recommendations a separate section. The resolution could be for > > example performed by a resolver on the client in which case NS > > records may be requested by the client. See above. The protocol hands over all the information needed to resolve securely. If the client wants to satisfy its curiosity about where the authoritative DNS servers are, it can ask the provided forwarding DNS server. > > MGLT: Maybe that would be good to have a INTERNAL_NS attribute. Again, I dont see a use case for it. > > Also one domain name may have multiple TA, I think it would be > > wiser to be able to have multiple TA payload associated to one > > domain. The TA format includes the domain it applies for already, so there is no reason to complicate things by creating more associations or dependencies between the payload options. > > MGLT: I think that is better to use the wire format than the string format. As explains in another thread on the list, that just complicates sending this information down to a locally running DNS server. None of the current ones take DNS wireformat for on-the-fly reconfiguration. However, they do take DNS presentation format. Also, for instance if you look at the libreswan implementation, this data is passed into the connection handler via environment variables, so libreswan would have to convert the DNS wire format to DNS presentation format before giving it to the handler for DNS reconfiguration. > > I do not understand why the TTL is ignored. I also think that > > would be important in case of KSK roll-over. The TTL is ignored because this is an administrative reconfiguration. Just like a DNS server loading trust anchors from a file, there is no TTL to that file-based information either. If the zone does a KSK roll without updating the IPsec server, it is an administrative error. Possibly, the IPsec server could have code that reads the KSK's hourly and auto-updates what it gives to its clients, but that would all be implementation specific and I don't think this document needs to specify that. > > Maybe some text could mention that multiple TA can be added > > especially during the key roll over. Sure, if that is not obvious we can do that. > > In addition, I think additional text shoudl be provided to clarify > > what ar ethe advanatges of using a DS reccord. In fact providing > > the KSK in stead of the DS prevent teh client to request the KSK.... > > so it seems the KSK will anyway be transmitted. Trust anchors for DNS servers tend to be specified using DS records, or "DS or DNSKEY" records. So DS was the common denominator. Additionally, a DS blob is much smaller than a DNSKEY blob. I had asked at the last IETF if DNS vendors prefered one of the other, since getting a DS means they need to fetch the DNSKEY (insecurely) and then confirm it matches the DS record supplied, and they said DS was fine for them. (I talked to unbound, knot and bind people) >    For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client >    SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS >    servers as the only resolvers for the listed domains and its sub- >    domains and it SHOULD NOT attempt to resolve the provided DNS domains >    using its external DNS servers. >    > > MGLT: This may come with some privacy issues. So I would rather > > let the client chose if the domain is in relation with an internal > > resolution. That can use some rewording. Note there are different use cases. Obviously, we don't want VPN provider FOO to ask for all google.com queries when the VPN client connects to it only for FOO services. But we also want to give university BAR a chance to hand out a list of their own custom domains that the VPN client does not know about beforehand. >    If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes, >    the client SHOULD configure its DNS resolver to resolve those domains >    and all their subdomains using only the DNS resolver(s) listed in >    that CFG_REPLY message.  If those resolvers fail, those names SHOULD >    NOT be resolved using any other DNS resolvers.  All other domain > >    names MUST be resolved using some other external DNS resolver(s), >    configured independently, and SHOULD NOT be sent to the internal DNS >    resolver(s) listed in that CFG_REPLY message.  For example, if the >    INTERNAL_DNS_DOMAIN attribute specifies "example.com", then >    "example.com", "www.example.com" and "mail.eng.example.com" MUST be >    resolved using the internal DNS resolver(s), but "anotherexample.com" >    and "ample.com" MUST be resolved using the system's external DNS >    resolver(s). > > > MGLT: Unless i am missing some point I would rather mention this as a > > SHOULD. This appears to me more a policy. Well, the idea here is that you will not be able to resolve that resource unless you accept DNS server for it. If you say SHOULD instead of MUST, it means you are going to fail to resolve the internal resource. As for using the internal DNS for more than advertised, if the internal DNS server is okay with resolving everything, it could send the value ".". We could clarify that explicitly. One risk of using an internal DNS for a public DNS name is that the client can be tricked into revealing that it has a VPN connection option to VPN provider FOO by giving it a unique tracking DNS entry to lookup. So unless the VPN provider instructs clients to use it for ALL DNS, I think the advise of MUST is good. Paul From nobody Thu Aug 4 14:56:17 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A74CC12DB1C; Thu, 4 Aug 2016 14:56:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804215615.15820.73050.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 14:56:15 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 21:56:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Curve25519 and Curve448 for IKEv2 Key Agreement Authors : Yoav Nir Simon Josefsson Filename : draft-ietf-ipsecme-safecurves-02.txt Pages : 7 Date : 2016-08-04 Abstract: This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 15:07:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB1612D9ED for ; Thu, 4 Aug 2016 15:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ptqTjE-PIzrZ for ; Thu, 4 Aug 2016 15:07:30 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01ABC12D863 for ; Thu, 4 Aug 2016 15:07:29 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id p129so4768620wmp.0 for ; Thu, 04 Aug 2016 15:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ajycsyxbYdib/wSJQcY9gg45/DW8aaLkh/5ZmtsDZJs=; b=kDM/DBR/dCZYbhIc5l/83sUExLYhEcDdU9bWyHpxlULV+JtZx5spVMW4CS/A9n1bmT 31hRG/KScMtZtmmjerzmEJgsESabrj8vE2ziHfb9zuGYQ8mD+SFBhY7WwnkiM1FTrnmJ MY+yq8/y6jHkt6D/woMdaQvy7fiEn6Dhq9ypC0gyH5jgBFl4hTCtX/cvpouC+8qVRvuq ZB41ErMWWQvlDdMo7mUvYji0fkYBHTerxyUMIytguo15mm/BXnpSRY0UwryBOJcXej9Q zf/QHaxK9i6A8MubQeKVLI+DYwQqPMWLdIpnKEMv/IHIf5FsRwCPqj+xSWxBbCMabnQg cqHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ajycsyxbYdib/wSJQcY9gg45/DW8aaLkh/5ZmtsDZJs=; b=HFhr7QVCd4q+4EQhU2tXY0WTJ85yLlpKM6/DVZa49VlEjxgQqLvtH4MFRLw4IVJjo+ nmYLmBtFP5IClLvAWiPafaBm7ytZpBDabTKNoELySQ8ui3/XgDUFOaH8IBe6b9ivFHEP n7qD/HjBfhZ/GhWVha6BQQN2X8Y0Wsl5hQjZ1WDD7w1YkLtqru9ycZKKgptIIW1GRvma HkC7++1yqhXJigzBEz0DMBzMVtPyn1jZC1wlsMfDOANxPtz5Fql6+pH4eLK96kCzKt+3 oYIhiBuZcKf8sRbOJW059vunpIfvcj+a4LIp+icBd6k5x4j4bl0VIkeNWo7+VFdRGnbS S+mg== X-Gm-Message-State: AEkoouuVCcFkxo/6JffKGfvduztAIz64od6eM9ZVbXVDER55E7EfZN0BW8QwcC1NFD/UZg== X-Received: by 10.28.165.3 with SMTP id o3mr176741wme.3.1470348448183; Thu, 04 Aug 2016 15:07:28 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id vv2sm3462156wjc.29.2016.08.04.15.07.27 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 15:07:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <20160804215615.15820.73050.idtracker@ietfa.amsl.com> Date: Fri, 5 Aug 2016 01:07:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <28861B29-3DA6-43E7-8798-FD8CC7F51341@gmail.com> References: <20160804215615.15820.73050.idtracker@ietfa.amsl.com> To: IPsecME WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 22:07:33 -0000 Hi. New in this version: - A few textual changes in the Introduction (suggested by Tero) - Numerical example in Appendix A for Curve25519. I used OpenSSL code to generate the example. I didn=E2=80=99t find = similar code for Curve448. Hopefully I will be able to fill this gap = before publication. Currently OpenSSL does not support this, but there = is an open issue ([1]). Yoav [1] https://github.com/openssl/openssl/issues/1398 > On 5 Aug 2016, at 12:56 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions of the IETF. >=20 > Title : Curve25519 and Curve448 for IKEv2 Key = Agreement > Authors : Yoav Nir > Simon Josefsson > Filename : draft-ietf-ipsecme-safecurves-02.txt > Pages : 7 > Date : 2016-08-04 >=20 > Abstract: > This document describes the use of Curve25519 and Curve448 for > ephemeral key exchange in the Internet Key Exchange (IKEv2) = protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-safecurves-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Aug 4 20:45:48 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A608312D873; Thu, 4 Aug 2016 20:45:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 20:45:43 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 03:45:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Filename : draft-fluhrer-qr-ikev2-02.txt Pages : 12 Date : 2016-08-04 Abstract: This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 5 00:49:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1207912D563 for ; Fri, 5 Aug 2016 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EdVuvO-GhCTj for ; Fri, 5 Aug 2016 00:49:30 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DEF12B036 for ; Fri, 5 Aug 2016 00:49:30 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id q128so20876586wma.1 for ; Fri, 05 Aug 2016 00:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0tOEnIWgtGdxX5KoPyMR4mTlh3G0YUijufcMwwtHcFc=; b=YaWyC/uNoyRl1/VaFDPNPSj7smUvm+nCci6mMLzG74IPmUWQprP3uMAul/wFXyzbwh vamGIzeBU6a/aY6brHcSmUMAepnblvVZ/AUpYYUAo+OtPnjLZxeR8S6XRfJe625qbBEn iZoilIMaMspEc6My6CpMmMBXe2GZLqO9zGmD9UZULDJTIo/WftqVD4KWjc4PFVG7CGlb dsMuuOGO/vr0+mIdQWt5HIVSe8hsDHQAWISj/OSFeKNLl911c9V8/jBX8B0aZ4yV7xqc gSuWpF6CSPw0q65jy7WxQ9YZbssxN7LDUPTtmrI4fdQEwap44kP1PHrmzvSt3K/7EP+0 EHdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0tOEnIWgtGdxX5KoPyMR4mTlh3G0YUijufcMwwtHcFc=; b=hACAowKjZEoMCRj3s4nUrqpJR4LI0zbOPC+aPp0IE1CPVjTH+i1Pa3SnCmhylleysq 3+aC+R1gMF4C70oZo4F+ZHk3hWdGiE3FEVLVtv8JvmESur5hy8Q0kXI7ira3QCI1nCvV EfJpkgMoc9RcOsVD5M+NhNFIaeLF5G2hgSiMuytA37nlgEAHXp5Le3nHRMJMjltIlW3n dSkBBub+XfBGUM2Ef9tkdhAqgWy1ix1bz5BpfxXte5WPWmehMTpcRTuMqxybcJXmSKlU ch5YqgHSDFvqcOEpMlKLJjAx9M2gtLCaqTlte1dnnP0EfpyloEqH35ev01AKPxcN6cXt FItw== X-Gm-Message-State: AEkoout90CUPRP9ux7cdLKQCXz6St7VSUreJjPUU77Atj53uwjwKtQCx6zuRzistQwhlSQ== X-Received: by 10.194.11.102 with SMTP id p6mr69600885wjb.104.1470383368482; Fri, 05 Aug 2016 00:49:28 -0700 (PDT) Received: from [10.0.0.12] (bzq-79-179-150-16.red.bezeqint.net. [79.179.150.16]) by smtp.gmail.com with ESMTPSA id a194sm7276549wmd.24.2016.08.05.00.49.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 00:49:27 -0700 (PDT) References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> To: "ipsec@ietf.org" From: Yaron Sheffer X-Forwarded-Message-Id: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 5 Aug 2016 10:49:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 07:49:32 -0000 Scott et al., It's not great to include a list of algorithms in a particular document, because it will quickly grow stale. I suggest to add something like: The preference of specific algorithms in IKE will likely change over time. Please consult [rfc4307bis] or its follow-on document for guidance on which algorithms are preferred and which need to be avoided. Thanks, Yaron -------- Forwarded Message -------- Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt Date: Thu, 04 Aug 2016 20:45:43 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipsec@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Filename : draft-fluhrer-qr-ikev2-02.txt Pages : 12 Date : 2016-08-04 Abstract: This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Aug 5 05:55:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1C312D5A8 for ; Fri, 5 Aug 2016 05:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Z3VlBrxQ6nqV for ; Fri, 5 Aug 2016 05:55:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A8B12D0BE for ; Fri, 5 Aug 2016 05:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3293; q=dns/txt; s=iport; t=1470401702; x=1471611302; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SvnDoEyO9PURheZwJrBFDloGR254mKIyq8cbsNb8R7E=; b=TvUbdzlccNGy6GQ14Iw8LwKTfGv8EHh3L5YC1ac8bj/Xf0jEtZHHn+t2 OtXcSyfUbpFpWoAsmb2MwzDvmg3lTTQUXIuTCcjC38oU319Y0NS1bybGi CAC/alI14WJobnvOPBGf4hKpo9O0TWh30QvW1GDAaVd4xVN1xY9LM0u/I w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgA+jKRX/5tdJa1cg0VWfAe5G4F9J?= =?us-ascii?q?IV5AoFKOBQBAQEBAQEBXSeEXgEBBAEBATg0FwQCAQgRAwEBAR8JBycLFAkIAgQ?= =?us-ascii?q?BEgiIIQgOvjQBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqDSoEDihsFmTUBhhyIZ?= =?us-ascii?q?IFyToQNiHyMM4N2AR42g3puhmZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,474,1464652800"; d="scan'208";a="306403627" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Aug 2016 12:54:58 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u75CswPd006309 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Aug 2016 12:54:58 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 5 Aug 2016 08:54:57 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Fri, 5 Aug 2016 08:54:57 -0400 From: "Scott Fluhrer (sfluhrer)" To: Yaron Sheffer , "ipsec@ietf.org" Thread-Topic: [IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt Thread-Index: AQHR7u3sSpt/LJdsWE2tAmSWW2Vp4KA6TvBQ Date: Fri, 5 Aug 2016 12:54:57 +0000 Message-ID: <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.224.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 12:55:04 -0000 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Friday, August 05, 2016 3:49 AM > To: ipsec@ietf.org > Subject: [IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt >=20 > Scott et al., >=20 > It's not great to include a list of algorithms in a particular document, = because > it will quickly grow stale. I suggest to add something like: >=20 > The preference of specific algorithms in IKE will likely change over time= . > Please consult [rfc4307bis] or its follow-on document for guidance on whi= ch > algorithms are preferred and which need to be avoided. The point of listing algorithms here is to list which ones are Quantum Safe= , and which are not, as that may not be obvious to an implementor. Pointin= g them to 4307bis isn't helpful, as it doesn't mention which ones are Quant= um Safe. Now, this draft is still fairly early (pending the discussion of requiremen= ts); it is quite unlikely that it will be accepted as-is. I agree that thi= s might not be the ultimate right spot for it; we might (say) amend 4307bis= to explicitly state which algorithm is QR or not (and also state that any = RFC that defines future algorithms will include their expected Quantum Resi= stance in the security considerations). However, until we have a landing s= pot for such information, I can't think of any place better than this draft= . >=20 > Thanks, > Yaron >=20 >=20 > -------- Forwarded Message -------- > Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt > Date: Thu, 04 Aug 2016 20:45:43 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipsec@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IP Security Maintenance and Extensions o= f the > IETF. >=20 > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Filename : draft-fluhrer-qr-ikev2-02.txt > Pages : 12 > Date : 2016-08-04 >=20 > Abstract: > This document describes an extension of IKEv2 to allow it to be > resistant to a Quantum Computer, by using preshared keys >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-fluhrer-qr-ikev2-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Aug 5 08:23:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A86212D541 for ; Fri, 5 Aug 2016 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FkLyn1s_p8t1 for ; Fri, 5 Aug 2016 08:23:34 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1024B12D53D for ; Fri, 5 Aug 2016 08:23:34 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id q128so35521823wma.1 for ; Fri, 05 Aug 2016 08:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=eIHlfyE6XViVaMu3YDMJMGG8zT7/X/r8oQxj+rAPWNI=; b=zD8hMW0+rlae0Rb6HRx360u1gawr4TYD2yxjv8RFWqveqzyeHSszHIrj0M4MpkzBYY sIPpH+KnCkojZ7ySVqdZ8lsNWU9jhrWjPYmgmYwm6DS42wu2UCgjlVJlnclOlvQJIydY 738gu1hN8C8JoMb3UxIIWSkqfR0akhIrTIx45Fl5IAYJsyc3OjM931XRbbdP9gkXPiPv 9X2HA28IorUj5AgdlwXI7DRSo3XroHCg0pkg1Fd1gNKAnYNcnRZCDFtV9T51g0zezSVX rrtXJPBuEk3A4LHt/ywjmKcy8J8GLWadzURxHDg/kDjxzOA4gcDnqkVouF5XPJtzmWI5 vlXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eIHlfyE6XViVaMu3YDMJMGG8zT7/X/r8oQxj+rAPWNI=; b=LcwApAmELC7DghVB3dyBcAj/AK2x6WJAKQ2wTYL6v896O30mwD2imc2I2qdGMVX9I8 30cKMMcGkDxk4GPIk+3cpxvIOEY2Q2Exj6PGDmhczAM9bQ0GmHXQdXDyCwEJXNP3hSs+ tn/lT0pCYHI0I0n4Anq0Aa6TUec0dioNXuPuWGUs9Q9nolTp+THkOMV0I9CkbSa1OPjJ A4AYRvJWSwG4fkYuEIxygmX1XJH/XQSxlOmSF0X4O0bmi1oXHIeqiGZZa0l/+Uo8NjMn 18OHfAr196Jia9t9Gl7VbafwOycj/HhB+Vx/PrDklJyf5dvBrLZotGS159bT7ZS3/xzk rnew== X-Gm-Message-State: AEkoouu/v2XgHd8hgQyFWZtKdBY4lRKdXKJgkzvSHLwN84ZK1VCKuLV5qihbOjt7LFrhIw== X-Received: by 10.194.144.33 with SMTP id sj1mr82896820wjb.150.1470410612347; Fri, 05 Aug 2016 08:23:32 -0700 (PDT) Received: from [10.0.0.12] (bzq-79-179-150-16.red.bezeqint.net. [79.179.150.16]) by smtp.gmail.com with ESMTPSA id ub8sm18325492wjc.39.2016.08.05.08.23.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 08:23:31 -0700 (PDT) To: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> From: Yaron Sheffer Message-ID: Date: Fri, 5 Aug 2016 18:23:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:23:36 -0000 On 05/08/16 15:54, Scott Fluhrer (sfluhrer) wrote: > >> -----Original Message----- From: IPsec >> [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: >> Friday, August 05, 2016 3:49 AM To: ipsec@ietf.org Subject: [IPsec] >> Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt >> >> Scott et al., >> >> It's not great to include a list of algorithms in a particular >> document, because it will quickly grow stale. I suggest to add >> something like: >> >> The preference of specific algorithms in IKE will likely change >> over time. Please consult [rfc4307bis] or its follow-on document >> for guidance on which algorithms are preferred and which need to be >> avoided. > > The point of listing algorithms here is to list which ones are > Quantum Safe, and which are not, as that may not be obvious to an > implementor. Pointing them to 4307bis isn't helpful, as it doesn't > mention which ones are Quantum Safe. > My point was that nominally QR-resistant algorithms might still get broken and be deprecated in 4307bis or maybe the next "bis". I guess my proposed text didn't make the point clearly enough. > Now, this draft is still fairly early (pending the discussion of > requirements); it is quite unlikely that it will be accepted as-is. > I agree that this might not be the ultimate right spot for it; we > might (say) amend 4307bis to explicitly state which algorithm is QR > or not (and also state that any RFC that defines future algorithms > will include their expected Quantum Resistance in the security > considerations). However, until we have a landing spot for such > information, I can't think of any place better than this draft. The trick to that is to add a new column to the IANA table https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 > >> >> Thanks, Yaron >> >> >> -------- Forwarded Message -------- Subject: [IPsec] I-D Action: >> draft-fluhrer-qr-ikev2-02.txt Date: Thu, 04 Aug 2016 20:45:43 >> -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: >> ipsec@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IP Security >> Maintenance and Extensions of the IETF. >> >> Title : Postquantum Preshared Keys for IKEv2 Authors >> : Scott Fluhrer David McGrew Panos Kampanakis Filename : >> draft-fluhrer-qr-ikev2-02.txt Pages : 12 Date >> : 2016-08-04 >> >> Abstract: This document describes an extension of IKEv2 to allow it >> to be resistant to a Quantum Computer, by using preshared keys >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ IPsec mailing list >> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ IPsec mailing list >> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Aug 5 08:42:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B7112D5CE for ; Fri, 5 Aug 2016 08:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 BQdX4jBBhChm for ; Fri, 5 Aug 2016 08:42:23 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAEE12D550 for ; Fri, 5 Aug 2016 08:42:23 -0700 (PDT) Received: from [10.32.60.123] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u75FgIFq074765 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 08:42:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.123] From: "Paul Hoffman" To: "Yaron Sheffer" Date: Fri, 05 Aug 2016 08:42:17 -0700 Message-ID: <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> In-Reply-To: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ipsec@ietf.org" , Scott Fluhrer Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:42:25 -0000 On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: > The trick to that is to add a new column to the IANA table > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtm= l#ikev2-parameters-5 That's the first of two tricks: the second is getting agreement about = the rules for the values in that column. It seems like there is still = disagreement in the crypto community about how susceptible different = algorithms and modes are to quantum. --Paul Hoffman From nobody Mon Aug 8 05:39:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDE512D5CF for ; Mon, 8 Aug 2016 05:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 1sCAuQIyRM2V for ; Mon, 8 Aug 2016 05:39:46 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BE112D5BE for ; Mon, 8 Aug 2016 05:39:44 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u78CdZUm020860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 15:39:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u78CdYTL021924; Mon, 8 Aug 2016 15:39:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22440.32133.870165.114680@fireball.acr.fi> Date: Mon, 8 Aug 2016 15:39:33 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <82CD09B9-5B50-4C36-9390-A0DF4C303E2E@nohats.ca> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 36 min X-Total-Time: 35 min Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Tommy Pauly Subject: Re: [IPsec] review of draft-pauly-ipsecme-split-dns-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 12:39:50 -0000 [not waring any hats] Paul Wouters writes: > As explains in another thread on the list, that just complicates sending > this information down to a locally running DNS server. None of the > current ones take DNS wireformat for on-the-fly reconfiguration. > However, they do take DNS presentation format. Also, for instance if > you look at the libreswan implementation, this data is passed into > the connection handler via environment variables, so libreswan would > have to convert the DNS wire format to DNS presentation format before > giving it to the handler for DNS reconfiguration. We are specifying the IKEv2 protocol extension, not really specifying how to pass the information forward. If some implementation is using environment variables, or command line options to pass this information forward I think some kind of binary format is better in IKEv2 than string format. Ifwe use string format the IKEv2 implementations might easily just pass the string forward without any checking, and this might cause security vulnerabilities like we had with shellshock or similar. If the input format is some kind of binary format, and the IKEv2 library then constructs the string format out of that it will remove ability to do that kind of attacks. With string formats we need to make sure that there is nothing dangerous in there ("$INCLUDE /etc/passwd" or "; `sh -c /sbin/reboot`") and we have to specify what kind of checking implementations should do on the format. Saying that the contents is DS RDATA wire format as specified in the RFC4034 section 5.1 would be much easier, and converting that to string representation is quite easy, as it is just 1 16-bit field, two 8-bit field, and then the digest: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There would not be need for the TTL, so that is not an issue, but on the other hand, we need the domain name, so perhaps the INTERNAL_DNS_DOMAIN would need to be as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | | +-+-+-+-+-+-+-+-+ | ~ Domain Name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm | Digest Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Digest ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the Name length tells the lengt of the domain name, and after that there is optional DS record information for that domain. Whether the Key Tag / Algorith / Digest Type is there after the Domain name is seen from the Length field and the Key Tag is followed immediately after Domain Name without any padding, and without the trailing dot, and the Domain Name is not null-terminated. If there is multiple DS records, then there would be multiple INTERNAL_DNS_DOMAIN records, with same or different domain name. I.e., in that case the example would be : CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS() INTERNAL_IP4_DNS() INTERNAL_DNS_DOMAIN(example.com) INTERNAL_DNS_DOMAIN(other.com) CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(198.51.100.234) INTERNAL_IP4_DNS(198.51.100.2) INTERNAL_IP4_DNS(198.51.100.4) INTERNAL_DNS_DOMAIN(example.com,31406,8,2, 0xF78CF3344F72137235098ECBBD08947C2C9001C7F6A085A17F518B5D8F6B916D) INTERNAL_DNS_DOMAIN(example.com,31589,8,1, 0x3490A6806D47F17A34C29E2CE80E8A999FFBE4BE) INTERNAL_DNS_DOMAIN(example.com,43547,8,1, 0xB6225AB2CC613E0DCA7962BDC2342EA4F1B56083) INTERNAL_DNS_DOMAIN(example.com,31406,8,1, 0x189968811E6EBA862DD6C209F75623D8D9ED9142) INTERNAL_DNS_DOMAIN(example.com,31589,8,2, 0xCDE0D742D6998AA554A92D890F8184C698CFAC8A26FA59875A990C03E576343C) INTERNAL_DNS_DOMAIN(example.com,43547,8,2, 0x615A64233543F66F44D68933625B17497C89A70E858ED76A2145997EDF96A918) INTERNAL_DNS_DOMAIN(city.other.com) with DS records given for example.com, but without DS records for city.other.com. > > > I do not understand why the TTL is ignored. I also think that > > > would be important in case of KSK roll-over. > > The TTL is ignored because this is an administrative reconfiguration. > Just like a DNS server loading trust anchors from a file, there is no > TTL to that file-based information either. > > If the zone does a KSK roll without updating the IPsec server, it is > an administrative error. Possibly, the IPsec server could have code > that reads the KSK's hourly and auto-updates what it gives to its > clients, but that would all be implementation specific and I don't > think this document needs to specify that. It is not enough for the IPsec server to fetch KSK, as the client might have fetched the TA information two months ago, when it connected to the SGW. It might have done several IKEv2 rekeys after that, but as it does configuration payloads only when it initially connects it will not get new configuration information ever. This might not be something that we actually need to fix here, it might be enough just to add some words about that, and say that if internal domain does KSK roll overs then the server might want to request clients to do reauthentication (RFC4478) while doing roll over so they will get new configuration information before the old one is removed. > Well, the idea here is that you will not be able to resolve that > resource unless you accept DNS server for it. If you say SHOULD instead > of MUST, it means you are going to fail to resolve the internal > resource. As for using the internal DNS for more than advertised, if the > internal DNS server is okay with resolving everything, it could send > the value ".". We could clarify that explicitly. Internal server might be willing to resolve everything, and even provide completely new DS for "." so you can do everything securely, but the user might be bit suprised to learn that his facebook.com requests go to the company dns server, and dnssec is happy with the faked results pointing to the companys internal facebook proxy that checks they do not post anything nasty about company to the facebook... So this is also security issue, i.e., how much configuration you should trust from the server. Bad server can send you bad configuration data, and client might want to limit the damage done by the bad server. -- kivinen@iki.fi From nobody Mon Aug 8 05:51:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F0A12B015 for ; Mon, 8 Aug 2016 05:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 LLJ3HCGGdAyd for ; Mon, 8 Aug 2016 05:51:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D59712D0DD for ; Mon, 8 Aug 2016 05:51:08 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u78Cp5XU014588 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 15:51:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u78Cp5dt007526; Mon, 8 Aug 2016 15:51:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22440.32825.371898.685634@fireball.acr.fi> Date: Mon, 8 Aug 2016 15:51:05 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <28861B29-3DA6-43E7-8798-FD8CC7F51341@gmail.com> References: <20160804215615.15820.73050.idtracker@ietfa.amsl.com> <28861B29-3DA6-43E7-8798-FD8CC7F51341@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 12:51:09 -0000 Yoav Nir writes: > Hi. > > New in this version: > - A few textual changes in the Introduction (suggested by Tero) You seemed to skip my proposed changes for the IANA considerations section. As an IANA expert, I would be more happy with the actual table version of the allocations there, as it makes IANAs work easier, which means there will be less changes for mistakes... I.e., I would still propose changing the IANA Considerations section to have the table format of allocations: Number Name Recipient Tests Reference ------ ---- --------------- --------- TBA1 Curve25519 [RFCxxxx], Sec 3.2 [RFCxxxx] TBA2 Curve448 [RFCxxxx], Sec 3.2 [RFCxxxx] > - Numerical example in Appendix A for Curve25519. This is good... Hopefully someone can verify that using some other code than openssl... -- kivinen@iki.fi From nobody Mon Aug 8 06:13:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB9712D814 for ; Mon, 8 Aug 2016 06:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 7zp4GKQvwKki for ; Mon, 8 Aug 2016 06:13:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086CF12D813 for ; Mon, 8 Aug 2016 06:13:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3s7HsH4mYYz3ds; Mon, 8 Aug 2016 15:13:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1470661987; bh=w+UghK+Dsr5+bX9jS/HHbIzkro1VsPKAKjc7pHElF60=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Gohyr9uT4i15VPA4pjwIjxnSv9Fr9LYGhIeY822P+UxCk7OqInazAw/4wjAeb4SKQ jkWUqpMczz1R3F7nbjbZCygkU2fw72Np0KocfThW0XSo2nqScSjxz4Zv3dhaZtbqB1 SrBPepdBSCNLPbeL6OHz5hbpJH3jPdupk39QakC4= 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 TA3GcsvXmgcv; Mon, 8 Aug 2016 15:13:06 +0200 (CEST) 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; Mon, 8 Aug 2016 15:13:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 59C20352954; Mon, 8 Aug 2016 09:12:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 59C20352954 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4281B406A900; Mon, 8 Aug 2016 09:12:55 -0400 (EDT) Date: Mon, 8 Aug 2016 09:12:55 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22440.32133.870165.114680@fireball.acr.fi> Message-ID: References: <82CD09B9-5B50-4C36-9390-A0DF4C303E2E@nohats.ca> <22440.32133.870165.114680@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Tommy Pauly Subject: Re: [IPsec] review of draft-pauly-ipsecme-split-dns-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:13:11 -0000 On Mon, 8 Aug 2016, Tero Kivinen wrote: > Paul Wouters writes: >> As explains in another thread on the list, that just complicates sending >> this information down to a locally running DNS server. None of the >> current ones take DNS wireformat for on-the-fly reconfiguration. >> However, they do take DNS presentation format. Also, for instance if >> you look at the libreswan implementation, this data is passed into >> the connection handler via environment variables, so libreswan would >> have to convert the DNS wire format to DNS presentation format before >> giving it to the handler for DNS reconfiguration. > > We are specifying the IKEv2 protocol extension, not really specifying > how to pass the information forward. If some implementation is using > environment variables, or command line options to pass this > information forward I think some kind of binary format is better in > IKEv2 than string format. Well, we have been passing domain names to forward via IKEv1 XAUTH for 10+ years and I've never heard of a problem with passing domain names as strings. I find this "security software authors might do dangerous string passing" a rather unconvincing argument. > Ifwe use string format the IKEv2 implementations might easily just > pass the string forward without any checking, and this might cause > security vulnerabilities like we had with shellshock or similar. We are talking about dedicated security software here, not /bin/bash. If your security software can't do string passing, you already are using a timb bomb. > If the input format is some kind of binary format, and the IKEv2 > library then constructs the string format out of that it will remove > ability to do that kind of attacks. Why? You don't think attackers can encode weird characters in binary which would be "blindly" decoded into ascii with the same dangerous characters inside? > With string formats we need to make sure that there is nothing > dangerous in there ("$INCLUDE /etc/passwd" or "; `sh -c > /sbin/reboot`") and we have to specify what kind of checking > implementations should do on the format. Same for binary format? We either have to write our own routines (more likely) or link against a DNS library that has this functionality. Like using ldns, which would drag in so much code people more likely will copy the wire conversation functions from some dns library into their code and never update that code again, possibly leaving in security vulnerabilities. > Saying that the contents is DS RDATA wire format as specified in the > RFC4034 section 5.1 would be much easier, and converting that to > string representation is quite easy, as it is just 1 16-bit field, two > 8-bit field, and then the digest: And now you have to understand DNS wire format and all their possible changes, use of compression, sneaking in multiple records, etc etc. > INTERNAL_DNS_DOMAIN(example.com,31406,8,2, > 0xF78CF3344F72137235098ECBBD08947C2C9001C7F6A085A17F518B5D8F6B916D) I understand you can do this, but it does add a string2wire() and wire2string() operation for what I believe is a red-herring for security reasons. >>>> I do not understand why the TTL is ignored. I also think that >>>> would be important in case of KSK roll-over. >> >> The TTL is ignored because this is an administrative reconfiguration. >> Just like a DNS server loading trust anchors from a file, there is no >> TTL to that file-based information either. >> >> If the zone does a KSK roll without updating the IPsec server, it is >> an administrative error. Possibly, the IPsec server could have code >> that reads the KSK's hourly and auto-updates what it gives to its >> clients, but that would all be implementation specific and I don't >> think this document needs to specify that. > > It is not enough for the IPsec server to fetch KSK, as the client > might have fetched the TA information two months ago, when it > connected to the SGW. It might have done several IKEv2 rekeys after > that, but as it does configuration payloads only when it initially > connects it will not get new configuration information ever. Perhaps that needs clarification, but my idea was that you purge the trust anchor and the zone data underneath it when you tear down the IPsec SA. The VPN tunnel is not meant to be a replacement for RFC-5011 style trust anchor updating. The split-DNS view can be changed at any time by the server/internal network and clients MUST NOT store this information as a permanent update. I will add language to clarify that. > This might not be something that we actually need to fix here, it > might be enough just to add some words about that, and say that if > internal domain does KSK roll overs then the server might want to > request clients to do reauthentication (RFC4478) while doing roll over > so they will get new configuration information before the old one is > removed. Any internal KSK roll should be done slowly enough (days or weeks) so that any VPN client connecting can always pull a working DNSKEY RRset. Perhaps a re-key or re-auth event should allow to request/send a new CFG set to keep updated for very long lived tunnels? >> Well, the idea here is that you will not be able to resolve that >> resource unless you accept DNS server for it. If you say SHOULD instead >> of MUST, it means you are going to fail to resolve the internal >> resource. As for using the internal DNS for more than advertised, if the >> internal DNS server is okay with resolving everything, it could send >> the value ".". We could clarify that explicitly. > > Internal server might be willing to resolve everything, and even > provide completely new DS for "." so you can do everything securely, > but the user might be bit suprised to learn that his facebook.com > requests go to the company dns server, and dnssec is happy with the > faked results pointing to the companys internal facebook proxy that > checks they do not post anything nasty about company to the > facebook... I am not sure if you are agreeing with the SHOULD or the MUST here? You seem to be arguing to leave it as MUST? > So this is also security issue, i.e., how much configuration you > should trust from the server. Bad server can send you bad > configuration data, and client might want to limit the damage done by > the bad server. Which is why the client can send the list of domains it is willing to have overridden, or it can interpret the received list. And it can ignore "." if that is not in its locally accepted list. Paul From nobody Mon Aug 8 06:24:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2984112D80B for ; Mon, 8 Aug 2016 06:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 hHE_8jbhLU3K for ; Mon, 8 Aug 2016 06:24:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA5612D5CC for ; Mon, 8 Aug 2016 06:15:10 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u78DF1l0017552 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 16:15:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u78DF1C9016279; Mon, 8 Aug 2016 16:15:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22440.34261.193865.786849@fireball.acr.fi> Date: Mon, 8 Aug 2016 16:15:01 +0300 From: Tero Kivinen To: "Paul Hoffman" In-Reply-To: <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 20 min Archived-At: Cc: "ipsec@ietf.org" , Scott Fluhrer Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:24:50 -0000 Paul Hoffman writes: > On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: > > > The trick to that is to add a new column to the IANA table > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 > > That's the first of two tricks: the second is getting agreement about > the rules for the values in that column. It seems like there is still > disagreement in the crypto community about how susceptible different > algorithms and modes are to quantum. As an IANA expert, I am not that happy adding yet another column to that table. The ESP/IKEv2 reference columns already seem to make enough confusion for people :-) Also I think it is bad idea to list which ciphers are quantum computing safe, as I have no idea whether RC5 or Blowfish are really in that category, even when they do have long keys... It might be better to list ciphers which we consider not to be safe, i.e., explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 128-bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not PRF_AES_CBC). Also this is something we might want to add to the rfc4307bis provided we can agree on the text before it goes forward. I.e. I do not think the RFC4307bis should wait for the text, as we can add it the QR document also, but if we can agree on that now, then we can add this kind of warning to rfc4307bis too. That text could be something like this: Quantum computers might able to perform Grover's algorithm; that effectively halves the size of a symmetric key. Because of this, to provide 128-bit security even when we have quantum computers, the symmetric algorithm keys needs to have least 256 bits of entropy. Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys always, they cannot use longer keys, so the text saying "even though they can use larger keys" is wrong, as those versions cannot use longer keys. -- kivinen@iki.fi From nobody Mon Aug 8 06:41:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2365C12D819 for ; Mon, 8 Aug 2016 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 D21OvT3-MXl5 for ; Mon, 8 Aug 2016 06:41:52 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209AA12D098 for ; Mon, 8 Aug 2016 06:41:52 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3s7JVP02q6z3mQ; Mon, 8 Aug 2016 15:41:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1470663709; bh=wxwSsSOeZUxfJCL2EOx6AR4RrQr5RmKa99TRRn+WVBk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RrVHosy5fsVGy5mq0oteuwRJUJ5ZgoZ2IZbEzt7gAxgFA1TFAC3Y0P2yW8B38Xd+x SJS3HFwBHh2GHh/nCqLcvf8hmjs6JjPve1/m891dO5V72fL3mlpsIDwtdmndChgk5Z FMJZL8FaUguEmfFJK85qcRHe2wBNF9EHMKAjoWN8= 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 5vJASV45TwNp; Mon, 8 Aug 2016 15:41:48 +0200 (CEST) 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; Mon, 8 Aug 2016 15:41:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 259D5352954; Mon, 8 Aug 2016 09:41:37 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 259D5352954 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 05103406A900; Mon, 8 Aug 2016 09:41:36 -0400 (EDT) Date: Mon, 8 Aug 2016 09:41:36 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22440.34261.193865.786849@fireball.acr.fi> Message-ID: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Paul Hoffman , Scott Fluhrer Subject: [IPsec] 4307bis/7321bis key sizes, was Re: I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 13:41:53 -0000 On Mon, 8 Aug 2016, Tero Kivinen wrote: > Also this is something we might want to add to the rfc4307bis provided > we can agree on the text before it goes forward. I.e. I do not think > the RFC4307bis should wait for the text, as we can add it the QR > document also, but if we can agree on that now, then we can add this > kind of warning to rfc4307bis too. That text could be something like > this: > > Quantum computers might able to perform Grover's algorithm; that > effectively halves the size of a symmetric key. Because of this, to > provide 128-bit security even when we have quantum computers, the > symmetric algorithm keys needs to have least 256 bits of entropy. Actually, this is a very good reason to bumo the keysizes from 128 to 256. Currently in 7321bis and 4307bis, 128 is MUST and 256 is SHOULD. I have asked before if we should make 256 MUST and 128 MUST-. Current text has: [1] - This requirement level is for 128-bit keys. 256-bit keys are at SHOULD. 192-bit keys can safely be ignored. [IoT] - This requirement is for interoperability with IoT. IPsec sessions may have very long life time, and carry multiple packets, so there is a need to move 256-bit keys in the long term. For that purpose requirement level is for 128 bit keys and 256 bit keys are at SHOULD (when applicable). In that sense 256 bit keys status has been raised from MAY in RFC7321 to SHOULD. Is there anyone who disagrees with making 128 MUST- and 256 MUST ? Paul From nobody Mon Aug 8 09:13:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0312D125 for ; Mon, 8 Aug 2016 09:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 cFCwQbpQZPnJ for ; Mon, 8 Aug 2016 09:13:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E12012B01B for ; Mon, 8 Aug 2016 09:13:10 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u78GD1iH018819 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 19:13:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u78GD0w2012147; Mon, 8 Aug 2016 19:13:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22440.44940.619165.393001@fireball.acr.fi> Date: Mon, 8 Aug 2016 19:13:00 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <82CD09B9-5B50-4C36-9390-A0DF4C303E2E@nohats.ca> <22440.32133.870165.114680@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 55 min X-Total-Time: 65 min Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Tommy Pauly Subject: Re: [IPsec] review of draft-pauly-ipsecme-split-dns-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:13:13 -0000 Paul Wouters writes: > Well, we have been passing domain names to forward via IKEv1 XAUTH for > 10+ years and I've never heard of a problem with passing domain names > as strings. I find this "security software authors might do dangerous > string passing" a rather unconvincing argument. Simple string is not an issue. Regex to check whether domain name is leagl is quite simple, and even then people do that wrong. Checking whether string is valid textual representation of the dns record is harder, and you have to think things like, are comments allowed, are newlines allowed. Also if you want to verify that the DS record is actually for the real domain name, and not something else you need to parse the string to get the first entry of it, and you might need to know what $ORIGIN is to be able to know which suffix you need to add to it if it does not have dot in the end etc... I do not even know whether that format has some way of escaping special characters, i.e., some kind of \x2e format or so. Where is the formal specification for that text representation? RFC4034 just specifies DS RR specific stuff, but it does not give any indication for the generic format. For example where is it said that "; key id = 60485" is comment? I tried quickly look that up, but could not find it, so it would be better to add direct reference to the rfc specifying the generic text representation format of DNS RR records, not just the DS RR specific parts which are in RFC4034. > > Ifwe use string format the IKEv2 implementations might easily just > > pass the string forward without any checking, and this might cause > > security vulnerabilities like we had with shellshock or similar. > > We are talking about dedicated security software here, not /bin/bash. If > your security software can't do string passing, you already are using > a timb bomb. You said that someone uses environment variables, and some uses it as command line arguments. Those all might have issues with bash parsing environment variables in specific ways, meaning that the security software needs to make sure the things it passes to them are safe. Yes, the easist way to do string passing that format is to first parse it in IKEv2 from text to binary, and then reformat it back to text format which I know cannot have anything funny in it, but before I can do that I need to know the format I am about to parse, and for now I do not have that information. > > If the input format is some kind of binary format, and the IKEv2 > > library then constructs the string format out of that it will remove > > ability to do that kind of attacks. > > Why? You don't think attackers can encode weird characters in binary > which would be "blindly" decoded into ascii with the same dangerous > characters inside? No they cannot. If I encode the 8-bit number as 8-bit binary, when I parse it, I will get 8-bit number, which I can then print with "%d" to ascii if needed. > > With string formats we need to make sure that there is nothing > > dangerous in there ("$INCLUDE /etc/passwd" or "; `sh -c > > /sbin/reboot`") and we have to specify what kind of checking > > implementations should do on the format. > > Same for binary format? We do not need to specify our binary format to include any of those special things. There is no need for our binary format to allow comments, or including other files or anything like that. We do not need to specify binary format that includes all features the text format has, only the features we need, which in our case is only to encode the DS RR record, which consists exactly 4 fields. > We either have to write our own routines (more likely) or link > against a DNS library that has this functionality. You can link against DNS library, I would write: ret = ssh_decode_buffer(buffer, SSH_DECODE_UINT8_STR(&name, &name_len), SSH_DECODE_UINT16(&key_tag), SSH_DECODE_CHAR(&alg), SSH_DECODE_CHAR(&digest_type), SSH_FORMAT_END); if (ret == 0) { return SSH_IKEV2_INVALID_SYNTAX; } digest = ssh_buffer_ptr(buffer) + ret; digest_len = ssh_buffer_len(buffer) - ret; which is most likely easier, than to find out the suitable location in dns library where to call to get the rr-record decoded. > Like using ldns, which would drag in so much code people more likely > will copy the wire conversation functions from some dns library into > their code and never update that code again, possibly leaving in > security vulnerabilities. Yes. And as we are talking about 10 lines of code, I think they should write it specifically for this job, and not use huge library. > > Saying that the contents is DS RDATA wire format as specified in the > > RFC4034 section 5.1 would be much easier, and converting that to > > string representation is quite easy, as it is just 1 16-bit field, two > > 8-bit field, and then the digest: > > And now you have to understand DNS wire format and all their possible > changes, use of compression, sneaking in multiple records, etc etc. I was talking DS RDATA wire format as specifice in 5.1, and I do not think there is anything like compression there, or multiple records, as it is just one record. But if you like, we can just copy the fields and their sizes to this specification and not use the RDATA format if that makes you happy. > > > INTERNAL_DNS_DOMAIN(example.com,31406,8,2, > > 0xF78CF3344F72137235098ECBBD08947C2C9001C7F6A085A17F518B5D8F6B916D) > > I understand you can do this, but it does add a string2wire() and > wire2string() operation for what I believe is a red-herring for security > reasons. I disagree with you. I think it will add security, will make the implementations easier to write, and smaller. Especially if you do have your own resolver you are going to configure, and which might not use textual format at all. In that case you suddenly need to implement full textual format parser just to parse this one line of text. > > It is not enough for the IPsec server to fetch KSK, as the client > > might have fetched the TA information two months ago, when it > > connected to the SGW. It might have done several IKEv2 rekeys after > > that, but as it does configuration payloads only when it initially > > connects it will not get new configuration information ever. > > Perhaps that needs clarification, but my idea was that you purge the > trust anchor and the zone data underneath it when you tear down the > IPsec SA. IPsec SA? I assume you are meaning IKEv2 SA, not IPsec SA (Child SA), as configuration parameters passed inside the configuration paylads are tied to the lifetime of the IKEv2 SA, not Child SA. > The VPN tunnel is not meant to be a replacement for RFC-5011 > style trust anchor updating. The split-DNS view can be changed at any > time by the server/internal network and clients MUST NOT store this > information as a permanent update. I will add language to clarify that. But you do store it for few years, i.e. as long as your IKEv2 SA happens to stay up... Not all IKEv2 SAs are short lived. Some of them might stay up for months, or even years. > > This might not be something that we actually need to fix here, it > > might be enough just to add some words about that, and say that if > > internal domain does KSK roll overs then the server might want to > > request clients to do reauthentication (RFC4478) while doing roll over > > so they will get new configuration information before the old one is > > removed. > > Any internal KSK roll should be done slowly enough (days or weeks) > so that any VPN client connecting can always pull a working DNSKEY > RRset. Why would client reconnect that often? I mean if I have IKEv2 up and running, and I do rekeys every 24 hours, why should I need to reconnect it ever unless the network between devices break down. > Perhaps a re-key or re-auth event should allow to request/send a new > CFG set to keep updated for very long lived tunnels? IKEv2 rekey does not do that, as old configuration parameters are inherited by new IKEv2 SA. Re-authentication (i.e. tearing down the IKEv2 SA and creating new one) do make new configuration payload exchange, thus might get new IP-address and will get new trust anchors for DNSSEC. And yes, the server can just send delete notification to the IKEv2 SA when the old trust anchor is about to expire, thus forcing the client to do reauthentication, and this will work even if the client does not support RFC4478. This might of course cause issues, as user might not be there to type in the credentials need to reconnect, thus causing the connection to stay down... > > Internal server might be willing to resolve everything, and even > > provide completely new DS for "." so you can do everything securely, > > but the user might be bit suprised to learn that his facebook.com > > requests go to the company dns server, and dnssec is happy with the > > faked results pointing to the companys internal facebook proxy that > > checks they do not post anything nasty about company to the > > facebook... > > I am not sure if you are agreeing with the SHOULD or the MUST here? You > seem to be arguing to leave it as MUST? Not really, I am saying we should have warning saying that rogue or badly configure server can cause all kind of issues especially by sending the DS records for ".". The security considerations section do have text saying that if vpn gateway A sends "example.com" and vpn gateway B does the same then the IKE connection is terminated, but it does not say that vpn gateway a might send "." as INTERNAL_DNS_DOMAIN and give new TA for "." too, which will forward all DNS requests to the vpn... Also if one VPN gateway sends "example.com" and another sends "com" which one of them is used? The one which the dns resolver you use happens to use, or do we want to specifcy that resolvers should then always use longest match when matching against the list of resolvers... > > So this is also security issue, i.e., how much configuration you > > should trust from the server. Bad server can send you bad > > configuration data, and client might want to limit the damage done by > > the bad server. > > Which is why the client can send the list of domains it is willing to > have overridden, or it can interpret the received list. And it can > ignore "." if that is not in its locally accepted list. But adding reasoning for that to the security considerations section is needed... -- kivinen@iki.fi From nobody Mon Aug 8 09:46:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D7012D621 for ; Mon, 8 Aug 2016 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X7L3Zk1fFu7O for ; Mon, 8 Aug 2016 09:46:26 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0B112D0FD for ; Mon, 8 Aug 2016 09:46:24 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o80so151463127wme.1 for ; Mon, 08 Aug 2016 09:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jEJPU5yjaXVPUFlrFIpnGTrisZzU6WSN7OcRdlGiOfw=; b=fpyD0beU/Rnu9ymYODb6dZhqqVQWpFfwmg7yOmzH0QhI4clZ5KRkoW2ad/xwo3qhKT zYeR4s5nWubZ3qvLIx6bfgY8VME/KP6q+gPIZ46Zifh2ymjvnvT7PIbQQNNn5joyy8A7 X2wWkE1lNbkCNtjEG3HP8yIIWocRK1+I30q8hptk0q4n0RwpJBy9yhhEhndvbg9OGCbr pbcHn28rLUpH8s4VxoksqwnIEhqrWSX2D4w0FplVnbNgcn9e9lCgAmN0to7v0fycX1aA m53aTbrFlWRd7ivVBKXNRVFvPqPtJ/itUZJ5kBu3MMn4+mcsX4RxdxPZARTt5pgSxIaT pLXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jEJPU5yjaXVPUFlrFIpnGTrisZzU6WSN7OcRdlGiOfw=; b=k3oYHXSspWgu/aVOrzWO/w+2dyNlDyC0equmScuwcBqyGV+yIMC+SnoKq2AXT6L47Q XRelHU288oC1pO34EzExFh/m82gdFwXYBSPfw6k5GpnveUdmtPwPnv1WlJJ6dK0xP2q/ r0yZwy6TL0rQTZL42sot8QoWPc/vD8CRJc5Ib21pq5s+Btch9lpS0ocMBzv7LOuxIXKI wYmOUmiazp8vgwKIyDDBv82R4XOhxxCpKtFMsNAho2HEy2voLx22/ROQuL9YWdVrGvQW e/6IVMBiK3UrAc0SjMxXpjOlY4AZNLThpx+H8MsJGXhvJIIMYzJ0Y6XOxH2wvOZjHD4N TO3A== X-Gm-Message-State: AEkoouvgu3UKpi8hm0Un/RZKHeBJiLbpH6I2OaZ/rB+2RiVvTlmtUA1nxVyvef0UsjTXbQ== X-Received: by 10.194.23.166 with SMTP id n6mr97239552wjf.36.1470674783136; Mon, 08 Aug 2016 09:46:23 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id vv2sm22443469wjc.29.2016.08.08.09.46.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Aug 2016 09:46:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <22440.32825.371898.685634@fireball.acr.fi> Date: Mon, 8 Aug 2016 19:46:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160804215615.15820.73050.idtracker@ietfa.amsl.com> <28861B29-3DA6-43E7-8798-FD8CC7F51341@gmail.com> <22440.32825.371898.685634@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 16:46:30 -0000 > On 8 Aug 2016, at 3:51 PM, Tero Kivinen wrote: >=20 > Yoav Nir writes: >> Hi. >>=20 >> New in this version: >> - A few textual changes in the Introduction (suggested by Tero) >=20 > You seemed to skip my proposed changes for the IANA considerations > section. As an IANA expert, I would be more happy with the actual > table version of the allocations there, as it makes IANAs work easier, > which means there will be less changes for mistakes... >=20 > I.e., I would still propose changing the IANA Considerations section > to have the table format of allocations: >=20 >=20 > Number Name Recipient Tests Reference > ------ ---- --------------- --------- > TBA1 Curve25519 [RFCxxxx], Sec 3.2 [RFCxxxx] > TBA2 Curve448 [RFCxxxx], Sec 3.2 [RFCxxxx] OK. >=20 >> - Numerical example in Appendix A for Curve25519. >=20 > This is good... Hopefully someone can verify that using some other > code than openssl=E2=80=A6=20 That would be great. Also, I=E2=80=99m still looking for code I can use = for Curve448. OpenSSL won=E2=80=99t have that for release 1.1.0, only = the release after that[1]. Yoav [1] https://github.com/openssl/openssl/issues/1398 From nobody Tue Aug 9 05:44:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE912D7F9 for ; Tue, 9 Aug 2016 05:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 XtWEo0NkJvYN for ; Tue, 9 Aug 2016 05:44:10 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E908412D7F8 for ; Tue, 9 Aug 2016 05:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3240; q=dns/txt; s=iport; t=1470746649; x=1471956249; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o69hkTFdDJ6V8vbc5FcJHYxIfM/hGFIXluOxZexB0Q0=; b=S6hpy7jjnwD8CtZgJhU7Knqwp1LOcSQSo0ZclzUpXTwXrAemIvuO1N+B 07QIL3pO8T8AsoCjHvg84XEa8o31ok7tt/2KucULopgHz9j9ehwW3H9xG cdvY5TFDm6DM1Bhly6z4uanVR5sBxf3aqLJYG7RzZKpBIA4o7bzQVqkFw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAgATz6lX/51dJa1dg0VWfAe5HYF9J?= =?us-ascii?q?IV5AoFMOBQBAQEBAQEBXSeEXgEBBAE6MQ4MBAIBCBEEAQEBHgkHMhQJCAIEAQ0?= =?us-ascii?q?FCAyIFQgOwjMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2KGwWZOQGPAo9Kj?= =?us-ascii?q?DSDdwEeNoN6boZOfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="scan'208";a="307975569" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2016 12:44:08 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u79Ci86p028152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 12:44:08 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 Aug 2016 08:44:07 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 9 Aug 2016 08:44:07 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , Paul Hoffman Thread-Topic: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt Thread-Index: AQHR7y/10NkmpxmQkkWhx9nlDv4V5aA/UmuAgAFBhqA= Date: Tue, 9 Aug 2016 12:44:07 +0000 Message-ID: <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> In-Reply-To: <22440.34261.193865.786849@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 12:44:11 -0000 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, August 08, 2016 9:15 AM > To: Paul Hoffman > Cc: Yaron Sheffer; ipsec@ietf.org; Scott Fluhrer (sfluhrer) > Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt >=20 > Paul Hoffman writes: > > On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: > > > > > The trick to that is to add a new column to the IANA table > > > https://www.iana.org/assignments/ikev2-parameters/ikev2- > parameters.x > > > html#ikev2-parameters-5 > > > > That's the first of two tricks: the second is getting agreement about > > the rules for the values in that column. It seems like there is still > > disagreement in the crypto community about how susceptible different > > algorithms and modes are to quantum. >=20 > As an IANA expert, I am not that happy adding yet another column to that > table. The ESP/IKEv2 reference columns already seem to make enough > confusion for people :-) On the other hand, we need to give people some guidance somehow... >=20 > Also I think it is bad idea to list which ciphers are quantum computing s= afe, as > I have no idea whether RC5 or Blowfish are really in that category, even > when they do have long keys... There's no known Quantum attack against either (assuming long keys), and so= they're in the same category as AES-256. >=20 > It might be better to list ciphers which we consider not to be safe, i.e.= , > explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 128- > bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not > PRF_AES_CBC). That makes a lot of sense; ultimately, we don't really know which ones are = strong against Quantum Computers (then again, we really don't know which on= es are strong against conventional computers using undiscovered attacks :-)= ; we do know some are likely weak. >=20 > Also this is something we might want to add to the rfc4307bis provided we > can agree on the text before it goes forward. I.e. I do not think the > RFC4307bis should wait for the text, as we can add it the QR document als= o, > but if we can agree on that now, then we can add this kind of warning to > rfc4307bis too. That text could be something like > this: >=20 > Quantum computers might able to perform Grover's algorithm; that > effectively halves the size of a symmetric key. Because of this, to > provide 128-bit security even when we have quantum computers, the > symmetric algorithm keys needs to have least 256 bits of entropy. >=20 > Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys > always, they cannot use longer keys, so the text saying "even though they > can use larger keys" is wrong, as those versions cannot use longer keys. Actually, if you look through the definitions of the transforms that IANA p= oints to, RFC4434 and RFC4615, the transform can take as input a "key" long= er than 128 bits. Yes, if you look inside the definition of the transform,= you see that they transform the arbitrary-length "key" into a 128 bit one;= people quite often don't look into the innards of their crypto (nor should= they have to). > -- > kivinen@iki.fi From nobody Tue Aug 9 06:07:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB4112D518 for ; Tue, 9 Aug 2016 06:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 juZ01RasA6vp for ; Tue, 9 Aug 2016 06:07:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BEB12D59B for ; Tue, 9 Aug 2016 06:07:37 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u79D7RAS014186 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Aug 2016 16:07:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u79D7Ra4008821; Tue, 9 Aug 2016 16:07:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22441.54671.248778.890727@fireball.acr.fi> Date: Tue, 9 Aug 2016 16:07:27 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Cc: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 13:07:41 -0000 Scott Fluhrer (sfluhrer) writes: > > Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys > > always, they cannot use longer keys, so the text saying "even though they > > can use larger keys" is wrong, as those versions cannot use longer keys. > > Actually, if you look through the definitions of the transforms that > IANA points to, RFC4434 and RFC4615, the transform can take as input > a "key" longer than 128 bits. Yes, if you look inside the > definition of the transform, you see that they transform the > arbitrary-length "key" into a 128 bit one; people quite often don't > look into the innards of their crypto (nor should they have to). Yes, as PRF they can take arbitrary long keys, but the AES is always using 128-bit keys. So both of those are true in a way. For encryption algorithms you can use the key length attribute to specify key length for the AES, but for the PRF or INTEG you cannot, instead they use fixed length key for AES. The original version of the AES-XCBC-PRF-128 specified in the RFC3664 did require the exactly 128-bit key for the PRF use also, but this caused problems as in IKEv2 we want to use PRF on the nonces, and the shared secret, thus requiring them to be 128-bits caused problems. Because of this RFC4434 was done so that it allows arbitrary sized keying material but the PRF still has security of 128-bit... I.e. the prehashing done to feed the PRF key to the AES is just to allow any sized material, and using longer PRF key does not increase the security. So at least separate the "PRF key" and "AES key" in the text, so it is clear which text we are refering. -- kivinen@iki.fi From nobody Tue Aug 9 06:48:06 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA0B12D51D; Tue, 9 Aug 2016 06:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147075048258.30707.10796219761276839937.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 06:48:02 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 13:48:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Curve25519 and Curve448 for IKEv2 Key Agreement Authors : Yoav Nir Simon Josefsson Filename : draft-ietf-ipsecme-safecurves-03.txt Pages : 7 Date : 2016-08-09 Abstract: This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 9 09:15:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122AA12D5D8 for ; Tue, 9 Aug 2016 09:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 MhLnzl0efxwi for ; Tue, 9 Aug 2016 09:15:52 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFB312D0BE for ; Tue, 9 Aug 2016 09:15:52 -0700 (PDT) Received: from [10.32.60.61] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u79GFmZG009125 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2016 09:15:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.61] From: "Paul Hoffman" To: "Scott Fluhrer" Date: Tue, 09 Aug 2016 09:15:47 -0700 Message-ID: <2EB225E0-2921-43E7-90A5-B1D8329E9D66@vpnc.org> In-Reply-To: <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 16:15:54 -0000 On 9 Aug 2016, at 5:44, Scott Fluhrer (sfluhrer) wrote: >> -----Original Message----- >> From: Tero Kivinen [mailto:kivinen@iki.fi] >> Sent: Monday, August 08, 2016 9:15 AM >> To: Paul Hoffman >> Cc: Yaron Sheffer; ipsec@ietf.org; Scott Fluhrer (sfluhrer) >> Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt >> >> Paul Hoffman writes: >>> On 5 Aug 2016, at 8:23, Yaron Sheffer wrote: >>> >>>> The trick to that is to add a new column to the IANA table >>>> https://www.iana.org/assignments/ikev2-parameters/ikev2- >> parameters.x >>>> html#ikev2-parameters-5 >>> >>> That's the first of two tricks: the second is getting agreement >>> about >>> the rules for the values in that column. It seems like there is >>> still >>> disagreement in the crypto community about how susceptible different >>> algorithms and modes are to quantum. >> >> As an IANA expert, I am not that happy adding yet another column to >> that >> table. The ESP/IKEv2 reference columns already seem to make enough >> confusion for people :-) > > On the other hand, we need to give people some guidance somehow... Do we? Who is "we"? Why is "our" guidance any better than what they get from their own experts, particularly if "our" guidance gets ossified in an IANA registry or RFCs that are updated slowly? >> Also I think it is bad idea to list which ciphers are quantum >> computing safe, as >> I have no idea whether RC5 or Blowfish are really in that category, >> even >> when they do have long keys... > > There's no known Quantum attack against either (assuming long keys), > and so they're in the same category as AES-256. That would be better stated as "There's currently no known..." >> It might be better to list ciphers which we consider not to be safe, >> i.e., >> explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using >> 128- >> bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not >> PRF_AES_CBC). > > That makes a lot of sense; ultimately, we don't really know which ones > are strong against Quantum Computers (then again, we really don't know > which ones are strong against conventional computers using > undiscovered attacks :-); we do know some are likely weak. Exactly. --Paul Hoffman From nobody Wed Aug 10 23:12:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8041112D18D for ; Wed, 10 Aug 2016 23:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DcfRqjXEaxN0 for ; Wed, 10 Aug 2016 23:12:34 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B060E12B038 for ; Wed, 10 Aug 2016 23:12:33 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i5so11469033wmg.0 for ; Wed, 10 Aug 2016 23:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=UdkT5FBEAKOGLw+pSRG4j4eg91Qqxj9Z/2wBF81F8PQ=; b=eze18VNi/c53cyfQtFcnaV9GteQOkLM9KBh0B28WMSBTkrkJ2bs/dvG+FQKTwN0++M 8hR1G+7HU9BtCy9FIglFjCIbU/G7+EjmFhKTxd8ImtcdDhNW4brxpW2wwV89xdGilxmX MNJPlYaJAbNKrqxe3EsdWS2AIyezeBoFoH7hNJxvA/EOgW2BoALMvH/vmk+cdTNU3Xa3 JI6MrMJ8gMKkCz8Dy+i2+43fzVHTIYKUmc7HQQ2t9kiOQQfyXIfOMgu0vum2vYI7uXNE ojJrO5ySQXNClyqi/upQzoKzFHjVawZdZTqVWXTDoid0lN84+7s6+PZ9zFPAUhr9I9CE B7Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=UdkT5FBEAKOGLw+pSRG4j4eg91Qqxj9Z/2wBF81F8PQ=; b=ZHD2H0iMx1tCWQt8D0bcdbQH73kTtxgE+Yeuq8YhCzoNB1yEYlMrblGMdTr119N/qL OT1wdybYwV1zi6Gw50z0SxKqe0IM3KhlfJHhPaPybqbE44NE0WQcR7BYIiMWs6G9ruu/ fgSIy/lM3T+cKGWd/78Afg50fhhf+XcHUZh9fldOTj9JpssSPQcZLDrGZ77Yb8yKlDcO MFD/43qbpEnqcQwx6ma/sHUc+B/m/XFp5us5F95uIFuK/mlz6wGNSQxRWMbXh+8sydt7 FoZELe4WPMHlSksZ/BV5/QOClaKwLE4HPNSu7rZNavK1JF2bWrDRLCjz+RlnSbjeHOfj cAiA== X-Gm-Message-State: AEkoouvu6myp/jGj3p6hGZw9O89broUTiZfMDGRwNZIWpE7Jd3Lh1diV2V0J+s2IoNcmgA== X-Received: by 10.46.5.5 with SMTP id 5mr1261275ljf.9.1470895952171; Wed, 10 Aug 2016 23:12:32 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e79sm252042lji.42.2016.08.10.23.12.31 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 10 Aug 2016 23:12:31 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , "Scott Fluhrer" References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> <2EB225E0-2921-43E7-90A5-B1D8329E9D66@vpnc.org> Date: Thu, 11 Aug 2016 09:12:30 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 06:12:35 -0000 Hi, >> On the other hand, we need to give people some guidance somehow... > > Do we? Who is "we"? Why is "our" guidance any better than what they get > from their own experts, particularly if "our" guidance gets ossified in > an IANA registry or RFCs that are updated slowly? Instead of listing QR-secure (or insecure) symmetric algorithms it's probably better to give some generic advice of selecting symmetric crypto in presense of Quantum Computers. For example (I stole the text from http://www.pqcrypto.eu.org/docs/initial-recommendations.pdf): Symmetric systems are usually not affected by Shor's algorithm, but they are affected by Grover's algorithm. Under Grover's attack, the best security a key of length n can offer is 2^(n/2), so AES-128 offers only 2^64 post-quantum security. This document recommends using algorithms with 256-bit keys to achieve 2^128 post-quantum security. >> There's no known Quantum attack against either (assuming long keys), >> and so they're in the same category as AES-256. > > That would be better stated as "There's currently no known..." Exactly. > --Paul Hoffman Regards, Valery. From nobody Thu Aug 11 05:16:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A4912D0E3 for ; Thu, 11 Aug 2016 05:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 JVhhbg9UTZVg for ; Thu, 11 Aug 2016 05:16:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0285412D18B for ; Thu, 11 Aug 2016 05:16:05 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7BCG1tn007021 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Aug 2016 15:16:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7BCG1Wh015161; Thu, 11 Aug 2016 15:16:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22444.27777.273959.299341@fireball.acr.fi> Date: Thu, 11 Aug 2016 15:16:01 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 9 min Archived-At: Subject: [IPsec] Working group Last call for draft-ietf-ipsecme-safecurves X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 12:16:08 -0000 Now when we have new version of the draft-ietf-ipsecme-safecurves, so I will now start two week working group last call (WGLC) for draft-ietf-ipsecme-safecurves-03 [1]. Please send your comments, questions etc to the WG mailing list before 2016-08-25. If you belive that the document is ready to be submitted to the IESG for consideration as a standard track RFC please send a short message stating this. [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ -- kivinen@iki.fi From nobody Thu Aug 11 05:17:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6E312B02D for ; Thu, 11 Aug 2016 05:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 4LzqE4Gk8_DX for ; Thu, 11 Aug 2016 05:17:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E0312D0C6 for ; Thu, 11 Aug 2016 05:17:04 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7BCH2Dr018838 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Aug 2016 15:17:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7BCH2ln014032; Thu, 11 Aug 2016 15:17:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22444.27838.642912.394462@fireball.acr.fi> Date: Thu, 11 Aug 2016 15:17:02 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] IPsecME Status update 2016-08-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 12:17:06 -0000 Charter update New version posted to list 2016-07-20, no objection in list, should go forward, waiting for the AD. Document Status: - draft-ietf-ipsecme-ddos-protection (David) WGLC should be done, ready to go forward. - draft-ietf-ipsecme-rfc4307bis (David) Should be ready for WGLC, new version with changes agreed in meeting done. - draft-mglt-ipsecme-rfc7321bis (David) New version posted what should align with 4307bis. This is agreed item on the charter, so we should do adoptation call for this document to be WG document. - draft-ietf-ipsecme-safecurves (Tero) New version submitted, WGLC started, will end 2016-08-25. - draft-nir-ipsecme-eddsa (Tero) I think this is still waiting for the curdle to decide for OID, but we could start WG adaptation call, as this is now in our charter, and this is good starting point. - draft-ietf-ipsecme-tcp-encaps (Tero) This should also be ready for WGLC. New work: - Quantum Resistance (David) We need to start discussion about the requirements and then when we have those decided on the list, we should adopt document. - draft-pauly-ipsecme-split-dns (David) This was accepted as charter item, but need few more reviews before taking it as WG draft. - draft-mglt-ipsecme-implicit-iv (Tero) This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. -- kivinen@iki.fi From nobody Thu Aug 11 06:50:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFCF12D608 for ; Thu, 11 Aug 2016 06:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Uu6A7vkgDZjT for ; Thu, 11 Aug 2016 06:50:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE9312D0A8 for ; Thu, 11 Aug 2016 06:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1797; q=dns/txt; s=iport; t=1470923416; x=1472133016; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mPRsLCn5/fHyYPuThEkrbcMGRgRmbta/cIzTqcJY5gc=; b=mTBWxAn5V69KI0tr3qhty6cNUvgp8N5kb7deWLw2h0fe6Szu+5nqw7S6 phWtz2wlNmT6VoUTlFaeVdmXCu3oq0hy6b4AT96Z6pbrxKymZgOMAqafz CfElbyk78YGDRVZwtyL5lLC5QyH8l+3r+JL4PJA7DjIFFbQ+VmbFns0Qc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgCvgaxX/4ENJK1eg0VWfAesfowog?= =?us-ascii?q?X0khXkCgWI4FAEBAQEBAQFdJ4ReAQEFOjEODAQCAQgOAwQBAR8JByERFAkIAgQ?= =?us-ascii?q?BDQUIiA8DFw68XA2EQAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoNKgQOCNA+HW?= =?us-ascii?q?AWZCDQBjFaCNo9KiC2ECIN3AR42g3puAYYFfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,505,1464652800"; d="scan'208";a="136590334" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2016 13:50:16 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7BDoFr2021100 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Aug 2016 13:50:15 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 Aug 2016 09:50:14 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Thu, 11 Aug 2016 09:50:14 -0400 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , Paul Hoffman Thread-Topic: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt Thread-Index: AQHR7y/10NkmpxmQkkWhx9nlDv4V5aA/UmuAgAFBhqCAAINQgIACORgGgAB+/uA= Date: Thu, 11 Aug 2016 13:50:14 +0000 Message-ID: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <496a3c96a34741e48f8ec4d9d2e2a031@XCH-RTP-006.cisco.com> <2EB225E0-2921-43E7-90A5-B1D8329E9D66@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 13:50:18 -0000 > -----Original Message----- > From: Valery Smyslov [mailto:svanru@gmail.com] > Sent: Thursday, August 11, 2016 2:13 AM > To: Paul Hoffman; Scott Fluhrer (sfluhrer) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt >=20 > Hi, >=20 > >> On the other hand, we need to give people some guidance somehow... > > > > Do we? Who is "we"? Why is "our" guidance any better than what they > > get from their own experts, particularly if "our" guidance gets > > ossified in an IANA registry or RFCs that are updated slowly? >=20 > Instead of listing QR-secure (or insecure) symmetric algorithms it's prob= ably > better to give some generic advice of selecting symmetric crypto in prese= nse > of Quantum Computers. >=20 > For example (I stole the text from http://www.pqcrypto.eu.org/docs/initia= l- > recommendations.pdf): >=20 > Symmetric systems are usually not affected by Shor's algorithm, but they = are > affected by Grover's algorithm. Under Grover's attack, the best security = a > key of length n can offer is 2^(n/2), so AES-128 offers only 2^64 post- > quantum security. This document recommends using algorithms with 256-bit > keys to achieve 2^128 post-quantum security. I'll steal this text in the next version (along with a note that, while the= PRFs PRF_AES128_XCBC and PRF_AES128_CMAC do accept keys larger than 128 bi= ts, they internally convert them to 128 bit values, and hence should be con= sidered as 128 bit algorithms). >=20 > >> There's no known Quantum attack against either (assuming long keys), > >> and so they're in the same category as AES-256. > > > > That would be better stated as "There's currently no known..." >=20 > Exactly. >=20 > > --Paul Hoffman >=20 > Regards, > Valery. From nobody Thu Aug 11 15:00:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53E712D813 for ; Thu, 11 Aug 2016 15:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.767 X-Spam-Level: X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ebvi_7nIwJjT for ; Thu, 11 Aug 2016 15:00:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C571112D806 for ; Thu, 11 Aug 2016 15:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20132; q=dns/txt; s=iport; t=1470952843; x=1472162443; h=from:to:subject:date:message-id:mime-version; bh=L7uRii4GittjQkaPNIYZKaocddbDNnZCu1/QiV+ye58=; b=EOZYIvg8A6KWjyEeH2eWu8BHp72rHbLYe9fpVCr5hbwq1ZLKCMJITzm7 FFx1O+tbG3L89mpxFD9zltmeAn0QUSbDzW8rVmasIN3sLzvY88KPgKcre o57siRWjN7ofz+hmYcTmMN26nuVlb5ikrxXyH4DUWV9AQ5QaWkOFEEh4+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAgCK9KxX/5xdJa1VCYJ3TlaBA7kmg?= =?us-ascii?q?X2IAzgUAQEBAQEBAV0nhGUtXgGBACYBBBsMB4gWoFygFwEBAQEGAQEBASOGKoh?= =?us-ascii?q?mhgIFk3iFRAGPDI9KkCwBHjaCEhyBTIZmfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,507,1464652800"; d="scan'208,217";a="134946095" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Aug 2016 22:00:42 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7BM0f8d028907 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Aug 2016 22:00:41 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 11 Aug 2016 18:00:40 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Thu, 11 Aug 2016 18:00:40 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rw== Date: Thu, 11 Aug 2016 22:00:40 +0000 Message-ID: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: multipart/alternative; boundary="_000_9475723e788947debfbb36f23c40030eXCHRTP006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 22:00:47 -0000 --_000_9475723e788947debfbb36f23c40030eXCHRTP006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In Berlin, we decided to take up Quantum Resistance as a work item, and tha= t we should start talking about requirements. I'm starting this thread in = a hope of kicking off the discussion. First of all, a solution to Quantum Resistance that is applicable everywher= e would involve replacing the (EC)DH exchange with a postquantum key exchan= ge. While this would be ideal, the cryptographical community currently doe= sn't have a solution that is sufficiently trusted and is of reasonable cost= . So, it would make sense to divide this into two efforts, a long term sol= ution (which we may initially put on the shelf, as the crypto pieces aren't= there yet), and a short term solution, to address the needs of customers t= hat aren't willing to wait; instead, they feel the need to protect traffic = that is encrypted now. For this short term solution, it's sufficient if we= don't necessarily cover all cases, a number of interesting cases (in parti= cular, ones for which redistributing secrets is doable) would be sufficient= . Does everyone agree with that general assessment? If so, there here is a list of potential requirements (based on Tero's list= that he gave during the IETF, but with a few of my own), along with my opi= nion: - Simplicity; how large of a change to IKE (and IKE implementation= s) are we willing to contemplate? o My opinion: minimizing changes to IKE should be given high priority, bo= th because "complexity is the enemy of security" and this is a short term s= olution; if we have a solution that we can't implement in a few years, well= , we might as well wait for the crypto people to give us the long term one. - Preserving existing IKE properties; how important is it that our= solution do not induce any weaknesses in IKE against an adversary with a c= onvention computer; that is, whatever we do, we must not make things worse? o My opinion: I'm pretty sure that we'll all agree that this is important= (except for possibly the identity protection, see below); I just want to s= tate this as something we need to remember. - What do we feel needs to protected from someone with a Quantum C= omputer? Do we feel the need to protect only the IPsec traffic, or do we = need to protect the IKE traffic as well. o My opinion: I'm going to abstain on this one, except to note that prote= cting only the IPsec traffic allows for a rather simple implementation; now= , if the WG decides that protecting the IKE traffic is important, this simp= licity is irrelevant. - What level of identity protection do we need to provide? If two= different IKE negotiations use the same shared secret, do we mind if someo= ne can deduce that? o My opinion: identity protection in IKE is rather overrated; I suspect t= here's enough in the data exchange that an advanced adversary (how can look= at things such as packet length and packet timings) is likely to get a fai= rly decent guess regardless. - PPK management; how much support do we provide for automaticall= y managing the secrets? o My opinion: we already have preshared keys in IKE, and we don't define = any particular management scheme for them (even though they are used quite = often in practice). I don't see why we need to go out of our way when it c= omes to these postquantum secrets. - How much support do we provide for nonstatic secrets, for exampl= e, by QKD, or via something like HIMMO (a key distribution mechanism that a= ppears to be post quantum)? o My opinion: I'd prefer it if we didn't spend a great deal of time tryin= g to come up with a solution that covers everything. However, if we could = include a hook that these schemes could take advantage of (such as an opaqu= e identifier that's passed that has meaning to the PPK manager), that might= be reasonable. - Authentication; if someone with a Quantum Computer can break the= DH in real time, do we care if he can act as a man-in-the-middle? o My opinion: this draft is here mainly to protect 'store-and-decrypt-lat= er' attacks, and so this attack isn't as large of a concern. On the other = hand, we may very well get this for free; if we include our 'post quantum s= ecret' as an input to the KDF, then an active attacker is foiled just like = a passive attacker. - Algorithm agility; how important is it that we negotiate any cry= ptoprimitives involved? o My opinion: this is of lesser importance, as this is a short term solut= ion. On the other hand, I am quite aware that others on this list would di= sagree with me... Well, here's my list of requirements (and my opinions); did I miss any requ= irement that you think is important? What are you opinions about these req= uirements? Thanks! --_000_9475723e788947debfbb36f23c40030eXCHRTP006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In Berlin, we decided to take up Quantum Resistance = as a work item, and that we should start talking about requirements.  = I’m starting this thread in a hope of kicking off the discussion.

 

First of all, a solution to Quantum Resistance that = is applicable everywhere would involve replacing the (EC)DH exchange with a= postquantum key exchange.  While this would be ideal, the cryptograph= ical community currently doesn’t have a solution that is sufficiently trusted and is of reasonable cost.  So,= it would make sense to divide this into two efforts, a long term solution = (which we may initially put on the shelf, as the crypto pieces aren’t= there yet), and a short term solution, to address the needs of customers that aren’t willing to wait; instead,= they feel the need to protect traffic that is encrypted now.  For thi= s short term solution, it’s sufficient if we don’t necessarily = cover all cases, a number of interesting cases (in particular, ones for which redistributing secrets is doable) would be sufficient. = ; Does everyone agree with that general assessment?

 

If so, there here is a list of potential requirement= s (based on Tero’s list that he gave during the IETF, but with a few = of my own), along with my opinion:

 

-     &= nbsp;    Simplicity; how large of a change to IKE (and IKE i= mplementations) are we willing to contemplate?

o   My opinion: minimizing changes to IKE should= be given high priority, both because “complexity is the enemy of sec= urity” and this is a short term solution; if we have a solution that = we can’t implement in a few years, well, we might as well wait for the crypto people to give us the long term one.

-     &= nbsp;    Preserving existing IKE properties; how important i= s it that our solution do not induce any weaknesses in IKE against an adver= sary with a convention computer; that is, whatever we do, we must not make = things worse?

o   My opinion: I’m pretty sure that we= 217;ll all agree that this is important (except for possibly the identity p= rotection, see below); I just want to state this as something we need to re= member.

-     &= nbsp;    What do we feel needs to protected from someone wit= h a Quantum Computer?  Do we feel  the need to protect only the I= Psec traffic, or do we need to protect the IKE traffic as well.<= /p>

o   My opinion: I’m going to abstain on th= is one, except to note that protecting only the IPsec traffic allows for a = rather simple implementation; now, if the WG decides that protecting the IK= E traffic is important, this simplicity is irrelevant.

-     &= nbsp;    What level of identity protection do we need to pro= vide?  If two different IKE negotiations use the same shared secret, d= o we mind if someone can deduce that?

o   My opinion: identity protection in IKE is ra= ther overrated; I suspect there’s enough in the data exchange that an= advanced adversary (how can look at things such as packet length and packe= t timings) is likely to get a fairly decent guess regardless.

-     &= nbsp;     PPK management; how much support do we provid= e for automatically managing the secrets?

o   My opinion: we already have preshared keys i= n IKE, and we don’t define any particular management scheme for them = (even though they are used quite often in practice).  I don’t se= e why we need to go out of our way when it comes to these postquantum secrets.

-     &= nbsp;    How much support do we provide for nonstatic secret= s, for example, by QKD, or via something like HIMMO (a key distribution mec= hanism that appears to be post quantum)?

o   My opinion: I’d prefer it if we didn&#= 8217;t spend a great deal of time trying to come up with a solution that co= vers everything.  However, if we could include a hook that these schem= es could take advantage of (such as an opaque identifier that’s passed that has meaning to the PPK manager), that might be re= asonable.

-     &= nbsp;    Authentication; if someone with a Quantum Computer = can break the DH in real time, do we care if he can act as a man-in-the-mid= dle?

o   My opinion: this draft is here mainly to pro= tect ‘store-and-decrypt-later’ attacks, and so this attack isn&= #8217;t as large of a concern.  On the other hand, we may very well ge= t this for free; if we include our ‘post quantum secret’ as an input to the KDF, then an active attacker is foiled just like a pass= ive attacker.

-     &= nbsp;    Algorithm agility; how important is it that we nego= tiate any cryptoprimitives involved?

o   My opinion: this is of lesser importance, as= this is a short term solution.  On the other hand, I am quite aware t= hat others on this list would disagree with me…

 

Well, here’s my list of requirements (and my o= pinions); did I miss any requirement that you think is important?  Wha= t are you opinions about these requirements?

 

Thanks!

--_000_9475723e788947debfbb36f23c40030eXCHRTP006ciscocom_-- From nobody Fri Aug 12 07:12:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7B12D0FF for ; Fri, 12 Aug 2016 07:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PFBEGSyELwun for ; Fri, 12 Aug 2016 07:12:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3F912D0E5 for ; Fri, 12 Aug 2016 07:12:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B545E199; Fri, 12 Aug 2016 10:23:26 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E577638D1; Fri, 12 Aug 2016 10:12:38 -0400 (EDT) From: Michael Richardson To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> References: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 14:12:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scott Fluhrer (sfluhrer) wrote: > - Simplicity; how large of a change to IKE (and IKE implementations) > are we willing to contemplate? > o My opinion: minimizing changes to IKE should be given high priority, > both because =E2=80=9Ccomplexity is the enemy of security=E2=80=9D an= d this is a short > term solution; if we have a solution that we can=E2=80=99t implement = in a few > years, well, we might as well wait for the crypto people to give us t= he > long term one. Still, I'd like to know what the properties are of the cryptographically lo= ng term solution. It seems to me, having read your email and a few of the documents that the long-term solutions are architecturally least disruptive, and the short-term "hacks" are more disruptive. Is this a fair characterisation? Or could we introduce some things now that would make "dropping in" a replacement easier? > - Preserving existing IKE properties; how important is it that our > solution do not induce any weaknesses in IKE against an adversary with > a convention computer; that is, whatever we do, we must not make thin= gs > worse? > o My opinion: I=E2=80=99m pretty sure that we=E2=80=99ll all agree th= at this is > important (except for possibly the identity protection, see below); I > just want to state this as something we need to remember. Yes, very very important. > - What do we feel needs to protected from someone with a Quantum > Computer? Do we feel the need to protect only the IPsec traffic, or do > we need to protect the IKE traffic as well. > o My opinion: I=E2=80=99m going to abstain on this one, except to not= e that > protecting only the IPsec traffic allows for a rather simple > implementation; now, if the WG decides that protecting the IKE traffic > is important, this simplicity is irrelevant. I think it depends upon what the affect on the IKE traffic is. > - What level of identity protection do we need to provide? If two > different IKE negotiations use the same shared secret, do we mind if > someone can deduce that? > o My opinion: identity protection in IKE is rather overrated; I suspe= ct > there=E2=80=99s enough in the data exchange that an advanced adversar= y (how can > look at things such as packet length and packet timings) is likely to > get a fairly decent guess regardless. I think you didn't answer the question you posed. You asked, "different IKE negotiations use the same shared secret, do we mi= nd if someone can deduce that?" which I don't think it strictly about identity protection. I also think that leaking the identity of a mobile end point effectively could be painting a target on them. Consider how much effort is going into IPv6 privacy extensions. > - PPK management; how much support do we provide for automatically > managing the secrets? > o My opinion: we already have preshared keys in IKE, and we don=E2=80= =99t > define any particular management scheme for them (even though they are > used quite often in practice). I don=E2=80=99t see why we need to go = out of our > way when it comes to these postquantum secrets. > - How much support do we provide for nonstatic secrets, for example, = by > QKD, or via something like HIMMO (a key distribution mechanism that > appears to be post quantum)? > o My opinion: I=E2=80=99d prefer it if we didn=E2=80=99t spend a grea= t deal of time > trying to come up with a solution that covers everything. However, if > we could include a hook that these schemes could take advantage of > (such as an opaque identifier that=E2=80=99s passed that has meaning = to the PPK > manager), that might be reasonable. Yes, I agree. > - Authentication; if someone with a Quantum Computer can break the DH > in real time, do we care if he can act as a man-in-the-middle? > o My opinion: this draft is here mainly to protect > =E2=80=98store-and-decrypt-later=E2=80=99 attacks, and so this attack= isn=E2=80=99t as large of > a concern. On the other hand, we may very well get this for free; if = we > include our =E2=80=98post quantum secret=E2=80=99 as an input to the = KDF, then an > active attacker is foiled just like a passive attacker. I think that this is important, if we can do it without getting into IKEv1 PSK stupids. > - Algorithm agility; how important is it that we negotiate any > cryptoprimitives involved? > o My opinion: this is of lesser importance, as this is a short term > solution. On the other hand, I am quite aware that others on this list > would disagree with me=E2=80=A6 > Well, here=E2=80=99s my list of requirements (and my opinions); did I= miss any > requirement that you think is important? What are you opinions about > these requirements? We have to be able to negotiate to use of these extensions. I want to suggest something further: that we might want to negotiate use of some of these extensions as a *rekey* of a "conventional" IKEv2 PARENT. I.e. even the use of these extensions might be too big a red flag. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV63ZU4CLcPvd0N1lAQLoDwf+Kxl2PVc8RwaN0LSqwSVOr4imyDO3+vyR 5m4yhCv5EztrQL4VYDArOR+p1VJKF4CZqz5yCy+mE6jogvxZrFCgQ0RhkcWxzD7i CIUFDUcu2OywTpOj9R9lHuSo1sT3XlvQfH3yHKSJSuKeNHTmSC+V+cK27fixd/p0 Vs3hsEvmV31IW9iKlACl8KJliyDckBoX52H+Tq4l3K2SBzIUH0b4egnqaNW0/miY iYGQ0AXLBPg+zXAZXCKjsTAwEOUq8NYXE1EicEy6xrrCzpE9SXeim12WP2Dt+Qcb 1SZ6rZlEaOW3+7Le2YA1Yj//Y+5tLAsMlBA8Ukhi3GOIM32eO82rbw== =EhzM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 12 07:33:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359B212D58D for ; Fri, 12 Aug 2016 07:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HR9SvqGTDU7M for ; Fri, 12 Aug 2016 07:33:28 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4E412D182 for ; Fri, 12 Aug 2016 07:33:27 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id f65so31319429wmi.0 for ; Fri, 12 Aug 2016 07:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=EsmgadclEV3TQptdG37x6xhg8B0QRb+2g/4axbgNqQY=; b=vGhLoG8hRPPlQgDeDwPsWxb278ojNi2CgmKeGpwAIJzOlkp4x504gHMg6d8QMtNt5Z F6hUwRY1wFuDntVWurvF1JuN+iLAg/ZVlKSAE3hwczjmtAXbNF+hFXUGO3fGWFAh/5cY 8IuyU4yN+CDAaAGjSJpyEjG0HviMPIU/y3QkMDROdhEtc4RrXWbtGVV98wlul+xfdEC3 LENmsCVskx/dc2X09E4HQYcNikHeIP0kt3aPGLzVE1EhpiaOGQTGNH0Kowju7yIorn/K vs7O2uQHp5L0iMG0DJHc0myTKfMINANUyZNGHg9n38Y5uYoeaTBKVPLJL+Vq00gQ14Az 9/Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EsmgadclEV3TQptdG37x6xhg8B0QRb+2g/4axbgNqQY=; b=dUNU1Asqpk3ND2Q8iUkR1wsCFgGTGG0RCkgP1QgWPj99WImG9puGHAelHC4voV1JnY IZ7fpAUqmYyMBra0SsQEF4+F+Ab51oYw7Pzo+ahfRyYAFZILDD332fTgw7FKpGdI8g9P tHa7URyzBcCzNxgOEOwq/tnZazfV1Ckw0p/HMclhliIi79AhOswxUxf3mqhHcHDNh5UP ijMrSejE8bK0eqVEmHrTCmZlFqRJu2wO/J+9mOz1bNTTFjy5GMJhtgvZlvy1mNDQzhrg gU6+d6O/CWZ6BHRv5rWA4VIb6qx/P3jy0Qk8BH4YJWZUuyfM6chqAPjHh2XCrTrC4GoW +RmA== X-Gm-Message-State: AEkoout0BiRv3NDyztRbp3iR+SLxH4fAwIgWVwzclSkf07MoLfMfTqtw+NT+glyI7vOEjw== X-Received: by 10.194.19.129 with SMTP id f1mr18179609wje.160.1471012405949; Fri, 12 Aug 2016 07:33:25 -0700 (PDT) Received: from [10.53.144.159] ([88.128.80.47]) by smtp.gmail.com with ESMTPSA id x6sm7823403wjk.26.2016.08.12.07.33.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 07:33:24 -0700 (PDT) To: Michael Richardson , "Scott Fluhrer (sfluhrer)" References: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> <26205.1471011158@obiwan.sandelman.ca> From: Yaron Sheffer Message-ID: Date: Fri, 12 Aug 2016 16:33:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <26205.1471011158@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 14:33:29 -0000 > > > Well, here’s my list of requirements (and my opinions); did I miss any > > requirement that you think is important? What are you opinions about > > these requirements? > > We have to be able to negotiate to use of these extensions. > I want to suggest something further: that we might want to negotiate use of > some of these extensions as a *rekey* of a "conventional" IKEv2 PARENT. > I.e. even the use of these extensions might be too big a red flag. > I really don't like the idea of a mandatory rekey to use these extensions, for two reasons: - This smells too much like SSL renegotiation, with issues like QR-security of the original SA vs. the new SA coming up. - I am sure a passive observer can distinguish an immediate rekey from normal IPsec traffic, just using packet lengths and timing. So the red flag is still there. Thanks, Yaron From nobody Fri Aug 12 09:41:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B7212D7D8 for ; Fri, 12 Aug 2016 09:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 tsVGILoel7gg for ; Fri, 12 Aug 2016 09:41:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0B612D7A0 for ; Fri, 12 Aug 2016 09:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14168; q=dns/txt; s=iport; t=1471020109; x=1472229709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yyNfLrqzFw3TxW9kZrhlys/POnYdJurz5rEin1y5YW4=; b=HKOPqP7pMEqVxkTCJGClGMLR71S6s1cyoBQYqP391TuE9hy485SK3zLR Sv5l/F4ELNahGWKWBx4lOqqQoznCQ7mTjoIXHNNN+tNfGRrboJJBq9L3N bOjR6zjnlk8HdC8e5TTx3UN9rWLbR9Mjz7CCcVQ42v1o02HWsm390FCE7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAgD9+61X/4YNJK1VCYNFgVIHuSaBf?= =?us-ascii?q?YYdAhyBKTgUAQEBAQEBAV0nhF4BAQQBIxFFDAQCAQgRBAEBAQICIwMCAgIwFAE?= =?us-ascii?q?ICAEBBA4FCBOIDgivJZAyAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSmDSoEDh?= =?us-ascii?q?BIHCgEzgmqCWgWZPAGPDYFyiA2FS4w1g3cBHjaCEhyBTG6FaA0XBxl/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,511,1464652800"; d="scan'208";a="310182773" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Aug 2016 16:41:48 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u7CGflX9023898 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Aug 2016 16:41:47 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 Aug 2016 12:41:46 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Fri, 12 Aug 2016 12:41:46 -0400 From: "Scott Fluhrer (sfluhrer)" To: Michael Richardson Thread-Topic: [IPsec] Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwAqVMAAAAXSNTA= Date: Fri, 12 Aug 2016 16:41:46 +0000 Message-ID: <60808678c1cd464495a915d91b935d58@XCH-RTP-006.cisco.com> References: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> <26205.1471011158@obiwan.sandelman.ca> In-Reply-To: <26205.1471011158@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 16:41:51 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pY2hhZWwgUmljaGFyZHNv biBbbWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYV0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3Qg MTIsIDIwMTYgMTA6MTMgQU0NCj4gVG86IFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKQ0KPiBDYzog SVBzZWNtZSBXRyAoaXBzZWNAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJlOiBbSVBzZWNdIFF1YW50 dW0gUmVzaXN0YW5jZSBSZXF1aXJlbWVudHMNCj4gDQo+IA0KPiBTY290dCBGbHVocmVyIChzZmx1 aHJlcikgPHNmbHVocmVyQGNpc2NvLmNvbT4gd3JvdGU6DQo+ICAgICA+IC0gU2ltcGxpY2l0eTsg aG93IGxhcmdlIG9mIGEgY2hhbmdlIHRvIElLRSAoYW5kIElLRSBpbXBsZW1lbnRhdGlvbnMpDQo+ ICAgICA+IGFyZSB3ZSB3aWxsaW5nIHRvIGNvbnRlbXBsYXRlPw0KPiANCj4gICAgID4gbyBNeSBv cGluaW9uOiBtaW5pbWl6aW5nIGNoYW5nZXMgdG8gSUtFIHNob3VsZCBiZSBnaXZlbiBoaWdoIHBy aW9yaXR5LA0KPiAgICAgPiBib3RoIGJlY2F1c2Ug4oCcY29tcGxleGl0eSBpcyB0aGUgZW5lbXkg b2Ygc2VjdXJpdHnigJ0gYW5kIHRoaXMgaXMgYSBzaG9ydA0KPiAgICAgPiB0ZXJtIHNvbHV0aW9u OyBpZiB3ZSBoYXZlIGEgc29sdXRpb24gdGhhdCB3ZSBjYW7igJl0IGltcGxlbWVudCBpbiBhIGZl dw0KPiAgICAgPiB5ZWFycywgd2VsbCwgd2UgbWlnaHQgYXMgd2VsbCB3YWl0IGZvciB0aGUgY3J5 cHRvIHBlb3BsZSB0byBnaXZlIHVzIHRoZQ0KPiAgICAgPiBsb25nIHRlcm0gb25lLg0KPiANCj4g U3RpbGwsIEknZCBsaWtlIHRvIGtub3cgd2hhdCB0aGUgcHJvcGVydGllcyBhcmUgb2YgdGhlIGNy eXB0b2dyYXBoaWNhbGx5IGxvbmcNCj4gdGVybSBzb2x1dGlvbi4gICAgSXQgc2VlbXMgdG8gbWUs IGhhdmluZyByZWFkIHlvdXIgZW1haWwgYW5kIGEgZmV3IG9mIHRoZQ0KPiBkb2N1bWVudHMgdGhh dCB0aGUgbG9uZy10ZXJtIHNvbHV0aW9ucyBhcmUgYXJjaGl0ZWN0dXJhbGx5IGxlYXN0IGRpc3J1 cHRpdmUsDQo+IGFuZCB0aGUgc2hvcnQtdGVybSAiaGFja3MiIGFyZSBtb3JlIGRpc3J1cHRpdmUu DQo+IA0KPiBJcyB0aGlzIGEgZmFpciBjaGFyYWN0ZXJpc2F0aW9uPw0KDQpTaW5jZSB3ZSBkb24n dCBoYXZlIGEgbG9uZyB0ZXJtIHNvbHV0aW9uIGluIGhhbmQsIHRvIGFuc3dlciB0aGF0IHdvdWxk IHJlcXVpcmUgc3BlY3VsYXRpb247IGlmIEkgZG8gaW5kdWxnZSBpbiB0aGF0LCBJJ2QgaGF2ZSB0 byBzYXkgdGhhdCBpdCdzIGEgYml0IG9uIHRoZSBtdXJreSBzaWRlDQoNCkFzIEkgbWVudGlvbmVk IGVhcmxpZXIsIHRoZSAibG9uZyB0ZXJtIiBzb2x1dGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgYW5v dGhlciAiRGlmZmllLUhlbGxtYW4gZ3JvdXAiLCB3aGljaCBpcyBub3QgcmVhbGx5IERIIGF0IGFs bCAob3IgYXQgbGVhc3QsIG5vdCBvbmx5IERIKSwgYnV0IGluY2x1ZGVzIHNvbWUgb3RoZXIga2V5 IGV4Y2hhbmdlIHByb3RvY29sOyB0aGUgZ3JvdXAgaXMgbmVnb3RpYXRlZCBqdXN0IGxpa2UgYW55 IG90aGVyIGdyb3VwLCBhbmQgdGhlIGluaXRpYXRvciBzZW5kcyBpdHMgS0UgcGF5bG9hZCwgdGhl IHJlc3BvbmRlciBzZW5kcyBpdHMgS0UgcGF5bG9hZCwgYW5kIGJvdGggc2lkZXMgZ2VuZXJhdGUg dGhlIHNoYXJlZCBzZWNyZXQuICBTbywgYXQgYSBwcm90b2NvbCBsZXZlbCwgZXZlcnl0aGluZyBy ZW1haW5zIGVzc2VudGlhbGx5IHRoZSBzYW1lIChhbmQgdGhlIHByb3RvY29sIGFsd2F5cyBtYWtl cyBpdCBjbGVhciBmb3IgZWFjaCBLRSBwYXlsb2FkIHdoZXRoZXIgaXQncyBhbiBpbml0aWF0b3Ig S0UgcGF5bG9hZCwgb3IgYSByZXNwb25zZSAoYW5kIGlmIGl0J3MgYSByZXNwb25zZSwgd2hpY2gg S0UgcGF5bG9hZCBpdCdzIGluIHJlc3BvbnNlIHRvKS4NCg0KSG93ZXZlciwgYXQgYW4gaW1wbGVt ZW50YXRpb24gbGV2ZWwsIHRoYXQncyBub3QgbmVjZXNzYXJpbHkgYXMgY2xlYW4uICBJJ3ZlIGdv bmUgdGhyb3VnaCBhIG51bWJlciBvZiAoYmVsaWV2ZWQpIHBvc3RxdWFudHVtIGtleSBleGNoYW5n ZXM7IG9uZSB0aGluZyBJIGhhdmUgbm90aWNlZCBpcyB0aG9zZSBwcm90b2NvbHMgYXJlIGFsbCBh c3ltbWV0cmljIGluIHNvbWUgd2F5LiAgV2l0aCAoRUMpREgsIGJvdGggc2lkZXMgZG8gZXhhY3Rs eSB0aGUgc2FtZSB0aGluZzsgZWFjaCBzaWRlIHBpY2tzIGEgc2VjcmV0IHZhbHVlICd4JywgY29t cHV0ZXMgJ2cqKngnLCBhbmQgdGhhdCdzIGl0cyBLRSB2YWx1ZTsgaXQgcmVjZWl2ZXMgdGhlICdn Kip5JyBLRSBwYXlsb2FkLCBhbmQgYWZ0ZXIgb3B0aW9uYWxseSB2YWxpZGF0aW5nIGl0LCBjb21w dXRlcyB0aGUgc2hhcmVkIHNlY3JldCBpbiBhIHVuaWZvcm0gbWFubmVyLiAgVGhpcyBzeW1tZXRy eSBpcyBub3QgdGhlcmUgaW4gYW55IHBvc3RxdWFudHVtIGtleSBleGNoYW5nZSBJJ3ZlIGxvb2tl ZCBhdDoNCg0KLSBXaXRoIExXRS1iYXNlZCBrZXkgZXhjaGFuZ2VzLCBib3RoIHNpZGVzIHNlbGVj dCBhIHNlY3JldCB2YWx1ZSBhbmQgYW4gZXJyb3IgdmVjdG9yOyBob3dldmVyIHRoZSByZXNwb25k ZXIgYWxzbyBzZW5kcyBzb21lIGFkZGl0aW9uYWwgZGF0YSBhbG9uZyB0byB0aGUgaW5pdGlhdG9y ICgibWFza2luZyBiaXRzIikgd2hpY2ggYWxsb3cgYm90aCBzaWRlcyB0byBkZXJpdmUgdGhlIHNh bWUgc2VjcmV0IChldmVuIHRob3VnaCBib3RoIHNpZGVzIGFkZCByYW5kb20gZXJyb3IgdmVjdG9y cyk7IHRoaXMgYWRkaXRpb25hbCBkYXRhIG5lZWRzIHRvIGJlIGNvbXB1dGVkIGluIHJlc3BvbnNl IHRvIHRoZSBpbml0aWF0b3IncyBLRSBwYXlsb2FkLCB3aGljaCBpbXBsaWVzIHRoYXQgKHVubGlr ZSBESCkgdGhlIHJlc3BvbmRlcidzIGNyeXB0byBjb2RlIG5lZWRzIGFjY2VzcyB0byB0aGUgaW5p dGlhdG9yJ3MgS0UgcGF5bG9hZCB3aGVuIGdlbmVyYXRpbmcgaXRzIEtFIHBheWxvYWQNCg0KLSBU aGVyZSBhcmUgYSBudW1iZXIgb2Ygc2NoZW1lcyB0aGF0IGFyZSByZWFsbHkgcHVibGljIGtleSBl bmNyeXB0aW9uIG1ldGhvZHM7IHRoZSBpbml0aWF0b3IncyBLRSBwYXlsb2FkIHJlYWxseSBpcyBh IHB1YmxpYyBlbmNyeXB0aW9uIGtleSwgYW5kIHRoZSByZXNwb25kZXIncyBLRSBwYXlsb2FkIGlz IGEgcmFuZG9tIHZhbHVlIGVuY3J5cHRlZCB3aXRoIHRoYXQgcHVibGljIGtleS4gIFRoaXMgd29y a3MganVzdCBmaW5lOyBob3dldmVyIGl0IGlzIG9idmlvdXNseSBhc3ltbWV0cmljLg0KDQotIFRo ZSBjbG9zZXN0IHRvIHRydWUgc3ltbWV0cnkgSSd2ZSBjb21lIGFjcm9zcyBpcyBTdXBlcnNpbmd1 bGFyIEVDIElzb2dlbnk7IHRoZXJlLCBib3RoIHNpZGUncyBLRSBwYXlsb2FkIGNhbiBiZSBwcm9k dWNlZCB3aXRob3V0IGFjY2VzcyB0byB0aGUgb3RoZXIgc2lkZSdzIEtFIHBheWxvYWQuICBPbiB0 aGUgb3RoZXIgaGFuZCwgYm90aCBzaWRlcyBuZWNlc3NhcmlseSBuZWVkIHRvIGJlIGluIGRpc3Rp bmN0IHJvbGVzICh0aGUgcmVmZXJlbmNlcyBJJ3ZlIHNlZW4gY2FsbGVkIHRoZW0gdGhlICJBbGlj ZSIgYW5kICJCb2IiIHJvbGUpLCBhbmQgc28gdGhlIHJlc3BvbmRlcidzIGNyeXB0byBjb2RlIG5l ZWRzIHRvIGtub3cgdGhhdCBpdCdzIGFjdGluZyBhcyBhIHJlc3BvbmRlci4NCg0KTXkgdGFrZS1h d2F5IGZyb20gdGhpcyBzcGVjdWxhdGlvbjsgd2hpbGUgaXQncyBxdWl0ZSBjbGVhbiBmcm9tIHRo ZSBwcm90b2NvbCBwZXJzcGVjdGl2ZSwgaXQgbWlnaHQgbm90IGVuZCB1cCBiZWluZyBxdWl0ZSBj bGVhbiBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgZXNwZWNpYWxseSBpZiB0 aGUgYXNzdW1wdGlvbiB0aGF0IHdlIGNhbiBnZW5lcmF0ZSBhIGtleSBzaGFyZSB3aXRob3V0IHJl ZmVyZW5jZSB0byBtdWNoIGVsc2UgKHdoaWNoIGlzIHRydWUgd2l0aCBESCkgaXMgYnVyaWVkIGZh aXJseSBkZWVwIGluIHRoZSBpbXBsZW1lbnRhdGlvbi4gIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0 aGUgcmVzcG9uZGVyIGltcGxlbWVudGF0aW9uIGhhcyBhIHNpbmdsZSAnaGVyZSdzIGEgS0UgcGF5 bG9hZCwgZ2VuZXJhdGUgYSByZXNwb25zZSBLRSBwYXlsb2FkIGFuZCB0aGUgc2hhcmVkIHNlY3Jl dCcgcHJpbWl0aXZlLCBpdCBtaWdodCBub3QgYmUgdGhhdCBiYWQuDQoNCjwvV2lsZFNwZWN1bGF0 aW9uPg0KDQpBcyBmb3IgdGhlIGRpc3J1cHRpdmVuZXNzIG9mIHRoZSBzaG9ydCB0ZXJtIGlkZWEs IHdlbGwsIGZyb20gYSBjcnlwdG8gcGVyc3BlY3RpdmUsIGl0J3MgYWN0dWFsbHkgZmFpcmx5IGNs ZWFuOyBvbmNlIHdlIGhhdmUgdGhlIHNlY3JldCwgd2Ugc3RpciB0aGF0IGFzIGFuIGlucHV0IHRv IHRoZSBLREYsIGFuZCB3ZSdyZSBnb29kOyB3aGF0J3MgYWN0dWFsbHkgZGlzcnVwdGl2ZSBpcyB0 aGUgbmVnb3RpYXRpb24gb2YgdGhlIHNlY3JldCAoYXJlIHdlIHVzaW5nIGEgc2VjcmV0IHdpdGgg dGhpcyBuZWdvYXRpaW9uPyAgSWYgc28sIHdoaWNoIG9uZT8pOyBpZiB3ZSBnbyB3aXRoIHRoZSBp ZGVhIHRoYXQgb25seSB0aGUgSVBzZWMgU0FzIG5lZWQgdG8gYmUgUVIsIHRoZW4gd2hlbiB3ZSBj b21wdXRlIHRoZSBLREYgZm9yIHRoZSBJUHNlYyBTQXMsIHdlIGtub3cgdGhlIG90aGVyIHNpZGUn cyBpZGVudGl0eSwgYW5kIHNvIHRoYXQgd291bGQgYmUgcmF0aGVyIHN0cmFpZ2h0LWZvcndhcmQu DQoNCg0KDQo+IA0KPiBPciBjb3VsZCB3ZSBpbnRyb2R1Y2Ugc29tZSB0aGluZ3Mgbm93IHRoYXQg d291bGQgbWFrZSAiZHJvcHBpbmcgaW4iIGENCj4gcmVwbGFjZW1lbnQgZWFzaWVyPw0KDQpOb3Ro aW5nIGNvbWVzIHRvIG1pbmQ7IGFjY29yZGluZyB0byB0aGUgYWJvdmUgd2lsZCBzcGVjdWxhdGlv biwgdGhlIGRpZmZpY3VsdGllcyB0aGF0IHBlb3BsZSBhcmUgbGlrZWx5IHRvIGVuY291bnRlciBh cmUgbW9yZSB0byBkbyB3aXRoIHRoZSBpbXBsZW1lbnRhdGlvbnMsIGFuZCBsZXNzIHdpdGggdGhl IHByb3RvY29sLg0KDQpBY3R1YWxseSwgdGhlcmUgYXJlIHNvbWUgaW50ZXJlc3RpbmcgcG9zdHF1 YW50dW0gcHJvdG9jb2xzIChlLmcuIE1jRWxpZWNlKSB3aGljaCBsb29rIGdvb2QsIGV4Y2VwdCB0 aGF0IHRoZXkgaGF2ZSBtYXNzaXZlbHkgbGFyZ2Uga2V5IHNoYXJlcy4gIEkndmUgY29uc2lkZXJl ZCB0aGVtIGltcHJhY3RpY2FsOyBob3dldmVyIGlmIHRoZXJlIHdhcyBzb21ldGhpbmcgZWFzeSB3 ZSBjb3VsZCBkbyB0byBtYWtlIHRob3NlIG1vcmUgcHJhY3RpY2FsLCB0aGF0IG1heSBoZWxwLiAg SSdtIG5vdCBzdWdnZXN0aW5nIHRoYXQgd2UgZG87IHlvdSBqdXN0IGFza2VkIGlmIHRoZXJlIHdh cyBhbnl0aGluZyB3ZSBtaWdodCBkbyB0aGF0IHdvdWxkIGhlbHAuLi4NCg0KPiANCj4gICAgID4g LSBQcmVzZXJ2aW5nIGV4aXN0aW5nIElLRSBwcm9wZXJ0aWVzOyBob3cgaW1wb3J0YW50IGlzIGl0 IHRoYXQgb3VyDQo+ICAgICA+IHNvbHV0aW9uIGRvIG5vdCBpbmR1Y2UgYW55IHdlYWtuZXNzZXMg aW4gSUtFIGFnYWluc3QgYW4gYWR2ZXJzYXJ5IHdpdGgNCj4gICAgID4gYSBjb252ZW50aW9uIGNv bXB1dGVyOyB0aGF0IGlzLCB3aGF0ZXZlciB3ZSBkbywgd2UgbXVzdCBub3QgbWFrZQ0KPiB0aGlu Z3MNCj4gICAgID4gd29yc2U/DQo+IA0KPiAgICAgPiBvIE15IG9waW5pb246IEnigJltIHByZXR0 eSBzdXJlIHRoYXQgd2XigJlsbCBhbGwgYWdyZWUgdGhhdCB0aGlzIGlzDQo+ICAgICA+IGltcG9y dGFudCAoZXhjZXB0IGZvciBwb3NzaWJseSB0aGUgaWRlbnRpdHkgcHJvdGVjdGlvbiwgc2VlIGJl bG93KTsgSQ0KPiAgICAgPiBqdXN0IHdhbnQgdG8gc3RhdGUgdGhpcyBhcyBzb21ldGhpbmcgd2Ug bmVlZCB0byByZW1lbWJlci4NCj4gDQo+IFllcywgdmVyeSB2ZXJ5IGltcG9ydGFudC4NCj4gDQo+ ICAgICA+IC0gV2hhdCBkbyB3ZSBmZWVsIG5lZWRzIHRvIHByb3RlY3RlZCBmcm9tIHNvbWVvbmUg d2l0aCBhIFF1YW50dW0NCj4gICAgID4gQ29tcHV0ZXI/IERvIHdlIGZlZWwgdGhlIG5lZWQgdG8g cHJvdGVjdCBvbmx5IHRoZSBJUHNlYyB0cmFmZmljLCBvciBkbw0KPiAgICAgPiB3ZSBuZWVkIHRv IHByb3RlY3QgdGhlIElLRSB0cmFmZmljIGFzIHdlbGwuDQo+IA0KPiAgICAgPiBvIE15IG9waW5p b246IEnigJltIGdvaW5nIHRvIGFic3RhaW4gb24gdGhpcyBvbmUsIGV4Y2VwdCB0byBub3RlIHRo YXQNCj4gICAgID4gcHJvdGVjdGluZyBvbmx5IHRoZSBJUHNlYyB0cmFmZmljIGFsbG93cyBmb3Ig YSByYXRoZXIgc2ltcGxlDQo+ICAgICA+IGltcGxlbWVudGF0aW9uOyBub3csIGlmIHRoZSBXRyBk ZWNpZGVzIHRoYXQgcHJvdGVjdGluZyB0aGUgSUtFIHRyYWZmaWMNCj4gICAgID4gaXMgaW1wb3J0 YW50LCB0aGlzIHNpbXBsaWNpdHkgaXMgaXJyZWxldmFudC4NCj4gDQo+IEkgdGhpbmsgaXQgZGVw ZW5kcyB1cG9uIHdoYXQgdGhlIGFmZmVjdCBvbiB0aGUgSUtFIHRyYWZmaWMgaXMuDQoNCkRvIHdl IGNhcmUgaWYgc29tZW9uZSB3aXRoIGEgUXVhbnR1bSBDb21wdXRlciBjYW4gZGVjcnlwdCB0aGUg SUtFIHRyYWZmaWM/DQoNCj4gDQo+ICAgICA+IC0gV2hhdCBsZXZlbCBvZiBpZGVudGl0eSBwcm90 ZWN0aW9uIGRvIHdlIG5lZWQgdG8gcHJvdmlkZT8gSWYgdHdvDQo+ICAgICA+IGRpZmZlcmVudCBJ S0UgbmVnb3RpYXRpb25zIHVzZSB0aGUgc2FtZSBzaGFyZWQgc2VjcmV0LCBkbyB3ZSBtaW5kIGlm DQo+ICAgICA+IHNvbWVvbmUgY2FuIGRlZHVjZSB0aGF0Pw0KPiANCj4gICAgID4gbyBNeSBvcGlu aW9uOiBpZGVudGl0eSBwcm90ZWN0aW9uIGluIElLRSBpcyByYXRoZXIgb3ZlcnJhdGVkOyBJIHN1 c3BlY3QNCj4gICAgID4gdGhlcmXigJlzIGVub3VnaCBpbiB0aGUgZGF0YSBleGNoYW5nZSB0aGF0 IGFuIGFkdmFuY2VkIGFkdmVyc2FyeSAoaG93DQo+IGNhbg0KPiAgICAgPiBsb29rIGF0IHRoaW5n cyBzdWNoIGFzIHBhY2tldCBsZW5ndGggYW5kIHBhY2tldCB0aW1pbmdzKSBpcyBsaWtlbHkgdG8N Cj4gICAgID4gZ2V0IGEgZmFpcmx5IGRlY2VudCBndWVzcyByZWdhcmRsZXNzLg0KPiANCj4gSSB0 aGluayB5b3UgZGlkbid0IGFuc3dlciB0aGUgcXVlc3Rpb24geW91IHBvc2VkLg0KPiBZb3UgYXNr ZWQsICJkaWZmZXJlbnQgSUtFIG5lZ290aWF0aW9ucyB1c2UgdGhlIHNhbWUgc2hhcmVkIHNlY3Jl dCwgZG8gd2UNCj4gbWluZCBpZg0KPiAgICAgICAgICAgIHNvbWVvbmUgY2FuIGRlZHVjZSB0aGF0 PyINCg0KPiANCj4gd2hpY2ggSSBkb24ndCB0aGluayBpdCBzdHJpY3RseSBhYm91dCBpZGVudGl0 eSBwcm90ZWN0aW9uLg0KPiBJIGFsc28gdGhpbmsgdGhhdCBsZWFraW5nIHRoZSBpZGVudGl0eSBv ZiBhIG1vYmlsZSBlbmQgcG9pbnQgZWZmZWN0aXZlbHkgY291bGQgYmUNCj4gcGFpbnRpbmcgYSB0 YXJnZXQgb24gdGhlbS4gIENvbnNpZGVyIGhvdyBtdWNoIGVmZm9ydCBpcyBnb2luZyBpbnRvDQo+ IElQdjYgcHJpdmFjeSBleHRlbnNpb25zLg0KDQpIZXJlJ3Mgd2hhdCBJJ20gY29uY2VybmVkIHdp dGg7IEFsaWNlIGNvbm5lY3RzIChmcm9tIFN0YXJidWNrcykgdG8gQm9iLCB1c2luZyB0aGVpciBq b2ludGx5IHNoYXJlZCBQUEsuICBBbGljZSB0aGVuIGdvZXMgdG8gTWNEb25hbGQsIHRoZW4gYWxz byBjb25uZWN0cyB0byBCb2IsIHVzaW5nIHRoZWlyIGpvaW50bHkgc2hhcmVkIFBQSy4gIE15IHF1 ZXN0aW9uOiBhcmUgd2UgY29uY2VybmVkIGlmIHNvbWVvbmUgbGlzdGVuaW5nIGludG8gdGhlIElL RSBuZWdvdGlhdGlvbnMsIGNvdWxkIGRldGVybWluZSB3aGV0aGVyIHRoZSBQUEsgQWxpY2UgdXNl ZCBmcm9tIFN0YXJidWNrcyBpcyB0aGUgc2FtZSBhcyB0aGUgb25lIHNoZSB1c2VkIGZyb20gTWNE b25hbGRzIChhbmQgZnJvbSB0aGF0LCBkZWR1Y2UgdGhhdCBpdCdzIGxpa2VseSB0aGF0IHRoZSBz YW1lIHBlcnNvbiB3YXMgYXQgYm90aCBTdGFyYnVja3MgYW5kIE1jRG9uYWxkcyk/DQoNCj4gDQo+ IA0KPiAgICAgPiAtIEhvdyBtdWNoIHN1cHBvcnQgZG8gd2UgcHJvdmlkZSBmb3Igbm9uc3RhdGlj IHNlY3JldHMsIGZvciBleGFtcGxlLCBieQ0KPiAgICAgPiBRS0QsIG9yIHZpYSBzb21ldGhpbmcg bGlrZSBISU1NTyAoYSBrZXkgZGlzdHJpYnV0aW9uIG1lY2hhbmlzbSB0aGF0DQo+ICAgICA+IGFw cGVhcnMgdG8gYmUgcG9zdCBxdWFudHVtKT8NCj4gDQo+ICAgICA+IG8gTXkgb3BpbmlvbjogSeKA mWQgcHJlZmVyIGl0IGlmIHdlIGRpZG7igJl0IHNwZW5kIGEgZ3JlYXQgZGVhbCBvZiB0aW1lDQo+ ICAgICA+IHRyeWluZyB0byBjb21lIHVwIHdpdGggYSBzb2x1dGlvbiB0aGF0IGNvdmVycyBldmVy eXRoaW5nLiBIb3dldmVyLCBpZg0KPiAgICAgPiB3ZSBjb3VsZCBpbmNsdWRlIGEgaG9vayB0aGF0 IHRoZXNlIHNjaGVtZXMgY291bGQgdGFrZSBhZHZhbnRhZ2Ugb2YNCj4gICAgID4gKHN1Y2ggYXMg YW4gb3BhcXVlIGlkZW50aWZpZXIgdGhhdOKAmXMgcGFzc2VkIHRoYXQgaGFzIG1lYW5pbmcgdG8g dGhlIFBQSw0KPiAgICAgPiBtYW5hZ2VyKSwgdGhhdCBtaWdodCBiZSByZWFzb25hYmxlLg0KPiAN Cj4gWWVzLCBJIGFncmVlLg0KPiANCj4gICAgID4gLSBBdXRoZW50aWNhdGlvbjsgaWYgc29tZW9u ZSB3aXRoIGEgUXVhbnR1bSBDb21wdXRlciBjYW4gYnJlYWsgdGhlDQo+IERIDQo+ICAgICA+IGlu IHJlYWwgdGltZSwgZG8gd2UgY2FyZSBpZiBoZSBjYW4gYWN0IGFzIGEgbWFuLWluLXRoZS1taWRk bGU/DQo+IA0KPiAgICAgPiBvIE15IG9waW5pb246IHRoaXMgZHJhZnQgaXMgaGVyZSBtYWlubHkg dG8gcHJvdGVjdA0KPiAgICAgPiDigJhzdG9yZS1hbmQtZGVjcnlwdC1sYXRlcuKAmSBhdHRhY2tz LCBhbmQgc28gdGhpcyBhdHRhY2sgaXNu4oCZdCBhcyBsYXJnZSBvZg0KPiAgICAgPiBhIGNvbmNl cm4uIE9uIHRoZSBvdGhlciBoYW5kLCB3ZSBtYXkgdmVyeSB3ZWxsIGdldCB0aGlzIGZvciBmcmVl OyBpZiB3ZQ0KPiAgICAgPiBpbmNsdWRlIG91ciDigJhwb3N0IHF1YW50dW0gc2VjcmV04oCZIGFz IGFuIGlucHV0IHRvIHRoZSBLREYsIHRoZW4gYW4NCj4gICAgID4gYWN0aXZlIGF0dGFja2VyIGlz IGZvaWxlZCBqdXN0IGxpa2UgYSBwYXNzaXZlIGF0dGFja2VyLg0KPiANCj4gSSB0aGluayB0aGF0 IHRoaXMgaXMgaW1wb3J0YW50LCBpZiB3ZSBjYW4gZG8gaXQgd2l0aG91dCBnZXR0aW5nIGludG8g SUtFdjEgUFNLDQo+IHN0dXBpZHMuDQoNClRoYXQgYnJpbmdzIHVwIGFub3RoZXIgcG90ZW50aWFs IHJlcXVpcmVtZW50IChhbHRob3VnaCBJJ20gbm90IGNlcnRhaW4gaG93IHRvIGV4cHJlc3MgaXQp OyBzb21ldGhpbmcgbGlrZSAiaG93IGltcG9ydGFudCBpcyBpdCB0byBhdm9pZCB0aGUgcHJvYmxl bXMgdGhhdCBJS0V2MSBoYWQgd2l0aCBwcmVzaGFyZWQga2V5cyIgKGFsdGhvdWdoIGEgY29ycmVj dCBzdGF0ZW1lbnQgb2YgdGhlIHJlcXVpcmVtZW50IHdvdWxkIGxpc3QgZXhhY3RseSB3aGF0IHBy b2JsZW1zIHdlJ3JlIHNlZWtpbmcgdG8gYXZvaWQpDQoNCj4gDQo+ICAgICA+IC0gQWxnb3JpdGht IGFnaWxpdHk7IGhvdyBpbXBvcnRhbnQgaXMgaXQgdGhhdCB3ZSBuZWdvdGlhdGUgYW55DQo+ICAg ICA+IGNyeXB0b3ByaW1pdGl2ZXMgaW52b2x2ZWQ/DQo+IA0KPiAgICAgPiBvIE15IG9waW5pb246 IHRoaXMgaXMgb2YgbGVzc2VyIGltcG9ydGFuY2UsIGFzIHRoaXMgaXMgYSBzaG9ydCB0ZXJtDQo+ ICAgICA+IHNvbHV0aW9uLiBPbiB0aGUgb3RoZXIgaGFuZCwgSSBhbSBxdWl0ZSBhd2FyZSB0aGF0 IG90aGVycyBvbiB0aGlzIGxpc3QNCj4gICAgID4gd291bGQgZGlzYWdyZWUgd2l0aCBtZeKApg0K PiANCj4gICAgID4gV2VsbCwgaGVyZeKAmXMgbXkgbGlzdCBvZiByZXF1aXJlbWVudHMgKGFuZCBt eSBvcGluaW9ucyk7IGRpZCBJIG1pc3MgYW55DQo+ICAgICA+IHJlcXVpcmVtZW50IHRoYXQgeW91 IHRoaW5rIGlzIGltcG9ydGFudD8gV2hhdCBhcmUgeW91IG9waW5pb25zIGFib3V0DQo+ICAgICA+ IHRoZXNlIHJlcXVpcmVtZW50cz8NCj4gDQo+IFdlIGhhdmUgdG8gYmUgYWJsZSB0byBuZWdvdGlh dGUgdG8gdXNlIG9mIHRoZXNlIGV4dGVuc2lvbnMuDQo+IEkgd2FudCB0byBzdWdnZXN0IHNvbWV0 aGluZyBmdXJ0aGVyOiB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gbmVnb3RpYXRlIHVzZSBvZg0KPiBz b21lIG9mIHRoZXNlIGV4dGVuc2lvbnMgYXMgYSAqcmVrZXkqIG9mIGEgImNvbnZlbnRpb25hbCIg SUtFdjIgUEFSRU5ULg0KPiBJLmUuIGV2ZW4gdGhlIHVzZSBvZiB0aGVzZSBleHRlbnNpb25zIG1p Z2h0IGJlIHRvbyBiaWcgYSByZWQgZmxhZy4NCg0KQW5vdGhlciBwb3RlbnRpYWwgcmVxdWlyZW1l bnQ6IGRvIHdlIGNhcmUgaWYgc29tZW9uZSBsaXN0ZW5pbmcgaW4gY2FuIGRldGVybWluZSB3aGV0 aGVyIHdlJ3JlIHVzaW5nIHRoaXMgZXh0ZW5zaW9uPw0KDQo= From nobody Fri Aug 12 17:45:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03C712D92F for ; Fri, 12 Aug 2016 17:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 iw88aKp6g2Eu for ; Fri, 12 Aug 2016 17:45:39 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39AC12D0A1 for ; Fri, 12 Aug 2016 17:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1471049139; x=2334962739; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DUMpar9Rd+hUFaqTXisFI3PSF8uAYpYyu0bOcGsEZb4=; b=wcUOamb/HQ2nYQOf2OeSEcYW2zY7fRhpCueLe235EIhP/6/LO7qI4iN+6jO/IDnA 3XCBSI/z88jP7xIFS6kxEoTpAi5iIyKv1dCBhyYMGM5AxU/Orjy38SaC5Q6QiwnL QcudFWW9pElbAOtQQr+S2U6btDkTU20sV+c5uH0YbfE9rrdRNofal1gH5P2u3c2u PvdsXWza67iuvVncdkaIz3iYtUcX5XvDO+uKXQUT9/IsnmRtRKvMYltsUEcGjls5 h8qNdyfVr/yzkiIydDj1aAzkij1lIMa10OMpsth814dVMO/TyVdrPPYE3HXeslwV arS7PQZhk/aQ2Q2EC/Am3A==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id A9.1C.10360.3BD6EA75; Fri, 12 Aug 2016 17:45:39 -0700 (PDT) X-AuditID: 11973e11-f79e76d000002878-4c-57ae6db3c9bd Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 15.42.04819.3BD6EA75; Fri, 12 Aug 2016 17:45:39 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_W3A4iSjNRlazkFiGfLNOAQ)" Received: from [17.153.34.234] (unknown [17.153.34.234]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OBT007J1OS0ZZ50@nwk-mmpp-sz07.apple.com>; Fri, 12 Aug 2016 17:45:39 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <6C7E8017-895F-4141-8A68-09C57F08F559@apple.com> Date: Fri, 12 Aug 2016 17:45:36 -0700 In-reply-to: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> To: "Scott Fluhrer (sfluhrer)" References: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUi2FAYpbs5d124wZzlUhb7t7xgs5ja4ufA 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZWz6dI6t4PELxopbp3czNzD2nGDsYuTkkBAw kXh5eyMrhC0mceHeerYuRi4OIYG9jBIHV/ezwBQtfrOJGSJxiFHi9aP5YAleAUGJH5PvgdnM AmESHU97WSGKupgkmrc3M3UxcnAIC0hIbN6TCFLDJqAicfzbBmaIXhuJE6++MIHYwkALpu9d BBZnEVCVaL3VBWZzCrhK3N+zlAlivpFE48eDYJeKCBhLdJ74zQZiCwm4SHy5tg3qG1mJRcev gN0gIXCCTaL302SWCYzCs5DcOgvJrbOAzmMWUJeYMiUXIqwt8eTdBVYIW01i4e9FTMjiCxjZ VjEK5SZm5uhm5hnpJRYU5KTqJefnbmIERcl0O8EdjMdXWR1iFOBgVOLh/cC5LlyINbGsuDL3 EKM0B4uSOK+i+NpwIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyrDXx7pV9ffVlxreP4LdZT sS6Fnptmh7zpsZY6OpXD7KPaKs5ZMQl2ChFfd7/i3/KrZq7Z05+7/rd3TrU7NdFml2qW1Kou N2Pm828SGztTsuVYCnf3HeJ7uD7sdtTdDyel1j0tuF8we/sM1gdGS59WzrkXq7RfPHu3agXj +3u/u29+/yH55tJxJZbijERDLeai4kQAZtU4LHMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUi2FD8QXdz7rpwg0+TBCz2b3nBZjG1xc+B yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgytj06RxbweMXjBW3Tu9mbmDsOcHYxcjJISFg IrH4zSZmCFtM4sK99WxdjFwcQgKHGCVeP5rPApLgFRCU+DH5HpjNLBAm0fG0lxWiqItJonl7 M1MXIweHsICExOY9iSA1bAIqEse/bWCG6LWROPHqCxOILQy0bPreRWBxFgFVidZbXWA2p4Cr xP09S5kg5htJNH48yApiiwgYS3Se+M0GYgsJuEh8ubYN6mhZiUXHr7BOYBSYheS8WUjOmwV0 EbOAusSUKbkQYW2JJ+8usELYahILfy9iQhZfwMi2ilGgKDUnsdJML7GgICdVLzk/dxMjOKgL o3YwNiy3OsQowMGoxMP7gXNduBBrYllxZS4wjDiYlUR4C7OAQrwpiZVVqUX58UWlOanFhxgn MgI9OZFZSjQ5HxhzeSXxhiYmBibGxmbGxuYm5rQUVhLnve0EdJFAemJJanZqakFqEcxRTByc Ug2M3it9Jq+YmfNba+OUn8fOF2vGf/jSkt2yw+/Fr4jVX80fNkXP9w58fj7mXnjJqZ+eRmYb JLYvKuA+IeZ7t0HZlfH5kearHhc37gmwOnNZPWyT48uW6U8a/jnHcb3Z+5CT7dCFwvqjYrkP eryKXhqXb1OM2Rz2eStv2rnJZhtfcv+vdOv/e0/VXomlOCPRUIu5qDgRAIvnKETdAgAA Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 00:45:41 -0000 --Boundary_(ID_W3A4iSjNRlazkFiGfLNOAQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Scott, Great list! Responses inline. Best, Tommy > On Aug 11, 2016, at 3:00 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 > In Berlin, we decided to take up Quantum Resistance as a work item, = and that we should start talking about requirements. I=E2=80=99m = starting this thread in a hope of kicking off the discussion. > =20 > First of all, a solution to Quantum Resistance that is applicable = everywhere would involve replacing the (EC)DH exchange with a = postquantum key exchange. While this would be ideal, the = cryptographical community currently doesn=E2=80=99t have a solution that = is sufficiently trusted and is of reasonable cost. So, it would make = sense to divide this into two efforts, a long term solution (which we = may initially put on the shelf, as the crypto pieces aren=E2=80=99t = there yet), and a short term solution, to address the needs of customers = that aren=E2=80=99t willing to wait; instead, they feel the need to = protect traffic that is encrypted now. For this short term solution, = it=E2=80=99s sufficient if we don=E2=80=99t necessarily cover all cases, = a number of interesting cases (in particular, ones for which = redistributing secrets is doable) would be sufficient. Does everyone = agree with that general assessment? > =20 > If so, there here is a list of potential requirements (based on = Tero=E2=80=99s list that he gave during the IETF, but with a few of my = own), along with my opinion: > =20 > - Simplicity; how large of a change to IKE (and IKE = implementations) are we willing to contemplate? > o My opinion: minimizing changes to IKE should be given high = priority, both because =E2=80=9Ccomplexity is the enemy of security=E2=80=9D= and this is a short term solution; if we have a solution that we = can=E2=80=99t implement in a few years, well, we might as well wait for = the crypto people to give us the long term one. Simplicity is definitely crucial to whatever solution we choose, and I = think the current proposal of a pre shared key that gets mixed into the = crypto is the simplest option we have now without really knowing what = true QR algorithms will entail for IKE. > - Preserving existing IKE properties; how important is it = that our solution do not induce any weaknesses in IKE against an = adversary with a convention computer; that is, whatever we do, we must = not make things worse? > o My opinion: I=E2=80=99m pretty sure that we=E2=80=99ll all agree = that this is important (except for possibly the identity protection, see = below); I just want to state this as something we need to remember. Definitely important.=20 > - What do we feel needs to protected from someone with a = Quantum Computer? Do we feel the need to protect only the IPsec = traffic, or do we need to protect the IKE traffic as well. > o My opinion: I=E2=80=99m going to abstain on this one, except to = note that protecting only the IPsec traffic allows for a rather simple = implementation; now, if the WG decides that protecting the IKE traffic = is important, this simplicity is irrelevant. My first reaction would be to focus on the IPSec traffic, which is = clearly important. It's not clear yet if IKE being protected is useful; = exactly how much more complicated will the exchange be, and is it worth = it? > - What level of identity protection do we need to provide? = If two different IKE negotiations use the same shared secret, do we mind = if someone can deduce that? > o My opinion: identity protection in IKE is rather overrated; I = suspect there=E2=80=99s enough in the data exchange that an advanced = adversary (how can look at things such as packet length and packet = timings) is likely to get a fairly decent guess regardless. I agree that the aspect of identity protection is already a bit of a = lost cause for this, and the new key will not significantly worsen the = situation. > - PPK management; how much support do we provide for = automatically managing the secrets? > o My opinion: we already have preshared keys in IKE, and we don=E2=80=99= t define any particular management scheme for them (even though they are = used quite often in practice). I don=E2=80=99t see why we need to go = out of our way when it comes to these postquantum secrets. The management seems like a separate issue for deployments to figure = out. I can imagine guidelines being published later, but let's just get = the crypto spec out first. > - How much support do we provide for nonstatic secrets, for = example, by QKD, or via something like HIMMO (a key distribution = mechanism that appears to be post quantum)? > o My opinion: I=E2=80=99d prefer it if we didn=E2=80=99t spend a = great deal of time trying to come up with a solution that covers = everything. However, if we could include a hook that these schemes = could take advantage of (such as an opaque identifier that=E2=80=99s = passed that has meaning to the PPK manager), that might be reasonable. > - Authentication; if someone with a Quantum Computer can = break the DH in real time, do we care if he can act as a = man-in-the-middle? > o My opinion: this draft is here mainly to protect = =E2=80=98store-and-decrypt-later=E2=80=99 attacks, and so this attack = isn=E2=80=99t as large of a concern. On the other hand, we may very = well get this for free; if we include our =E2=80=98post quantum = secret=E2=80=99 as an input to the KDF, then an active attacker is = foiled just like a passive attacker. > - Algorithm agility; how important is it that we negotiate = any cryptoprimitives involved? > o My opinion: this is of lesser importance, as this is a short term = solution. On the other hand, I am quite aware that others on this list = would disagree with me=E2=80=A6 I generally agree with Scott on these points. > =20 > Well, here=E2=80=99s my list of requirements (and my opinions); did I = miss any requirement that you think is important? What are you opinions = about these requirements? > =20 > Thanks! > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_W3A4iSjNRlazkFiGfLNOAQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Scott,

Great list! Responses inline.

Best,
Tommy


On = Aug 11, 2016, at 3:00 PM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> = wrote:

In Berlin, we decided to = take up Quantum Resistance as a work item, and that we should start = talking about requirements.  I=E2=80=99m starting this thread in a = hope of kicking off the discussion.
 
First of all, a solution to Quantum = Resistance that is applicable everywhere would involve replacing the = (EC)DH exchange with a postquantum key exchange.  While this would = be ideal, the cryptographical community currently doesn=E2=80=99t have a = solution that is sufficiently trusted and is of reasonable cost.  = So, it would make sense to divide this into two efforts, a long term = solution (which we may initially put on the shelf, as the crypto pieces = aren=E2=80=99t there yet), and a short term solution, to address the = needs of customers that aren=E2=80=99t willing to wait; instead, they = feel the need to protect traffic that is encrypted now.  For this = short term solution, it=E2=80=99s sufficient if we don=E2=80=99t = necessarily cover all cases, a number of interesting cases (in = particular, ones for which redistributing secrets is doable) would be = sufficient.  Does everyone agree with that general assessment?
 
If so, = there here is a list of potential requirements (based on Tero=E2=80=99s = list that he gave during the IETF, but with a few of my own), along with = my opinion:
 
-          Simplicity; = how large of a change to IKE (and IKE implementations) are we willing to = contemplate?
o   My = opinion: minimizing changes to IKE should be given high priority, both = because =E2=80=9Ccomplexity is the enemy of security=E2=80=9D and this = is a short term solution; if we have a solution that we can=E2=80=99t = implement in a few years, well, we might as well wait for the crypto = people to give us the long term = one.

Simplicity is definitely crucial to whatever = solution we choose, and I think the current proposal of a pre shared key = that gets mixed into the crypto is the simplest option we have now = without really knowing what true QR algorithms will entail for = IKE.

-          Preserving = existing IKE properties; how important is it that our solution do not = induce any weaknesses in IKE against an adversary with a convention = computer; that is, whatever we do, we must not make things worse?
o   My = opinion: I=E2=80=99m pretty sure that we=E2=80=99ll all agree that this = is important (except for possibly the identity protection, see below); I = just want to state this as something we need to = remember.

Definitely important. 

-          What do we = feel needs to protected from someone with a Quantum Computer?  Do = we feel  the need to protect only the IPsec traffic, or do we need = to protect the IKE traffic as well.
o   My = opinion: I=E2=80=99m going to abstain on this one, except to note that = protecting only the IPsec traffic allows for a rather simple = implementation; now, if the WG decides that protecting the IKE traffic = is important, this simplicity is = irrelevant.

My first reaction would be to focus on the IPSec = traffic, which is clearly important. It's not clear yet if IKE being = protected is useful; exactly how much more complicated will the exchange = be, and is it worth it?

-          What level of = identity protection do we need to provide?  If two different IKE = negotiations use the same shared secret, do we mind if someone can = deduce that?
o   My = opinion: identity protection in IKE is rather overrated; I suspect = there=E2=80=99s enough in the data exchange that an advanced adversary = (how can look at things such as packet length and packet timings) is = likely to get a fairly decent guess = regardless.

I= agree that the aspect of identity protection is already a bit of a lost = cause for this, and the new key will not significantly worsen the = situation.


-           PPK = management; how much support do we provide for automatically managing = the secrets?
o   My = opinion: we already have preshared keys in IKE, and we don=E2=80=99t = define any particular management scheme for them (even though they are = used quite often in practice).  I don=E2=80=99t see why we need to = go out of our way when it comes to these postquantum = secrets.

The = management seems like a separate issue for deployments to figure out. I = can imagine guidelines being published later, but let's just get the = crypto spec out first.

-          How much = support do we provide for nonstatic secrets, for example, by QKD, or via = something like HIMMO (a key distribution mechanism that appears to be = post quantum)?
o   My = opinion: I=E2=80=99d prefer it if we didn=E2=80=99t spend a great deal = of time trying to come up with a solution that covers everything.  = However, if we could include a hook that these schemes could take = advantage of (such as an opaque identifier that=E2=80=99s passed that = has meaning to the PPK manager), that might be reasonable.
-          Authentication;= if someone with a Quantum Computer can break the DH in real time, do we = care if he can act as a man-in-the-middle?
o   My = opinion: this draft is here mainly to protect = =E2=80=98store-and-decrypt-later=E2=80=99 attacks, and so this attack = isn=E2=80=99t as large of a concern.  On the other hand, we may = very well get this for free; if we include our =E2=80=98post quantum = secret=E2=80=99 as an input to the KDF, then an active attacker is = foiled just like a passive attacker.
-          Algorithm = agility; how important is it that we negotiate any cryptoprimitives = involved?
o   My = opinion: this is of lesser importance, as this is a short term = solution.  On the other hand, I am quite aware that others on this = list would disagree with me=E2=80=A6
I generally agree with Scott on these = points.

 
Well, here=E2=80=99s my list of requirements (and my = opinions); did I miss any requirement that you think is important?  = What are you opinions about these requirements?
 
Thanks!
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_W3A4iSjNRlazkFiGfLNOAQ)-- From nobody Wed Aug 17 10:22:09 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 694A012D969; Wed, 17 Aug 2016 10:22:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147145452839.23694.1664258079642996229.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 10:22:08 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:22:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-02.txt Pages : 20 Date : 2016-08-17 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 17 10:46:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA312D954 for ; Wed, 17 Aug 2016 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.338 X-Spam-Level: X-Spam-Status: No, score=-5.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.com 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 4UOAva6QLFj5 for ; Wed, 17 Aug 2016 10:46:43 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA9512DBD4 for ; Wed, 17 Aug 2016 10:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1471456002; x=2335369602; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uIj2PKCJdnA0MICJ3wyFZ4JWH6g1pzQZFQ6+Li86UEs=; b=Cx25bFrxuqHtCUVtCKCZEHwyUcTsISl4K3DF/HzZGbxxwwDGcNBu0j4P5Fti8dhq T01lDWgNK2yZuEO8sc5FTFTtg9+qgbubExyJAJLnu683g9hZcT3GqW++IuJitvAS uKlNJPjyWL8+2kodZmfh+dD9Sp9R8wBWSOshtpixdkXiUY0G8D5hW12y7Y81JNSw HbhbubwZ5UUtlX/QpmKJ8YEF96VoltrABGzAs90mz3t6GGRQIhpalMM2MwtbSwJ+ zVS5yyWDjxqXbUczTg4OWwO6sGGT4I2dZvE+UD+pBJRX3b1nrqs5b4gVSmVVmV2/ GDYP67tPfPDRrr8hqJmX9g==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 71.60.10360.203A4B75; Wed, 17 Aug 2016 10:46:42 -0700 (PDT) X-AuditID: 11973e11-f79e76d000002878-b0-57b4a302a21c Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id F0.D2.01452.203A4B75; Wed, 17 Aug 2016 10:46:42 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4+jseVoOnsE16Y5tLC8NzQ)" Received: from [17.226.23.74] (unknown [17.226.23.74]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OC200LX8EPTFP10@nwk-mmpp-sz12.apple.com>; Wed, 17 Aug 2016 10:46:42 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <54D3E0AE-8912-4E1A-835B-664CEFCC4387@apple.com> Date: Wed, 17 Aug 2016 10:46:41 -0700 In-reply-to: To: Daniel Migault References: X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUi2FDorMu0eEu4waKvmhZTpu9hs9i/5QWb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJUx8btNwaqXjBWNb7ayNTCuPMjYxcjJISFg IrFi2VkWCFtM4sK99WxdjFwcQgJ7GSXmXmqAK9qxcjcLROIQUGLnZCaQBK+AoMSPyffAupkF wiRuLZ/ABFHUwSTxcW4/UDcHh7CAhMTmPYkgNWwCKhLHv21ghui1kXg54TNYr7CAg8S3E8vZ QGwWAVWJSfMPgsU5BYIl5v/ZwQYxX1Vi1oTbYHtFBAyAeneCxYUEAiRm/rvCDnGorMSi41dY QW6QELjMJjH9yRumCYzCs5DcOgvJrRC2lsT3R61AcQ4gW17i4HlZiLCmxLN7n9ghbG2JJ+8u sC5gZFvFKJSbmJmjm5lnpJdYUJCTqpecn7uJERQl0+0EdzAeX2V1iFGAg1GJh3fH1C3hQqyJ ZcWVuYcYpTlYlMR5/07YHC4kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsbP2yqrXa1gZs9ik P6g92MQ6y39LnsivB9MMWaWPqBudPM0svn6K8pbaW0vEzdKzjrnY3XdhWRBRtjEu0uooR6z4 g2efr3hWbey9kvTzlBoju/gz7TmPJPunnhfTYzpmqMPlFNh260Tm6duG+h82fNAp0vq788a/ DF0ztrhv5jVJSzh+tVQdUWIpzkg01GIuKk4EAOMO9CNzAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUi2FB8Rpdp8ZZwg129UhZTpu9hs9i/5QWb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJUx8btNwaqXjBWNb7ayNTCuPMjYxcjJISFg IrFj5W4WCFtM4sK99WxdjFwcQgKHGCXm7pzMBJLgFRCU+DH5HlgRs0CYxK3lE5ggijqYJD7O 7QeaxMEhLCAhsXlPIkgNm4CKxPFvG5ghem0kXk74DNYrLOAg8e3EcjYQm0VAVWLS/INgcU6B YIn5f3awQcxXlZg14TbYXhEBA6DenWBxIYEAiZn/rrBDHCorsej4FdYJjAKzkJw3C8l5ELaW xPdHrUBxDiBbXuLgeVmIsKbEs3uf2CFsbYkn7y6wLmBkW8UoUJSak1hppJdYUJCTqpecn7uJ ERzUhc47GI8tszrEKMDBqMTDKzBjS7gQa2JZcWUuMIw4mJVEeEXnAIV4UxIrq1KL8uOLSnNS iw8xTmQEenIis5Rocj4w5vJK4g1NTAxMjI3NjI3NTcxpKawkzntJeXO4kEB6YklqdmpqQWoR zFFMHJxSDYwKKUXFDnP0d3Po5v5JtLOd4H+7eHlH2GWVG2WbPa9yX3T4rFujZpCgNq3z4Odr Hj8O7Hkiduub5dODSw5Ec01zca1V+BO9ef+ZC7mVF5IXzpqipGLH+Sz7VYZV1b4JXc2HTZxP f7nefjRkXVzx+w/LV6w0cF1w7lops05HfdKzpXKFarrPL2QrsRRnJBpqMRcVJwIAiocuat0C AAA= Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] review for draft-ietf-ipsecme-tcp-encaps-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:46:48 -0000 --Boundary_(ID_4+jseVoOnsE16Y5tLC8NzQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Daniel, Thanks for the in-depth review! I've incorporated your comments into a new update: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02 . Specific responses to your comments inline! Any other comments are welcome on the new version. I agree with Daniel that we're in good shape to go into WGLC. Best, Tommy > On Jul 27, 2016, at 11:24 AM, Daniel Migault wrote: > > Hi, > > I reviewed draft-ietf-ipsecme-tcp-encaps-01 as my understanding is that we are doing a pre-WGLC. I think the draft is in pretty good shape for a WGLC. Please see my comments below. > > > BR, > Daniel > > TCP Encapsulation of IKE and IPSec Packets > draft-ietf-ipsecme-tcp-encaps-01 > > Abstract > > This document describes a method to transport IKE and IPSec packets > over a TCP connection for traversing network middleboxes that may > block IKE negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending all packets for tunnel establishment > > >MGLT: Maybe that would be clearer to have: > >OLD: > >This method, referred to as TCP > >encapsulation, involves sending all packets for tunnel establishment > >as well as tunneled packets over a TCP connection. > > > >NEW: > >This method, referred to as TCP > >encapsulation, involves both sending all IKE packets for tunnel establishment > >as well as tunneled packets with ESP over a TCP connection. Tweaked the wording, thanks! > > > as well as tunneled packets over a TCP connection. This method is > intended to be used as a fallback option when IKE cannot be > negotiated over UDP. > > > 1. Introduction > > IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, using > > >MGLT: I think IPSec should be replaced by IPsec. Replaced throughout the draft. Thanks for pointing this out. > > Direct use of ESP or UDP Encapsulation should be preferred by IKE > implementations due to performance concerns when using TCP > Encapsulation Section 12. > > >MGLT: This looks a bit strange to have Section 12 at the end of the > >sentence. Maye it would be preferred something like "More details > >are provided in Section 12" Adjusted formatting. > > Most implementations should use TCP > Encapsulation only on networks where negotiation over UDP has been > attempted without receiving responses from the peer, or if a network > is known to not support UDP. > > 1.1. Prior Work and Motivation > > > Some previous solutions include: > > >MGLT: I would prefer "alternatives" then "solutions" as solutions > > imply there is not anymore a problem to solve.. In addition, we > >can add some justification for this document. The justifications for > >me are 1) defining a standard that provides interoperability as well > >as 2) reduce the additional overhead over some tof the solutions. I > >do not know if that is easier to have a sentence to position the > >document toward each alternative or if it can be summed up in the > >beginning. > I switched the wording to "alternatives", and added some text after the list about the goal of this document with regards to how it is different from other approaches. > > > 2. Configuration > > One of the main reasons to use TCP encapsulation is that UDP traffic > may be entirely blocked on a network. Because of this, support for > TCP encapsulation is not specifically negotiated in the IKE exchange. > Instead, support for TCP encapsulation must be pre-configured on both > the initiator and the responder. > > The configuration defined on each peer should include the following > parameters: > > o One or more TCP ports on which the responder will listen for > incoming connections. Note that the initiator may initiate TCP > connections to the responder from any local port. > > >MGLT: I would also add a note that the port the responder > >may listen to may be limited as such networks may only let > >a very limited set of outgoing ports over TCP. Obviously ports > >could be 80 or 443. On the other hand on an IPsec point of > >view port 4500 seems also a natural cnadidate. Added a note that the ports that will be chosen is likely based on the ones allowed on very restrictive networks. > > > > 3. TCP-Encapsulated Header Formats > > >MGLT: Maybe it would help to specify in the begining of the section > >something like : > >"TCP encapsulation follows > >the UDP encapsulation marking to differentaite ESP to IKE. > >In addition, TCP stream also require the length to be specified." > > Reworded the section to compare it to UDP encapsulation and point out the similarities. > In order to encapsulate IKE and ESP messages within a TCP stream, a > 16-bit length field precedes every message. If the first 32-bits of > the message are zeros (a Non-ESP Marker), then the contents comprise > an IKE message. Otherwise, the contents comprise an ESP message. > Authentication Header (AH) messages are not supported for TCP > encapsulation. > > > MGLT: I think the restriction to ESP should be mentioned earlier in > > the document. (Abstract or introduction) I looked for a better place to mention that only ESP is supported, and I didn't find a better place earlier in the document. This section on how to actually encapsulate the messages is the first part that gets into the details of ESP, etc. If you have a specific place you'd like to see AH mentioned earlier, let me know. > > > 3.1. TCP-Encapsulated IKE Header Format > > > The IKE header is preceded by a 16-bit length field in network byte > order that specifies the length of the IKE packet within the TCP > stream. > > > MGLT: Reading the text it looks that length does not include the Non-ESP > > Marker. This is specified later, but maybe we coudl replace: > > > > OLD: > > The IKE header is preceded by a 16-bit length field in network byte > > order that specifies the length of the IKE packet within the TCP > > stream. > > NEW: > > The IKE header is preceded by a 16-bit length field in network byte > > order that specifies the length of the encapsulated IKE packet within the TCP > > stream. Actually, the length should include the Non-ESP marker, and the text in the bullet point did mention that. I added another comment above where you were quoting to make this more clear. > > > > > 4. TCP-Encapsulated Stream Prefix > > >MGLT: Maybe that would be helpful for te reader to provide motivations > >for these "IKETCP" stream. I would have something like this at the > >beginign of the section: > > >"TCP encapsulation has not been assigned any specific port, as > > this port may not be allowed in a network. As a result, TCP > > encapsulation may not be announced with a specific port. In > > addition, port allowed by the network for TCP may happen to be > > well known port used by other applications such as port 80, or 443. > > When such port are used, peers should signal that the TCP connection > > is not associated to the well known port but instead for TCP > > encapsulation. In addition, such signaling needs to be performed > > at the TCP layer to make TCP encapsulation as generic as possible. > > For example, the used of ALPN for such signalling would restrict > > the signaling to TLS. TCP could use TCP options, but these options > > are unlikely to go through most networks. As a result, this document > > uses in-band signaling." > > Each stream of bytes used for IKE and IPSec encapsulation MUST begin > with a fixed sequence of six bytes as a magic value, containing the > characters "IKETCP" as ASCII values. This allows peers to > differentiate this protocol from other protocols that may be run over > TCP streams, since the bytes do not overlap with the valid start of > any other known stream protocol. This value is only sent once, by > the Initiator only, at the beginning of any stream of IKE and ESP > messages. I've reworded the section slightly. I think it already did communicate some of the reasons that we need a prefix, but I've tried to make it more clear. I've also explained why we don't use the inner protocol markings for 'framing protocols' (read: TLS). > > > >MGLT: Maybe that will be in the security considerations, but I think > >we should explain that we hope there is not matching with an existing packet. Added a comment in security considerations as well. > > > > > 5. Applicability > > > If TCP encapsulation is being used for a specific IKE SA, all > messages for that IKE SA and its Child SAs MUST be sent over a TCP > connection until the SA is deleted or MOBIKE is used to change the SA > endpoints and/or encapsulation protocol. > > >MGLT: The sentence below looks to me redundant with the first sentence. > > I would also add a reference to section below where intercations with > > MOBIKE is provided in more details. Agreed, I've removed the second sentence to make the wording less redundant. Added a reference as well. > > > No packets should be sent > over UDP or direct ESP for the IKE SA or its Child SAs while using > TCP encapsulation. > > > 8. Using MOBIKE with TCP encapsulation > > > > MGLT: From this section my understanding is that MOBIKE message > > from the new interface uses first a UDP encapsulation. If that > > does not work, it switches to TCP encapsulation. In other work > > there is no fall back from TCP to NO encapsulation. Shouldn't we > > use the NAT detection to determine whether UDP encapsulation or > > no encapsulation be used? > > My understanding is that ESP is UDP encapsulated or not depending > > if NAT has been detected on the initial interface. In other words, > > if the new network has no NAT, the mobile is likely to perform > > encapsulation on this network. Am I correct ? We do support raw ESP, ESP-over-UDP and ESP-over-TCP in this draft, and MOBIKE can use any of them. The IKE messages will either be over UDP or TCP, and if UDP, will use the NAT detection payloads to determine if ESP needs to be encapsulated in UDP (like normal). On every MOBIKE attempt, IKE should use UDP first, and then try TCP if UDP doesn't get a reply. I think the confusion was because of the sentence I had that said that the encapsulation of ESP needed to match the encapsulation of IKE. I have removed this sentence. Can you take another look and see if it is clearer now? > > > 13. Security Considerations > > > > MGLT: I think we should also add some text regarding the matching with the IKETCP string. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_4+jseVoOnsE16Y5tLC8NzQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Hi Daniel,

Thanks for the in-depth review! I've = incorporated your comments into a new update: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02. Specific responses to your comments inline!

Any other comments are welcome on the = new version. I agree with Daniel that we're in good shape to go into = WGLC.

Best,
Tommy

On = Jul 27, 2016, at 11:24 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

I reviewed = draft-ietf-ipsecme-tcp-encaps-01 as my understanding is that we are = doing a pre-WGLC.  I think the draft is in pretty good shape for a = WGLC. Please see my comments below.


BR,
Daniel

          &nb= sp;    TCP Encapsulation of IKE and IPSec Packets
          &nb= sp;         = draft-ietf-ipsecme-tcp-encaps-01

Abstract

   This document describes a method = to transport IKE and IPSec packets
   over a TCP = connection for traversing network middleboxes that may
   block IKE negotiation over UDP.  This = method, referred to as TCP
   encapsulation, = involves sending all packets for tunnel establishment
 
>MGLT: Maybe that would be clearer to = have:
>OLD:
>This method, referred to = as TCP
>encapsulation, involves sending all packets for = tunnel establishment
>as well as tunneled packets over = a TCP connection.
>
>NEW:
>This method, referred to as TCP
>encapsulation, involves both sending all IKE packets for = tunnel establishment
>as well as tunneled packets with = ESP over a TCP connection.

Tweaked = the wording, thanks!

  
   as well as tunneled = packets over a TCP connection.  This method is
   intended to be used as a fallback option when = IKE cannot be
   negotiated over UDP.


1.  Introduction

   IKEv2 [RFC7296] is a protocol for = establishing IPSec tunnels, using
  
>MGLT: I think IPSec should be replaced by IPsec.

Replaced throughout the draft. Thanks for pointing = this out.

 
   = Direct use of ESP or UDP Encapsulation should be preferred by IKE
   implementations due to performance concerns when = using TCP
   Encapsulation Section 12.
  
>MGLT: This looks a bit = strange to have Section 12 at the end of the
>sentence. = Maye it would be preferred something like "More details
>are provided in Section 12"

Adjusted = formatting.

   Most = implementations should use TCP
   Encapsulation = only on networks where negotiation over UDP has been
   attempted without receiving responses from the = peer, or if a network
   is known to not support = UDP.

1.1.  Prior Work and = Motivation


   Some = previous solutions include:

>MGLT: I = would prefer "alternatives" then "solutions" as solutions
> imply there is not anymore a problem to solve.. In = addition, we
>can add some justification for this = document. The justifications for
>me are 1) defining a = standard that provides interoperability as well
>as 2) = reduce the additional overhead over some tof the solutions. I
>do not know if that is easier to have a sentence to = position the
>document toward each alternative or if = it can be summed up in the
 >beginning.
 

I switched the wording to "alternatives", and = added some text after the list about the goal of this document with = regards to how it is different from other approaches.



2.  = Configuration

   One of the main = reasons to use TCP encapsulation is that UDP traffic
   may be entirely blocked on a network.  = Because of this, support for
   TCP = encapsulation is not specifically negotiated in the IKE exchange.
   Instead, support for TCP encapsulation must be = pre-configured on both
   the initiator and the = responder.

   The configuration = defined on each peer should include the following
   parameters:

   o  One or more TCP ports on which the = responder will listen for
      = incoming connections.  Note that the initiator may initiate TCP
      connections to the responder = from any local port.

>MGLT: I would also = add a note that the port the responder
>may listen to = may be limited as such networks may only let
 >a = very limited set of outgoing ports over TCP. Obviously ports
 >could be 80 or 443. On the other hand on an IPsec = point of
 >view port 4500 seems also a natural = cnadidate.

Added a note that the ports that will be chosen is = likely based on the ones allowed on very restrictive networks.

     

 
3.  TCP-Encapsulated Header = Formats

>MGLT: Maybe it would help to = specify in the begining of the section
>something like = :
>"TCP encapsulation follows
>the UDP = encapsulation marking to differentaite ESP to IKE.
>In = addition, TCP stream also require the length to be specified." 
>

Reworded the section to compare it to UDP encapsulation = and point out the similarities.
  In order = to encapsulate IKE and ESP messages within a TCP stream, a
   16-bit length field precedes every = message.  If the first 32-bits of
   the = message are zeros (a Non-ESP Marker), then the contents comprise
   an IKE message.  Otherwise, the contents = comprise an ESP message.
   Authentication = Header (AH) messages are not supported for TCP
   = encapsulation.

 > MGLT: I think the restriction to ESP should be = mentioned earlier in
 > the document. (Abstract = or introduction) 

I looked for a better place to mention that only ESP is = supported, and I didn't find a better place earlier in the document. = This section on how to actually encapsulate the messages is the first = part that gets into the details of ESP, etc. If you have a specific = place you'd like to see AH mentioned earlier, let me know.
  
 
3.1.  TCP-Encapsulated IKE Header Format
 
   The IKE header is preceded = by a 16-bit length field in network byte
   = order that specifies the length of the IKE packet within the TCP
   stream.

> MGLT: = Reading the text it looks that length does not include the Non-ESP
> Marker. This is specified later, but maybe we coudl = replace:
>
> OLD:
 >   The IKE header is preceded by a 16-bit = length field in network byte
 >  order that = specifies the length of the IKE packet within the TCP
 >  stream.
> NEW:
>    The IKE header is preceded by a 16-bit = length field in network byte
>   order that = specifies the length of the encapsulated IKE packet within the TCP
>   stream.

Actually, = the length should include the Non-ESP marker, and the text in the bullet = point did mention that. I added another comment above where you were = quoting to make this more clear.

  
 

4.  TCP-Encapsulated Stream Prefix

>MGLT: Maybe that would be helpful for te reader to = provide motivations
>for these "IKETCP" stream. I would = have something like this at the
>beginign of the = section:

>"TCP encapsulation has not = been assigned any specific port, as
> this port may not = be allowed in a network. As a result, TCP
> = encapsulation may not be announced with a specific port. In
> addition, port allowed by the network for TCP may happen = to be
> well known port used by other applications such = as port 80, or 443.
> When such port are used, peers = should signal that the TCP connection
> is not = associated to the well known port but instead for TCP
> = encapsulation. In addition, such signaling needs to be performed
> at the TCP layer to make TCP encapsulation as generic as = possible.
> For example, the used of ALPN for such = signalling would restrict
> the signaling to TLS. TCP = could use TCP options, but these options
> are unlikely = to go through most networks. As a result, this document
>= uses in-band signaling."

   Each = stream of bytes used for IKE and IPSec encapsulation MUST begin
   with a fixed sequence of six bytes as a magic = value, containing the
   characters "IKETCP" as = ASCII values.  This allows peers to
   = differentiate this protocol from other protocols that may be run over
   TCP streams, since the bytes do not overlap with = the valid start of
   any other known stream = protocol.  This value is only sent once, by
   the Initiator only, at the beginning of any = stream of IKE and ESP
   messages.

I've = reworded the section slightly. I think it already did communicate some = of the reasons that we need a prefix, but I've tried to make it more = clear. I've also explained why we don't use the inner protocol markings = for 'framing protocols' (read: TLS).


>MGLT: Maybe that will be in the security = considerations, but I think
>we should explain that we = hope there is not matching with an existing packet.

Added a = comment in security considerations as well.




5.  = Applicability


   = If TCP encapsulation is being used for a specific IKE SA, all
   messages for that IKE SA and its Child SAs MUST = be sent over a TCP
   connection until the SA is = deleted or MOBIKE is used to change the SA
   = endpoints and/or encapsulation protocol.

>MGLT: The sentence below looks to me redundant with the = first sentence.
>  I would also add a reference to = section below where intercations with
>  MOBIKE is = provided in more details.

Agreed, I've removed the second sentence to make the = wording less redundant. Added a reference as well.


   No = packets should be sent
   over UDP or direct ESP = for the IKE SA or its Child SAs while using
   = TCP encapsulation.


8.  = Using MOBIKE with TCP encapsulation


>   MGLT: =46rom this section my understanding = is that MOBIKE message
>   from the new = interface uses first a UDP encapsulation. If that
>  does not work, it switches to TCP encapsulation. = In other work
>   there is no fall back from = TCP to NO encapsulation. Shouldn't we
>   use = the NAT detection to determine whether UDP encapsulation or
>   no encapsulation be used?  
>   My understanding is that ESP is UDP = encapsulated or not depending
>   if NAT has = been detected on the initial interface. In other words,
>   if the new network has no NAT, the mobile is = likely to perform
>   encapsulation on this = network. Am I correct ?

We do support raw ESP, ESP-over-UDP and = ESP-over-TCP in this draft, and MOBIKE can use any of them. The IKE = messages will either be over UDP or TCP, and if UDP, will use the NAT = detection payloads to determine if ESP needs to be encapsulated in UDP = (like normal). On every MOBIKE attempt, IKE should use UDP first, and = then try TCP if UDP doesn't get a reply.

I think the confusion was because of the sentence = I had that said that the encapsulation of ESP needed to match the = encapsulation of IKE. I have removed this sentence. Can you take another = look and see if it is clearer now?

  

13.  Security = Considerations

 
> = MGLT: I think we should also add some text regarding the matching with = the IKETCP string.


_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_4+jseVoOnsE16Y5tLC8NzQ)-- From nobody Wed Aug 17 13:47:50 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB49912D658; Wed, 17 Aug 2016 13:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147146686972.23808.10322500010303308155.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 13:47:49 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 20:47:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-08.txt Pages : 29 Date : 2016-08-17 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 19 05:45:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED5812D980 for ; Fri, 19 Aug 2016 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 nwyil1qgYiJj for ; Fri, 19 Aug 2016 05:45:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0172312D955 for ; Fri, 19 Aug 2016 05:45:14 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7JCj57o028446 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Aug 2016 15:45:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7JCj4Y7004778; Fri, 19 Aug 2016 15:45:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22454.65360.439908.565705@fireball.acr.fi> Date: Fri, 19 Aug 2016 15:45:04 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: <60808678c1cd464495a915d91b935d58@XCH-RTP-006.cisco.com> References: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> <26205.1471011158@obiwan.sandelman.ca> <60808678c1cd464495a915d91b935d58@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , Michael Richardson Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:45:17 -0000 Scott Fluhrer (sfluhrer) writes: > > Or could we introduce some things now that would make "dropping in" a > > replacement easier? > > Nothing comes to mind; according to the above wild speculation, the > difficulties that people are likely to encounter are more to do with > the implementations, and less with the protocol. > > Actually, there are some interesting postquantum protocols (e.g. > McEliece) which look good, except that they have massively large key > shares. I've considered them impractical; however if there was > something easy we could do to make those more practical, that may > help. I'm not suggesting that we do; you just asked if there was > anything we might do that would help... Combining those two above, i.e., some postquantum protocols require too big packets so they are not usable in IKE context directly, but they do generate out some kind of shared secret which can be used to derive keys, we might implement our drop in postquantum protcols in way where the postquantum protocol is run outside the IKE context, and it just generates the shared secret to be used in the IKE. I.e., now we have shared PPK configured in and used in the KDF. After postquantum protocols are there, instead of having preconfigured shared PPK, we first run the postquantum protocol over some other channel (over tcp? or something, if it requires big packets etc), and the output of that process is the shared PPK we can use for IKE, just like our short term solution uses. I.e., if the postquantum protocols are going to be something that mimics Diffie-Hellman in away that they provide some shared secret we can mix in to KDF then we should be able to use that output with our short term PPK solution too. -- kivinen@iki.fi From nobody Tue Aug 23 10:55:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A217112D660 for ; Tue, 23 Aug 2016 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 4LG8BxAVI6R5 for ; Tue, 23 Aug 2016 10:55:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74ACE12D661 for ; Tue, 23 Aug 2016 10:55:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sJdPr6lHBzCWN; Tue, 23 Aug 2016 19:55:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1471974912; bh=jri5PxIJWUOTPntTgSGoqonUwmKWX4Ods+FuaGPhTIU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cGZf7D0cgLt7gJmjK15grcBF60BWUwsb2rXgSxu2e3FZzc/Umc66OptDbHCDmLArv AL9R7r8CmHlKrgmy+3xRjJ72pmCJxVdiMq3GGvIxZIYrHogZ+CUZh2A6fE3aPX09s3 qTL8LUpA/dJDnAnmCcCj57CEPicejws0VZe0gqpg= 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 wW4ghGL8v8FY; Tue, 23 Aug 2016 19:55:12 +0200 (CEST) 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; Tue, 23 Aug 2016 19:55:12 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 307374C9FF7; Tue, 23 Aug 2016 13:55:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 307374C9FF7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 20B1F411AC60; Tue, 23 Aug 2016 13:55:11 -0400 (EDT) Date: Tue, 23 Aug 2016 13:55:10 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: Message-ID: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Paul Hoffman , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 17:55:19 -0000 On Mon, 8 Aug 2016, Paul Wouters wrote: I haven't heard any objection to making 128 bit key sizes MUST- and 256 bit key sizes MUST. Answers that agree or disagree would be good to hear. Paul > Actually, this is a very good reason to bumo the keysizes from 128 to > 256. Currently in 7321bis and 4307bis, 128 is MUST and 256 is SHOULD. I > have asked before if we should make 256 MUST and 128 MUST-. > > Current text has: > > [1] - This requirement level is for 128-bit keys. 256-bit keys are at > SHOULD. 192-bit keys can safely be ignored. [IoT] - This > requirement is for interoperability with IoT. > > IPsec sessions may have very long life time, and carry multiple > packets, so there is a need to move 256-bit keys in the long term. > For that purpose requirement level is for 128 bit keys and 256 bit > keys are at SHOULD (when applicable). In that sense 256 bit keys > status has been raised from MAY in RFC7321 to SHOULD. > > > Is there anyone who disagrees with making 128 MUST- and 256 MUST ? > > Paul > > From nobody Tue Aug 23 11:32:58 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9352B12D6AC for ; Tue, 23 Aug 2016 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 tOyPKj4Z2j2P for ; Tue, 23 Aug 2016 11:32:55 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EF612D6AE for ; Tue, 23 Aug 2016 11:32:55 -0700 (PDT) Received: from [10.32.60.72] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7NIWpYS022572 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2016 11:32:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.72] From: "Paul Hoffman" To: "Paul Wouters" Date: Tue, 23 Aug 2016 11:32:51 -0700 Message-ID: <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> In-Reply-To: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 18:32:56 -0000 On 23 Aug 2016, at 10:55, Paul Wouters wrote: > On Mon, 8 Aug 2016, Paul Wouters wrote: > > I haven't heard any objection to making 128 bit key sizes MUST- and > 256 bit key sizes MUST. You can hear one now. > Answers that agree or disagree would be good > to hear. The proposed change is based on the existence of quantum computers that have a sufficient number of properly-interacting qbits. We have literally no idea if those computers will ever exist. All current data indicates that we will see the progressing of "sufficient number" and "properly-interacting" and be able to increase key sizes well ahead of widespread use of quantum computers. --Paul Hoffman From nobody Tue Aug 23 12:15:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFFB12D9B5 for ; Tue, 23 Aug 2016 12:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 SYHJwX-LZs0y for ; Tue, 23 Aug 2016 12:14:57 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3D512D9B7 for ; Tue, 23 Aug 2016 12:12:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DA7C3E203F; Tue, 23 Aug 2016 15:12:36 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17914-05; Tue, 23 Aug 2016 15:12:34 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id A04CFE203A; Tue, 23 Aug 2016 15:12:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1471979554; bh=H9T9u7NEyUOU04umWmegEm6RrKKZpeIGQ/eDWTFdIYo=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=swB323fMDvKsplih3J6dBTp7vHrbiCh3lQlFrU7DYjQM9ynJ2z9VvaqG5ayh6kC3e yWIvjESosomfN+SF0+lT3VCM60pvqNmpvGdt8poZ+IfdZt+wVQu3yD6MEOC5pk+mWW UE97M01y9YSSYTs3525YUgjx96ioYmpg7daQMMkE= Received: from 2001:470:e448:2:ea2a:eaff:fe7d:235 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 23 Aug 2016 15:12:34 -0400 Message-ID: In-Reply-To: <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> Date: Tue, 23 Aug 2016 15:12:34 -0400 From: "Derek Atkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:14:59 -0000 Paul, On Tue, August 23, 2016 2:32 pm, Paul Hoffman wrote: > On 23 Aug 2016, at 10:55, Paul Wouters wrote: > >> On Mon, 8 Aug 2016, Paul Wouters wrote: >> >> I haven't heard any objection to making 128 bit key sizes MUST- and >> 256 bit key sizes MUST. > > You can hear one now. > >> Answers that agree or disagree would be good >> to hear. > > The proposed change is based on the existence of quantum computers that > have a sufficient number of properly-interacting qbits. We have > literally no idea if those computers will ever exist. All current data > indicates that we will see the progressing of "sufficient number" and > "properly-interacting" and be able to increase key sizes well ahead of > widespread use of quantum computers. Just to play devil's advocate here, are you implying that we'll see a 5-10-year lead time on quantum computer development sufficiently in order to spend those 5-10 years: 1) having this discussion again, 2) revving the documents 3) getting the revved documents through the process 4) getting the revved documents published 5) getting the revved documents implemented 6) getting that new implementation into the field, and (most importantly) 7) getting the OLD hardware decommissioned? I think it would be a good 5 years just to get through step 6, let alone getting to step 7. I suspect step 7 is yet another 5-10 years beyond step 6 (and I feel like I'm being generous). So if we assume that quantum computers WILL, eventually, have a sufficient number of properly-interacting qbits, then the question is when do we think that will occur, and when do we need to start the process to update such that we get to step 7 before the quantum computers arrive? (I take it from your email that you disagree with this assumption, which is fine, but I believe this is the assumption from which these all occur) Also note that MTI does not imply MTU/MTD. (Use/Deploy). But I know you knew that. > --Paul Hoffman -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 23 12:29:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB96412D9C4 for ; Tue, 23 Aug 2016 12:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 ui4IgkaUHqRU for ; Tue, 23 Aug 2016 12:29:01 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7CB12D9D6 for ; Tue, 23 Aug 2016 12:28:58 -0700 (PDT) Received: from [10.32.60.72] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7NJStYG030728 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2016 12:28:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.72] From: "Paul Hoffman" To: "Derek Atkins" Date: Tue, 23 Aug 2016 12:28:55 -0700 Message-ID: <16D370A2-1634-4CA6-8D93-0E507269153A@vpnc.org> In-Reply-To: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:29:02 -0000 On 23 Aug 2016, at 12:12, Derek Atkins wrote: > Just to play devil's advocate here, are you implying that we'll see a > 5-10-year lead time on quantum computer development sufficiently in > order > to spend those 5-10 years: > 1) having this discussion again, > 2) revving the documents > 3) getting the revved documents through the process > 4) getting the revved documents published > 5) getting the revved documents implemented > 6) getting that new implementation into the field, and (most > importantly) > 7) getting the OLD hardware decommissioned? No, not at all. PaulW's proposal is *not* about adding a new algorithm, it is changing the recommendation status for the algorithms. Both algorithms will be in the deployed systems. So the 5-10 years lead time is getting users to change their configs. If we can't get them to change them in 10 years, we probably can't get them to change them ever. It is operator's responsibility to maintain their configurations, not ours to be the configuration police. Note that this thread is split off from the QR thread. --PaulH From nobody Tue Aug 23 12:35:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F9812D7BD for ; Tue, 23 Aug 2016 12:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bnPCmtCf8TGB for ; Tue, 23 Aug 2016 12:35:37 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9021C12D793 for ; Tue, 23 Aug 2016 12:35:37 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o80so210024488wme.1 for ; Tue, 23 Aug 2016 12:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xyFcVu96S5xmM+MtMJL2hscpiSg4Ywj/b4bxm/qYhRg=; b=CMud06yPxXj06nVyt3wzv86fpey39uqmgmjSK+i2MoRNCsZZbLmQlZ19W3hAqzckrd vCDlDsNObRg0m1TjhvXaQtXAbNLDgn6JkqFKuFwlTOBKacwD08RORIfSz86b4Y/sWnT3 yad4KHZMW8wq34rxqCu67zJbbep3u+4cRh2PmRl6MzMSQDvOFnL+r3hm8iyQgnF4WiKU H+bzL5pOf3v5xU183mJB1ebjC6P4RNKHI5QpMzIgomiVgJNJFlmEa+KU++a5/MkciEUT FXP7o+eq9rG/m+QAJCyOxuEtuIYhee9eVDtlZ0grDdlrZkcFVeTBPTIFwy+IIA8vvgqk gqAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xyFcVu96S5xmM+MtMJL2hscpiSg4Ywj/b4bxm/qYhRg=; b=hEDGyotve0Rw9YwFd7s0FQuZ5gzFzW2Vn5Aq9LNxHY7J9BPsIC7bRXuwfLB78BXdnW zzw38TIpx+3C3UeNzZbxxLcYLdapR7BqjPmOdDnzuljTzxYvzN/yp/cAOHpzq/0Uwwm2 wVd3SdG2Ab+EUh0FFiV4n2GwkRImVk1gbx1VWNzXS1wyx4oRZjQ3Zb9TBAqhoj58ztn+ 9+/N5YAhA9jbQa5Gl8EKyEMUAXVR0Ht348ZiQufp0Rp/ot+s/URSoRWGlwQhZrOTa8Kh QOv7XERuKJyUfEW1iYk6bVJZIf+CkSOnkeAuArKPRaKgqGisxBbgHMTlLwlq6YN/mQXV s7gw== X-Gm-Message-State: AEkoous3iI3RvAXSgmJSThPGsPoG0fVYuwIQ4foSk3bPVDUNZU/YRvZcQCmvkugreFp7Xg== X-Received: by 10.28.198.142 with SMTP id w136mr22098289wmf.30.1471980935869; Tue, 23 Aug 2016 12:35:35 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g7sm5540629wjx.10.2016.08.23.12.35.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 12:35:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> Date: Tue, 23 Aug 2016 22:35:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0DF2FD42-EB65-4EC6-81CE-AA0F4A1AC487@gmail.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:35:39 -0000 > On 23 Aug 2016, at 9:32 PM, Paul Hoffman = wrote: >=20 > On 23 Aug 2016, at 10:55, Paul Wouters wrote: >=20 >> On Mon, 8 Aug 2016, Paul Wouters wrote: >>=20 >> I haven't heard any objection to making 128 bit key sizes MUST- and >> 256 bit key sizes MUST. >=20 > You can hear one now. >=20 >> Answers that agree or disagree would be good >> to hear. >=20 > The proposed change is based on the existence of quantum computers = that have a sufficient number of properly-interacting qbits. We have = literally no idea if those computers will ever exist. All current data = indicates that we will see the progressing of "sufficient number" and = "properly-interacting" and be able to increase key sizes well ahead of = widespread use of quantum computers. Perhaps, but those quantum computers will be able to decrypt the traffic = we are sending now where the key is only 128-bit long. The vast majority of implementations support both 128-bit and 256-bit = keys for AES. When the day arrives that we feel it=E2=80=99s time to = take the performance hit and more to 256-bit AES, all of us will merely = have to reconfigure existing deployments. My company=E2=80=99s = implementation has supported AES-256 since 2001, and I=E2=80=99m sure = others are similar. But those outliers who support only one key length = (presumably 128) will impede everyone=E2=80=99s transition to 256-bits.=20= So I=E2=80=99m sympathetic to Paul W=E2=80=99s idea to make 256-bit a = MUST. I don=E2=80=99t think it=E2=80=99s reasonable to release a product = in 2016 that only supports 128-bit AES. I=E2=80=99m not saying anything = about what the defaults should be and what configuration advice should = be, but requiring support for 256-bit as a precaution seems prudent.=20 I=E2=80=99m less sympathetic to reducing AES-128 to MUST-. This = algorithm with that key length is the most common, most widely deployed = for IKE, IPsec, TLS, and SSH. It=E2=80=99s by far the most commonly = deployed. Our focus in these documents in interoperability, so this = needs to be a MUST. As you=E2=80=99ve said, we don=E2=80=99t know if = quantum computers are going to become practical in our lifetimes. = Without them, AES-256 offers little advantage. I don=E2=80=99t think we = should be signalling that AES-128 is on its way out. Yoav From nobody Tue Aug 23 12:44:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0DA12DA00 for ; Tue, 23 Aug 2016 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 xx8bDmW6MWbs for ; Tue, 23 Aug 2016 12:44:08 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010A612DA56 for ; Tue, 23 Aug 2016 12:43:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id F2954E2039; Tue, 23 Aug 2016 15:43:41 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18185-06; Tue, 23 Aug 2016 15:43:40 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 34842E2040; Tue, 23 Aug 2016 15:43:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1471981420; bh=wENxwbvQkgibqm4IBeGmGkfgAyPgUmHhgAoEwXP1LXY=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=DZ78ByIlGyidXbqKnZu9DMkdAbP2IQGVjGxvAy9hjAC+SRaQJbiQdWe7UjuYNqLDZ IBnGTyKHaKsZsVPhR4xfDTiDxYbMlGpVeDHt8ECCz99H++OMVRQsMV2VK0qS+AS+Mu Qlus/ug+SisMk2GTCfSyp/qvd33ConXOHEJj58v8= Received: from 2001:470:e448:2:ea2a:eaff:fe7d:235 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 23 Aug 2016 15:43:40 -0400 Message-ID: <1fade7de75915550a3093ffacfa8a902.squirrel@mail2.ihtfp.org> In-Reply-To: <16D370A2-1634-4CA6-8D93-0E507269153A@vpnc.org> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> <16D370A2-1634-4CA6-8D93-0E507269153A@vpnc.org> Date: Tue, 23 Aug 2016 15:43:40 -0400 From: "Derek Atkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Derek Atkins , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:44:10 -0000 Paul, On Tue, August 23, 2016 3:28 pm, Paul Hoffman wrote: > > On 23 Aug 2016, at 12:12, Derek Atkins wrote: > >> Just to play devil's advocate here, are you implying that we'll see a >> 5-10-year lead time on quantum computer development sufficiently in >> order >> to spend those 5-10 years: >> 1) having this discussion again, >> 2) revving the documents >> 3) getting the revved documents through the process >> 4) getting the revved documents published >> 5) getting the revved documents implemented >> 6) getting that new implementation into the field, and (most >> importantly) >> 7) getting the OLD hardware decommissioned? > > No, not at all. PaulW's proposal is *not* about adding a new algorithm, > it is changing the recommendation status for the algorithms. Both > algorithms will be in the deployed systems. So the 5-10 years lead time > is getting users to change their configs. If we can't get them to change > them in 10 years, we probably can't get them to change them ever. It is > operator's responsibility to maintain their configurations, not ours to > be the configuration police. Note that this thread is split off from the > QR thread. I apologize for jumping in, but my reading doesn't match your statement. My reading was Paul proposing to change the Implementation Level of AES-256 from SHOULD to MUST. That implied subtext is that some devices may not currently implement AES-256 (even though they SHOULD) and he wants to ensure that, if/when a quantum computer comes into existence then all that is requires *IS* a configuration change to move deployment to AES-256. I definitely agree that the goal should be that only a configuration change should be required to ensure AES-256 gets used. > --PaulH -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 23 12:54:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30A012D9EE for ; Tue, 23 Aug 2016 12:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 q-t19nDh187A for ; Tue, 23 Aug 2016 12:53:58 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F8612D820 for ; Tue, 23 Aug 2016 12:53:57 -0700 (PDT) Received: from [10.32.60.72] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7NJrsbJ032709 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2016 12:53:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.72] From: "Paul Hoffman" To: "Derek Atkins" Date: Tue, 23 Aug 2016 12:53:54 -0700 Message-ID: <5CE83BA0-2A07-4FA0-B60E-77E81522DA64@vpnc.org> In-Reply-To: <1fade7de75915550a3093ffacfa8a902.squirrel@mail2.ihtfp.org> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> <16D370A2-1634-4CA6-8D93-0E507269153A@vpnc.org> <1fade7de75915550a3093ffacfa8a902.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:53:59 -0000 On 23 Aug 2016, at 12:43, Derek Atkins wrote: > Paul, > > On Tue, August 23, 2016 3:28 pm, Paul Hoffman wrote: >> >> On 23 Aug 2016, at 12:12, Derek Atkins wrote: >> >>> Just to play devil's advocate here, are you implying that we'll see >>> a >>> 5-10-year lead time on quantum computer development sufficiently in >>> order >>> to spend those 5-10 years: >>> 1) having this discussion again, >>> 2) revving the documents >>> 3) getting the revved documents through the process >>> 4) getting the revved documents published >>> 5) getting the revved documents implemented >>> 6) getting that new implementation into the field, and (most >>> importantly) >>> 7) getting the OLD hardware decommissioned? >> >> No, not at all. PaulW's proposal is *not* about adding a new >> algorithm, >> it is changing the recommendation status for the algorithms. Both >> algorithms will be in the deployed systems. So the 5-10 years lead >> time >> is getting users to change their configs. If we can't get them to >> change >> them in 10 years, we probably can't get them to change them ever. It >> is >> operator's responsibility to maintain their configurations, not ours >> to >> be the configuration police. Note that this thread is split off from >> the >> QR thread. > > I apologize for jumping in, but my reading doesn't match your > statement. > My reading was Paul proposing to change the Implementation Level of > AES-256 from SHOULD to MUST. Ah! If you're right, then I agree with that part of his proposal. > That implied subtext is that some devices > may not currently implement AES-256 (even though they SHOULD) and he > wants > to ensure that, if/when a quantum computer comes into existence then > all > that is requires *IS* a configuration change to move deployment to > AES-256. That sounds fine. I may have misunderstood his proposal because he also wanted to demote AES-128 from MUST to MUST-. I object on the grounds that we have no idea if there will quantum-capable computers that can erode AES-128 in the foreseeable future, and that even if a dedicated adversary could weaken AES-128 to say 80 bits of strength, that we would want to say to all developers "don't implement this". --PaulH From nobody Tue Aug 23 13:00:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7EB12D9F3 for ; Tue, 23 Aug 2016 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 p-snaCYNbPem for ; Tue, 23 Aug 2016 13:00:14 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B8112D819 for ; Tue, 23 Aug 2016 13:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B990AE2039; Tue, 23 Aug 2016 16:00:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18185-10; Tue, 23 Aug 2016 16:00:11 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id B831CE203F; Tue, 23 Aug 2016 16:00:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1471982411; bh=XsagtmHTpbrVKhinvvrTmVLmx/bbULQu77ZYXN17rSA=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=BWpagHZY3JXvqQFoPLGC0aJrojer7dJIKycxniqz6LvBLWM6U+RvWskqQcWcUlCiN 0TrrGAVU5YYzWavEI7eu/mscid3vFqIhLpKiNk1gVy09SM4N50nyBU6cF+vCwKMT9h bqAKVuLTL416K8CpdK3ng0un+F0FljMLRHJHQgI4= Received: from 2001:470:e448:2:ea2a:eaff:fe7d:235 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 23 Aug 2016 16:00:11 -0400 Message-ID: <68cbddacb5262251c0ad2fd6b37d2763.squirrel@mail2.ihtfp.org> In-Reply-To: <5CE83BA0-2A07-4FA0-B60E-77E81522DA64@vpnc.org> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> <16D370A2-1634-4CA6-8D93-0E507269153A@vpnc.org> <1fade7de75915550a3093ffacfa8a902.squirrel@mail2.ihtfp.org> <5CE83BA0-2A07-4FA0-B60E-77E81522DA64@vpnc.org> Date: Tue, 23 Aug 2016 16:00:11 -0400 From: "Derek Atkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Derek Atkins , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 20:00:16 -0000 On Tue, August 23, 2016 3:53 pm, Paul Hoffman wrote: [snip] > I may have misunderstood his proposal because he also wanted to demote > AES-128 from MUST to MUST-. I object on the grounds that we have no idea > if there will quantum-capable computers that can erode AES-128 in the > foreseeable future, and that even if a dedicated adversary could weaken > AES-128 to say 80 bits of strength, that we would want to say to all > developers "don't implement this". Yeah, I also disagree with the demotion of AES-128 to MUST-. It's the most widely deployed now, and when Q-C happens we can turn it off with a config change and work to remove it at that time. I also see no reason to prefer *using* AES-256 today over AES-128, except, perhaps, for 10-30-year PFS against a potential Q-C that could bring the 128-bit down to 64-bit security. But this also assumes an adversary that is recording and storing all encrypted communications for the next 10-30 years until a Q-C can be built to break it. > --PaulH -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 23 13:41:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6D12D7EA for ; Tue, 23 Aug 2016 13:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 l5KuawJotPe2 for ; Tue, 23 Aug 2016 13:41:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E031F12D80E for ; Tue, 23 Aug 2016 13:41:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sJj5K6Jf4zCWf; Tue, 23 Aug 2016 22:41:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1471984869; bh=+GaJ8oJnf5RtFpayLrC5VxYwCV6p3wbpBoy/OTjmaFg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=faLe6T/XlJPacF3vgvi3eB8HfZEFWIvi089TpZ4b8OwRPSsy2lOJ9hh7I0lsDIGvE y8lX6qNPfJoUdc3rolDgwq54fWzXak+/llDHwMZL5n+T6ux60f+9FU9THN0m7H8j8r q3/O4pmpPWF9iJPiGeIpu5jykgfhavk+BbMaJ0mw= 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 8WnI0X_kRHtD; Tue, 23 Aug 2016 22:41:08 +0200 (CEST) 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; Tue, 23 Aug 2016 22:41:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D32984C9FF9; Tue, 23 Aug 2016 16:41:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D32984C9FF9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BB9D4411AC5F; Tue, 23 Aug 2016 16:41:05 -0400 (EDT) Date: Tue, 23 Aug 2016 16:41:05 -0400 (EDT) From: Paul Wouters To: Derek Atkins In-Reply-To: <68cbddacb5262251c0ad2fd6b37d2763.squirrel@mail2.ihtfp.org> Message-ID: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> <16D370A2-1634-4CA6-8D93-0E507269153A@vpnc.org> <1fade7de75915550a3093ffacfa8a902.squirrel@mail2.ihtfp.org> <5CE83BA0-2A07-4FA0-B60E-77E81522DA64@vpnc.org> <68cbddacb5262251c0ad2fd6b37d2763.squirrel@mail2.ihtfp.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Paul Hoffman , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 20:41:18 -0000 On Tue, 23 Aug 2016, Derek Atkins wrote: > Yeah, I also disagree with the demotion of AES-128 to MUST-. It's the > most widely deployed now, and when Q-C happens we can turn it off with a > config change and work to remove it at that time. I think that is fair, so let me propose the following changes for both bis documents: Current: [1] - This requirement level is for 128-bit keys. 256-bit keys are at SHOULD. 192-bit keys can safely be ignored. New: [1] - This implementation status covers 128-bit and 256-bit keys. 192-bit keys remain at MAY status. Paul From nobody Tue Aug 23 22:07:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445A312D17E for ; Tue, 23 Aug 2016 22:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pgGMwXm4ymRt for ; Tue, 23 Aug 2016 22:07:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D94D12B00F for ; Tue, 23 Aug 2016 22:07:45 -0700 (PDT) Received: from sandelman.ca (unknown [207.96.146.162]) by relay.sandelman.ca (Postfix) with ESMTPS id 87A211F8EF; Wed, 24 Aug 2016 05:07:42 +0000 (UTC) Received: by sandelman.ca (Postfix, from userid 179) id 1E8BF659D1; Wed, 24 Aug 2016 01:07:41 -0400 (EDT) From: Michael Richardson To: "Derek Atkins" In-reply-to: References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> Comments: In-reply-to "Derek Atkins" message dated "Tue, 23 Aug 2016 15:12:34 -0400." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Aug 2016 01:07:41 -0400 Message-ID: <22632.1472015261@dooku.sandelman.ca> Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Paul Hoffman , Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 05:07:47 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Derek Atkins wrote: >> The proposed change is based on the existence of quantum computers t= hat >> have a sufficient number of properly-interacting qbits. We have >> literally no idea if those computers will ever exist. All current da= ta >> indicates that we will see the progressing of "sufficient number" and >> "properly-interacting" and be able to increase key sizes well ahead = of >> widespread use of quantum computers. > Just to play devil's advocate here, are you implying that we'll see a > 5-10-year lead time on quantum computer development sufficiently in o= rder > to spend those 5-10 years: > 1) having this discussion again, > 2) revving the documents > 3) getting the revved documents through the process > 4) getting the revved documents published > 5) getting the revved documents implemented > 6) getting that new implementation into the field, and (most importan= tly) > 7) getting the OLD hardware decommissioned? Forgive my ignorance here; my BSc in particle physics is ~20 years out of d= ate. (this %#@*$ internet thing distracted me...) My understanding is we currently have a small number of qbits "properly-interacting". I think that I read an article saying it was 4 or so, but I just read that we are at 12 qbits in 2006, 28 in 2007 (maybe), and >1000 in 2015 (maybe). On the other hand, "2 qubit silicon gate" in 20= 16. I believe that we need 128 to interact to break AES-128? I'm just trying understand how the revolution that will take us from ~12 to 128, won't take us to 256 the following week. I feel kinda like we are re-arranging the chairs on the titanic here. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXvSuZAAoJEKD0KQ7Gj3P2aV4H/2ZF1JKjI7AJbVaLyINhbnRJ w91Jiane0SOboy2OIkRt0OU1rwD5t3K5TekGoU3JOLJ7DIanxX112+Won3gs5aL0 oevU0caRhm8sijA0PBVjoT+j6cPxr7SZGlrIJdyrIdKsmnInA9lPEf6V88+ZdDR/ Q3lnbOaFsJwIQIY1zrwhNWlfvY5htJzX/7yIIpmLGOhHJBY4M1O0OsQg/lAVfc3G +QURVhleJ6blmLbEBQmJX+4aE6b2z370pZAVbtcKHpRrRHvGwT2QKvYGshpkd2/8 VvJzJ2E26O04IwhGyABUwbeCsumbQAaqoxCrNLR3nA1z1EHA9CFkdpkOYRZ6k1Y= =MBDP -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 24 05:58:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD8112DCF8 for ; Wed, 24 Aug 2016 05:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 xQjDyBhyyhmC for ; Wed, 24 Aug 2016 05:58:45 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1E112DCF3 for ; Wed, 24 Aug 2016 05:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4169; q=dns/txt; s=iport; t=1472043521; x=1473253121; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tAe2KCtFlH7uyQwylS9VJuucvf+s2gbrSUavtHojsiY=; b=WkFsMx9nWKZISBhsy+eaNMZg8Ds8m9E8wpXhdV6pc7hzqdmAiLo9EgQn zAzYC04CBCa61GB5UwjygPJo9ogBlzOQBQvCN694V9eav+Rnm5eV91ETa lm82Jb1fG1p7m2BD9o1c6zdvBh64YRsXxzipaZGRmugNPtDTFCR1iwzgY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmBgDymL1X/49dJa1dgykBAQEBAR5Wf?= =?us-ascii?q?Ae6BSCCRoM3AoFDOxECAQEBAQEBAV4nhGEBAQMBATo/DAQCAQgRBAEBAR4JBzI?= =?us-ascii?q?UCQgCBAENBQiIIggOvxgBAQEBAQEBAQEBAQEBAQEBAQEBAQEchi2DSoEDihwFm?= =?us-ascii?q?UgBhh+Cf4V8gXROh0GFVIxAg3gBNCCDfXABh0B/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,570,1464652800"; d="scan'208";a="314827123" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2016 12:58:40 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7OCwd6S009106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Aug 2016 12:58:40 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 24 Aug 2016 08:58:38 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Wed, 24 Aug 2016 08:58:38 -0400 From: "Scott Fluhrer (sfluhrer)" To: Michael Richardson , Derek Atkins Thread-Topic: [IPsec] 4307bis/7321bis key sizes Thread-Index: AQHR/WeEAzrW+zv84EKO1xcY6Kz9FKBXIcGAgAALGQCAAKZGgIAAOn9A Date: Wed, 24 Aug 2016 12:58:38 +0000 Message-ID: <7d8a2db3d50c4e1fa3ff6c1f33eddaf4@XCH-RTP-006.cisco.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> <22632.1472015261@dooku.sandelman.ca> In-Reply-To: <22632.1472015261@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 12:58:47 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: Wednesday, August 24, 2016 1:08 AM > To: Derek Atkins > Cc: Paul Hoffman; ipsec@ietf.org; Paul Wouters; Tero Kivinen; Scott Fluhr= er > (sfluhrer) > Subject: Re: [IPsec] 4307bis/7321bis key sizes >=20 >=20 > Derek Atkins wrote: > >> The proposed change is based on the existence of quantum computers > that > >> have a sufficient number of properly-interacting qbits. We have > >> literally no idea if those computers will ever exist. All current = data > >> indicates that we will see the progressing of "sufficient number" = and > >> "properly-interacting" and be able to increase key sizes well ahea= d of > >> widespread use of quantum computers. >=20 > > Just to play devil's advocate here, are you implying that we'll see= a > > 5-10-year lead time on quantum computer development sufficiently in > order > > to spend those 5-10 years: > > 1) having this discussion again, > > 2) revving the documents > > 3) getting the revved documents through the process > > 4) getting the revved documents published > > 5) getting the revved documents implemented > > 6) getting that new implementation into the field, and (most import= antly) > > 7) getting the OLD hardware decommissioned? >=20 > Forgive my ignorance here; my BSc in particle physics is ~20 years out of= date. > (this %#@*$ internet thing distracted me...) >=20 > My understanding is we currently have a small number of qbits "properly- > interacting". I think that I read an article saying it was 4 or so, but = I just read > that we are at 12 qbits in 2006, 28 in 2007 (maybe), and >1000 in 2015 > (maybe). On the other hand, "2 qubit silicon gate" in 2016. >=20 > I believe that we need 128 to interact to break AES-128? Actually, rather more than that; see http://arxiv.org/pdf/1512.04965.pdf fo= r one rather detailed estimate. However, it doesn't appear that the number of qbits is the limiting factor;= instead, it is simply time. The best known quantum attack against AES is = Grover's algorithm; against AES-128, that would take O(2**64) entangled eva= luations of AES (where the constant of proportionality is somewhat larger t= han 1). In contrast, AES-256 would take O(2**128) such evaluations; we gen= erally agree that performing that many operations is infeasible for any pra= ctical attacker, and so we consider AES-256 safe. Actually, it's even worse than that for the attacker, even for AES-128; Gro= ver's algorithm isn't parallelizable, and so instead of 2**64 operations sp= read over a large computing cluster, we're talking about 2**64 run on a sin= gle thread, and that's far more difficult. There's no known parallelized a= pproach that's better than dividing up the keyspace into 2**k regions, and = running a separate instance of Grovers over each region (using 2**k indepen= dent quantum computers); this ends up taking 2**(128-k)/2 time. If the bou= nd on the number of evaluations a single quantum computer can do is 2**50 (= for example, 2**25 evaluations per second for a year), then the attacker wi= ll need 2**28 separate quantum computers. Does this mean that attacking AES-128 is infeasible? No; there are too man= y unknowns involved; it should be clear that applying the same argument to = AES-256 implies that the attacker has no hope. >=20 > I'm just trying understand how the revolution that will take us from ~12 = to > 128, won't take us to 256 the following week. >=20 > I feel kinda like we are re-arranging the chairs on the titanic here. No, the debate between AES-128 and AES-256 is more like "AES-128 *might* be= quantum secure; AES-256 is (baring some unexpected crypto development) *ve= ry* secure" >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 From nobody Wed Aug 24 10:08:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FF412D611 for ; Wed, 24 Aug 2016 10:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BCzezXR0zXHG for ; Wed, 24 Aug 2016 10:08:19 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3247A12D5B8 for ; Wed, 24 Aug 2016 10:08:18 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id g62so16552034lfe.3 for ; Wed, 24 Aug 2016 10:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version; bh=g35HGigFvQJEBIGLI7SkHxFmqQc9qyOiFmxmi+iA9lA=; b=ro8Lu6chuGgrQAIdOJ20hT/GD98ajz8j4tqVt6z5/8BEnHJ/+/H90aL0+WNv19uY/n COSFnMh6nHww9p1yhCD8Tun5cslvIPU//GeyvGS9/Dn1UpT/cBdIEb+LmAMFRc3KdmlG V9J9Hq+kMQTw7yVfjdfbxHhxCv6fAC5HWMVbyk2Qw/gZ7rFaeOXOqnkdBF0SPRMIuTyY zxWRMJDfiHqR1O+KGDNYjnrKMUvwx/Tbr/cxTN7INQUL71dcdqye2uhmGo40Ws7jBukb jM7G2Mcq/QYwtP5udBcaqMjoQucfRe7J4Lk6ryfEw9+uOfHr8Lly72/sh1opRH+7wBod b4og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version; bh=g35HGigFvQJEBIGLI7SkHxFmqQc9qyOiFmxmi+iA9lA=; b=h+ySiFz2VRB3Cv0TSJQjVRqHSTroiRzCYCDT0iQ2zJ1091gGKlNNg7XZeO/DBPWBSk rz3/JkUvd6zLlJ40UbtDqLjnXkClBfYtmjcHgOA5w+8jp+EBBs71SWEYf0PypkpPoqHo ZRMa+0xCsJCEa0NEjDhNR96C1ckQUmsER1hFj1ThSX8yA6I6A529dtxa2aywZt0peHKS cLtEqlN9fYXBrdSmL2IBbTIlB4qtgvu2R2ZIPoLE5gBMnB8VCzqZ6vZf5jnwh9E5eyLz 2/CyMivyzsOJPkzTiMuOdbymHPcCedJTYKKdWRZNttqrrcOUjQ4zyHd8aIYcGdG3nuw4 surw== X-Gm-Message-State: AE9vXwOvvAUdeH1uyg34PynPMHk0ZSX0VsafBoVOtiJHetrUuU/B/IidMghQjw3v6IfV8A== X-Received: by 10.25.16.212 with SMTP id 81mr1060194lfq.174.1472058496093; Wed, 24 Aug 2016 10:08:16 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r196sm2151543lfd.41.2016.08.24.10.08.14 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 24 Aug 2016 10:08:15 -0700 (PDT) Message-ID: <3FBE725260DA4CE2B3BCD9DA17BA2304@buildpc> From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , References: <9475723e788947debfbb36f23c40030e@XCH-RTP-006.cisco.com> Date: Wed, 24 Aug 2016 20:08:00 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0262_01D1FE43.3702CF50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 17:08:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0262_01D1FE43.3702CF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Scott, thank you for the list of requirements. My answers are inline. In Berlin, we decided to take up Quantum Resistance as a work item, = and that we should start talking about requirements. I'm starting this = thread in a hope of kicking off the discussion. =20 First of all, a solution to Quantum Resistance that is applicable = everywhere would involve replacing the (EC)DH exchange with a = postquantum key exchange. While this would be ideal, the = cryptographical community currently doesn't have a solution that is = sufficiently trusted and is of reasonable cost. So, it would make sense = to divide this into two efforts, a long term solution (which we may = initially put on the shelf, as the crypto pieces aren't there yet), and = a short term solution, to address the needs of customers that aren't = willing to wait; instead, they feel the need to protect traffic that is = encrypted now. For this short term solution, it's sufficient if we = don't necessarily cover all cases, a number of interesting cases (in = particular, ones for which redistributing secrets is doable) would be = sufficient. Does everyone agree with that general assessment? =20 If so, there here is a list of potential requirements (based on Tero's = list that he gave during the IETF, but with a few of my own), along with = my opinion: =20 - Simplicity; how large of a change to IKE (and IKE = implementations) are we willing to contemplate? Of course it is preferrable if the solution is simple. However, the = simplicity is difficult to measure, so it is mostly subjective. I would put the simplicity closer to the end = of the list of requirements. In other words - our goal is to provide a (temporary) QC-resistant = solution. If we manage to=20 get it simple - then it's good. o My opinion: minimizing changes to IKE should be given high = priority, both because "complexity is the enemy of security" and this is = a short term solution; if we have a solution that we can't = implement in a few years, well, we might as well wait for the crypto = people to give us the long term one. - Preserving existing IKE properties; how important is it = that our solution do not induce any weaknesses in IKE against an = adversary with a convention computer; that is, whatever we do, = we must not make things worse? This is important. o My opinion: I'm pretty sure that we'll all agree that this is = important (except for possibly the identity protection, see below); I = just want to state this as something we need to remember. - What do we feel needs to protected from someone with a = Quantum Computer? Do we feel the need to protect only the IPsec = traffic, or do we need to protect the IKE traffic as well. This requirement is related to the previous one. If we we = want to preserve existing IKE properties. then we should provide the solution that protects both IPsec = and IKE traffic. And I think it is important that IKE traffic is protected. It will allow to re-use this = solution in G-IKEv2 protocol without the need to re-invent it. o My opinion: I'm going to abstain on this one, except to note = that protecting only the IPsec traffic allows for a rather simple = implementation; now, if the WG decides that protecting the IKE = traffic is important, this simplicity is irrelevant. - What level of identity protection do we need to provide? = If two different IKE negotiations use the same shared secret, do we mind = if someone can deduce that? I think the ID protection is a nice thing to have, but I = won't consider it as the first proirity requirement. o My opinion: identity protection in IKE is rather overrated; I = suspect there's enough in the data exchange that an advanced adversary = (how can look at things such as packet length and packet timings) is = likely to get a fairly decent guess regardless. - PPK management; how much support do we provide for = automatically managing the secrets? No strong opinion here.=20 o My opinion: we already have preshared keys in IKE, and we = don't define any particular management scheme for them (even though they = are used quite often in practice). I don't see why we need to go out of = our way when it comes to these postquantum secrets. - How much support do we provide for nonstatic secrets, for = example, by QKD, or via something like HIMMO (a key distribution = mechanism that appears to be post quantum)? Again, no strong opinion here. o My opinion: I'd prefer it if we didn't spend a great deal of = time trying to come up with a solution that covers everything. However, = if we could include a hook that these schemes could take = advantage of (such as an opaque identifier that's passed that has = meaning to the PPK manager), that might be reasonable. - Authentication; if someone with a Quantum Computer can = break the DH in real time, do we care if he can act as a = man-in-the-middle? It would be nice if authentication is protected also. At = least to some extent (by the way, the curent draft seems to achive that, because the SKEYSEED is = dependant on the PPK, so any authentication method would be "augmented" by PPK). o My opinion: this draft is here mainly to protect = 'store-and-decrypt-later' attacks, and so this attack isn't as large of = a concern. On the other hand, we may very well get this for free; if we = include our 'post quantum secret' as an input to the KDF, then an active = attacker is foiled just like a passive attacker. - Algorithm agility; how important is it that we negotiate = any cryptoprimitives involved? I think it is important. I don't buy the argument that the = solution is intended to be temporary, so we can sacrifice the algorith agility. As far as I = understand the situation with "persistent" solution is currently very moot, so it is unpredictable for = how long this "temporary" solution will be in use. Probably it is 1-2 years, probably it is = 10-20 years. I definitely don't want to have a 20-year long solution without algorithm agility. o My opinion: this is of lesser importance, as this is a short = term solution. On the other hand, I am quite aware that others on this = list would disagree with me. =20 Well, here's my list of requirements (and my opinions); did I miss any = requirement that you think is important? What are you opinions about = these requirements? =20 Thanks! Regards, Valery. -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0262_01D1FE43.3702CF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Scott,
 
thank you for the list of requirements. My answers = are=20 inline.

In Berlin, we decided to take up Quantum = Resistance as a=20 work item, and that we should start talking about requirements.  = I=92m=20 starting this thread in a hope of kicking off the = discussion.

 

First of all, a solution to Quantum Resistance = that is=20 applicable everywhere would involve replacing the (EC)DH exchange with = a=20 postquantum key exchange.  While this would be ideal, the = cryptographical=20 community currently doesn=92t have a solution that is sufficiently = trusted and=20 is of reasonable cost.  So, it would make sense to divide this = into two=20 efforts, a long term solution (which we may initially put on the = shelf, as the=20 crypto pieces aren=92t there yet), and a short term solution, to = address the=20 needs of customers that aren=92t willing to wait; instead, they feel = the need to=20 protect traffic that is encrypted now.  For this short term = solution,=20 it=92s sufficient if we don=92t necessarily cover all cases, a number = of=20 interesting cases (in particular, ones for which redistributing = secrets is=20 doable) would be sufficient.  Does everyone agree with that = general=20 assessment?

 

If so, there here is a list of potential = requirements=20 (based on Tero=92s list that he gave during the IETF, but with a few = of my own),=20 along with my opinion:

 

-         =20 Simplicity; how large of a change to IKE (and = IKE=20 implementations) are we willing to = contemplate?

Of course it is preferrable if the solution is = simple.=20 However, the simplicity is difficult to measure,

so it is mostly subjective. I would put the = simplicity=20 closer to the end of the list of requirements.

In other words - our goal is to provide a = (temporary)=20 QC-resistant solution. If we manage to

get it simple - then it's good.

    o   = My opinion: minimizing changes to IKE = should be=20 given high priority, both because =93complexity is the enemy of = security=94 and=20 this is a short term solution; if     =     we=20 have a solution that we can=92t implement in a few years, well, we = might as well=20 wait for the crypto people to give us the long term=20 one.

   =20 -         =20 Preserving existing IKE properties; how = important is=20 it that our solution do not induce any weaknesses in IKE against an = adversary=20 with a convention         computer; that = is,=20 whatever we do, we must not make things worse?

This is = important.

o   = My opinion: I=92m pretty sure that = we=92ll all=20 agree that this is important (except for possibly the identity = protection, see=20 below); I just want to state this as something we need to=20 remember.

-         =20 What do we feel needs to protected from = someone with a=20 Quantum Computer?  Do we feel  the need to protect only the = IPsec=20 traffic, or do we need to protect the IKE traffic as = well.

   =20         This requirement is related to the = previous one. If we we want to preserve existing IKE = properties.

   =20         then we should provide the = solution that=20 protects both IPsec and IKE traffic. And I think it is = important

   =20         that IKE traffic is protected. It = will=20 allow to re-use this solution in G-IKEv2 protocol without the = need

   =20         to re-invent it.

    o   = My opinion: I=92m going to abstain on = this one,=20 except to note that protecting only the IPsec traffic allows for a = rather=20 simple implementation; now, if the WG     =    =20 decides that protecting the IKE traffic is important, this simplicity = is=20 irrelevant.

-         =20 What level of identity protection do we need = to=20 provide?  If two different IKE negotiations use the same shared = secret,=20 do we mind if someone can deduce that?

   =20         I think the ID protection is = a nice=20 thing to have, but I won't consider it as the first proirity=20 requirement.

    o   = My opinion: identity protection in IKE is = rather overrated; I suspect there=92s enough in the data exchange that = an=20 advanced adversary (how can look at things     such as = packet=20 length and packet timings) is likely to get a fairly decent guess=20 regardless.

-         =20  PPK management; how much support do we = provide=20 for automatically managing the secrets?

          =   No=20 strong opinion here.

    o   = My opinion: we already have preshared = keys in=20 IKE, and we don=92t define any particular management scheme for them = (even=20 though they are used quite often in practice).  I don=92t see why = we need=20 to go out of our way when it comes to these postquantum=20 secrets.

-         =20 How much support do we provide for nonstatic = secrets,=20 for example, by QKD, or via something like HIMMO (a key distribution = mechanism=20 that appears to be post quantum)?

   =20         Again, no strong opinion = here.

    o   = My opinion: I=92d prefer it if we = didn=92t spend a=20 great deal of time trying to come up with a solution that covers=20 everything.  However, if we could include a    =20     hook that these schemes could take advantage of = (such as an=20 opaque identifier that=92s passed that has meaning to the PPK = manager), that=20 might be reasonable.

-         =20 Authentication; if someone with a Quantum = Computer can=20 break the DH in real time, do we care if he can act as a=20 man-in-the-middle?

   =20         It would be nice if authentication = is=20 protected also. At least to some extent (by the way, the = curent

   =20         draft seems to achive that, = because the=20 SKEYSEED is dependant on the PPK, so any authentication

   =20         method would be "augmented" by=20 PPK).

    o   = My opinion: this draft is here mainly to=20 protect =91store-and-decrypt-later=92 attacks, and so this attack = isn=92t as large=20 of a concern.  On the other hand, we may very well get this for = free; if=20 we include our =91post quantum secret=92 as an input to the KDF, then = an active=20 attacker is foiled just like a passive attacker.

-         =20 Algorithm agility; how important is it that we = negotiate any cryptoprimitives involved?

   =20         I think it is important. I don't = buy the=20 argument that the solution is intended to be temporary,

   =20         so we can sacrifice the algorith = agility.=20 As far as I understand the situation with "persistent"

   =20         solution is currently very moot, = so it is=20 unpredictable for how long this "temporary" solution

   =20         will be in use. Probably it is 1-2 = years,=20 probably it is 10-20 years. I definitely don't want

   =20         to have a 20-year long solution = without=20 algorithm agility.

    o   = My opinion: this is of lesser importance, = as=20 this is a short term solution.  On the other hand, I am quite = aware that=20 others on this list would disagree with me=85

 

Well, here=92s my list of requirements (and my = opinions); did=20 I miss any requirement that you think is important?  What are you = opinions about these requirements?

 

Thanks!

Regards,

Valery.

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0262_01D1FE43.3702CF50-- From nobody Wed Aug 24 15:17:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96C12D178 for ; Wed, 24 Aug 2016 15:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hdS1YpDwMbfW for ; Wed, 24 Aug 2016 15:17:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB3212B026 for ; Wed, 24 Aug 2016 15:17:21 -0700 (PDT) Received: from sandelman.ca (162-253-141-186.dedicated.allstream.net [162.253.141.186]) by relay.sandelman.ca (Postfix) with ESMTPS id C00251F8FC; Wed, 24 Aug 2016 22:17:19 +0000 (UTC) Received: by sandelman.ca (Postfix, from userid 179) id 64D08659D9; Wed, 24 Aug 2016 18:17:15 -0400 (EDT) From: Michael Richardson To: "Scott Fluhrer \(sfluhrer\)" In-reply-to: <7d8a2db3d50c4e1fa3ff6c1f33eddaf4@XCH-RTP-006.cisco.com> References: <20160805034543.15860.28796.idtracker@ietfa.amsl.com> <04fc3cc06274464ca4b94746e50a67bc@XCH-RTP-006.cisco.com> <84F0EC1D-02BC-4892-9FC0-29B5E47A6D7F@vpnc.org> <22440.34261.193865.786849@fireball.acr.fi> <892D0256-4535-4AC7-9F7E-B2778DEDC276@vpnc.org> <22632.1472015261@dooku.sandelman.ca> <7d8a2db3d50c4e1fa3ff6c1f33eddaf4@XCH-RTP-006.cisco.com> Comments: In-reply-to "Scott Fluhrer (sfluhrer)" message dated "Wed, 24 Aug 2016 12:58:38 -0000." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Aug 2016 18:17:15 -0400 Message-ID: <3638.1472077035@dooku.sandelman.ca> Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Derek Atkins , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] 4307bis/7321bis key sizes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 22:17:23 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thank you for the reply, it helps me understand that AES-256 is worthwhile. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- (Camping this week!) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXvhzoAAoJEKD0KQ7Gj3P2h0sH/3/SXsoea0/i8ZfGArDQX3to s2A3nSbltVmxJF7GV9nPxba7u3sQpi86QMbMaCSproY9cnIYR2+JAEize8A4x0zB 0AUI3enBctJvMNEPWaNIGlduCfFvyTmDqoENYi6uruoNTbUpeLeO8VrYc9W9TGDK OXpD/bVVAmPVyqhNsrdhHTSk2a4GKxnaADXYY3juE+5Ls6tNhUKIecXf4kmYKzpa DIqNzy8DPmuOrPEDAzG/bx8L2BWgQrEaS55F0w7GXzQ9sUzOacNZmcVtFjE00T/W mgxF7yzluc4hhF7s104I7Z7ZEaduXoTfgrhb+SbjTgCE6fqMArF9wFGyNLr/ZWw= =hPKq -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 26 07:13:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5074112D799 for ; Fri, 26 Aug 2016 07:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 4gHbZHKipOzR for ; Fri, 26 Aug 2016 07:13:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B6412D803 for ; Fri, 26 Aug 2016 07:02:14 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7QE2Aoq025691 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 26 Aug 2016 17:02:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7QE2ABv020380; Fri, 26 Aug 2016 17:02:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22464.19426.464759.800837@fireball.acr.fi> Date: Fri, 26 Aug 2016 17:02:10 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <22444.27777.273959.299341@fireball.acr.fi> References: <22444.27777.273959.299341@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [IPsec] Working group Last call for draft-ietf-ipsecme-safecurves X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:13:27 -0000 Tero Kivinen writes: > Now when we have new version of the draft-ietf-ipsecme-safecurves, so > I will now start two week working group last call (WGLC) for > draft-ietf-ipsecme-safecurves-03 [1]. > > Please send your comments, questions etc to the WG mailing list before > 2016-08-25. If you belive that the document is ready to be submitted > to the IESG for consideration as a standard track RFC please send a > short message stating this. > > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ Working group last call ended, and there was no comments, so I think this document is ready to go forward. -- kivinen@iki.fi From nobody Fri Aug 26 07:14:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5112B010 for ; Fri, 26 Aug 2016 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 yjJNcFV9Er6Z for ; Fri, 26 Aug 2016 07:14:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B970512D768 for ; Fri, 26 Aug 2016 07:03:35 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7QE3XNL013059 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 26 Aug 2016 17:03:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7QE3XBA017789; Fri, 26 Aug 2016 17:03:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22464.19509.483817.103127@fireball.acr.fi> Date: Fri, 26 Aug 2016 17:03:33 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] IPsecME Status update 2016-08-26 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:14:29 -0000 Charter update New version posted to list 2016-07-20, no objection in list, should go forward, on the 2016-09-01 IESG telechat. Document Status: - draft-ietf-ipsecme-ddos-protection (David) WGLC should be done, ready to go forward. - draft-ietf-ipsecme-rfc4307bis (David) Should be ready for WGLC, new version with changes agreed in meeting done. - draft-mglt-ipsecme-rfc7321bis (David) New version posted what should align with 4307bis. This is agreed item on the charter, so we should do adoptation call for this document to be WG document. - draft-ietf-ipsecme-safecurves (Tero) New version submitted, WGLC ended 2016-08-25. No comments received, should be ready to go forward. - draft-nir-ipsecme-eddsa (Tero) I think this is still waiting for the curdle to decide for OID, but we could start WG adaptation call, as this is now in our charter, and this is good starting point. - draft-ietf-ipsecme-tcp-encaps (Tero) This should also be ready for WGLC. New work: - Quantum Resistance (David) Discussion has started on the mailing list about the requirements and when we have those decided on the list, we should start working on document. - draft-pauly-ipsecme-split-dns (David) This was accepted as charter item, but need few more reviews before taking it as WG draft. - draft-mglt-ipsecme-implicit-iv (Tero) This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. -- kivinen@iki.fi From nobody Mon Aug 29 18:21:27 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC4B12B01A; Mon, 29 Aug 2016 18:21:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147252008248.19114.6268958851439201313.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 18:21:22 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 01:21:22 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ipsecme-10-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This sentence doesn't parse for me - or maybe I just need more security clue? "IKEv1 using shared secret authentication was partially resistance to quantum computers." I don't object to this text "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE packets need to be encapsulated in a TCP tunnel. The group will define a mechanism to tunnel IKE and IPsec over a TCP-based connection. This method is intended to be used as a fallback when IKE cannot be negotiated over UDP. The group will create a method where IKEv2 and IPsec packets can be encapsulated in the TCP connection." going for external review, but I'd love to understand better what the resulting protocol stack looks like. I get the part about encapsulating IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a general-purpose "IP over TCP" mechanism? From nobody Mon Aug 29 20:28:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C0D12D0E1; Mon, 29 Aug 2016 20:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 CHfExu2NSrUv; Mon, 29 Aug 2016 20:28:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5DA12D0C2; Mon, 29 Aug 2016 20:28:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sNYrp1DHkz1PC; Tue, 30 Aug 2016 05:28:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472527722; bh=eRfmlqWi3FtISOrY01/rG7tL+bJuYn8ReVh58svT6KI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gLcd5c9eYQmV7QTx8GBahR79R6zbwrX5WuZU/4KVPiygrT/n9se0iw5RgnrJ/iTN8 mj5Vb0EyrksoHVhyxJt2o1v/zBFOSDnO+cDCEGDiiaVStAO+/86yJ0/+mnaxDgthx3 6QGWQ82w1VXkgwj1XV0cE1MU+k86GwG1AhwJcMyc= 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 kYdgVWOHfgda; Tue, 30 Aug 2016 05:28:40 +0200 (CEST) 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; Tue, 30 Aug 2016 05:28:40 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8239F3522EC; Mon, 29 Aug 2016 23:28:37 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 8239F3522EC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7926F416432B; Mon, 29 Aug 2016 23:28:37 -0400 (EDT) Date: Mon, 29 Aug 2016 23:28:37 -0400 (EDT) From: Paul Wouters To: Spencer Dawkins In-Reply-To: <147252008248.19114.6268958851439201313.idtracker@ietfa.amsl.com> Message-ID: References: <147252008248.19114.6268958851439201313.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 03:28:47 -0000 On Mon, 29 Aug 2016, Spencer Dawkins wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This sentence doesn't parse for me - or maybe I just need more security > clue? > > "IKEv1 using shared secret authentication was partially resistance to > quantum computers." s/resistance/resistant > I don't object to this text > > "There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE packets need to be > encapsulated in a TCP tunnel. "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec tunnel was not meant. Instead, we meant "encapsulated in TCP". > The group will define a mechanism to > tunnel IKE and IPsec over a TCP-based connection. This method is > intended to be used as a fallback when IKE cannot be negotiated over > UDP. The group will create a method where IKEv2 and IPsec packets can > be encapsulated in the TCP connection." > going for external review, but I'd love to understand better what the > resulting protocol stack looks like. I get the part about encapsulating > IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a > general-purpose "IP over TCP" mechanism? It will be "ESP over TCP" similar to how we now have "ESP over UDP". Paul From nobody Tue Aug 30 02:23:56 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD07612D099; Tue, 30 Aug 2016 02:23:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147254903470.23674.2069674175627586485.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 02:23:54 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 09:23:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Curve25519 and Curve448 for IKEv2 Key Agreement Authors : Yoav Nir Simon Josefsson Filename : draft-ietf-ipsecme-safecurves-04.txt Pages : 7 Date : 2016-08-30 Abstract: This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 30 02:26:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A7612D14B for ; Tue, 30 Aug 2016 02:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QYwlgSe5Sp7v for ; Tue, 30 Aug 2016 02:26:35 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE9812B024 for ; Tue, 30 Aug 2016 02:26:34 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i5so25126197wmg.0 for ; Tue, 30 Aug 2016 02:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YzZHbx7jLZudKoY8H43g+4TG+CylQkgccrSKwWiDqew=; b=aP3w2LU5GS/58sLHw85o5NvhKgMr1sLMGvivdF/PdxuRznx+DgHKgqvyQ+iPbSOfrd fXqnrByyVNFLC4I2dIeWkDhVzikhpbtO0U7grqSSCfAJ+zrPDStNOP/uQQ9oOFn4X3T3 Qe8Yc5h54f6aznb3KaCVh58mIPKnJbPf5c9jXYmCNqa3r8CaDVuR5C9jdM4oJ8mF5d2Y moogyJMRKSlQ4U6jV9b/AVUm64+hdJ3ZnoWEQRTnwpvnjhEE0uCF5Xn+A0QvNUnKRctV ZmHrZRqEgta3QyGcKqO8S0auS0vsqiy8AtOwoE7025hVE5SI3IZYGTjpSezSAgJVwMSY LpFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YzZHbx7jLZudKoY8H43g+4TG+CylQkgccrSKwWiDqew=; b=gw7VLZrGtvgq4gWBPbV35gnWx0nk1ILh6T/9E68eCLb9zT8xtwsaUDJgONWZ/qZ12z PzKqMpHjMh9+rAVvNKrR8vKJvBDROzv4fpe14VNkOHo1UbY+igVmNX3tMYdhH8XsY/1v gU6q72l48vymlZR3mMfZ1jxw850KWRh6zai82PAuQCQj62HYuGf+p8nBth6z3KaTu1iG jUdFuEwCzI/qKg7ny8qBP5CIoXU0EuJPhvOZ8xnGAst24vQMD7m9HV6C1Rs6TeiSUxrP hp8pq10BW35fdCLKlukyDYM5U6WcU91WQ1w0i1mgObpVyQGgYN4nNNCIlNfqTWXHfmBT 7UyQ== X-Gm-Message-State: AE9vXwPkLg6OdY/U+1OJdBzSlXTeYaJtsQiphfxk744HS2uadsuQb8Lhwj/rl8z4NMijgQ== X-Received: by 10.194.187.7 with SMTP id fo7mr2340973wjc.162.1472549193192; Tue, 30 Aug 2016 02:26:33 -0700 (PDT) Received: from [172.24.250.245] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id r16sm17677374wme.16.2016.08.30.02.26.32 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 30 Aug 2016 02:26:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <147254903470.23674.2069674175627586485.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 12:26:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147254903470.23674.2069674175627586485.idtracker@ietfa.amsl.com> To: IPsecME WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 09:26:37 -0000 Just an updated reference.=20 Yoav > On 30 Aug 2016, at 12:23 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions of the IETF. >=20 > Title : Curve25519 and Curve448 for IKEv2 Key = Agreement > Authors : Yoav Nir > Simon Josefsson > Filename : draft-ietf-ipsecme-safecurves-04.txt > Pages : 7 > Date : 2016-08-30 >=20 > Abstract: > This document describes the use of Curve25519 and Curve448 for > ephemeral key exchange in the Internet Key Exchange (IKEv2) = protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-safecurves-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Aug 30 06:38:50 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D212D58A; Tue, 30 Aug 2016 06:38:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 06:38:48 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 13:38:49 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-ipsecme-10-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There are some typos (s/MIT/MTI) and bits of English that need to be tidied up. I have a suggestion about this bit of work: "IKEv1 using shared secret authentication was partially resistance to quantum computers. IKEv2 removed this feature to make the protocol more usable. The working group will add a mode to IKEv2 or otherwise modify IKEv2 to have similar quantum resistant properties than IKEv1 had." My suggestion is twofold: 1) - s/will add/will consider adding/ and to add to the end: 2) "In doing this work the WG will consider ongoing work on quantum-resistance in the CFRG, and whether it is better to re-instate the same level of resistance that was present in IKEv1 or to wait for more recent work (e.g. in CFRG) to mature." The reason I suggest this is that it's possible the WG might conclude that it's better to wait for some newer QR stuff from CFRG. The current wording seems to commit the WG to firing ahead anyway, and we might overall be better if there are fewer QR mechanisms proposed, rather than adding some now when it might be better to wait a while longer. From nobody Tue Aug 30 08:26:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B375312D746; Tue, 30 Aug 2016 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HX0LMQRlSJ0C; Tue, 30 Aug 2016 08:26:38 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52E512D6AB; Tue, 30 Aug 2016 08:09:35 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id q128so125434946wma.1; Tue, 30 Aug 2016 08:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOJwMTDtO9NRtvy4nt6Jy9IEM7N6lRNhdqVJAXbsdr4=; b=MpKEdfqqrHZ6KirrtZC1ewGd4banTj87WJOO96EzTk/kZlqT1lO9m5s7RvFbycD1Pf w/Y9sOZdkqCqbV6MslzKz0jI57Icq6cXEYufT7RXrKZSOXele1KZxfYfEZQGEHp4mqYA vJuDnvhjBfqs6/x14Ki68djtIhcHU5Nxl23G8LgAb/S/S/97HbcwqWiqDn0K7kcDXIKL 2KqJYRGKI/apj1H6rbgAhy6IAbLJqCitpUzQP4GTPE9oP3ycC6LHL9LKx/Q5sh2e3vcz QHI5le6efslUYAB0Os0W8YzRAVrvsjjqQGulRJ+9wimQH4m4V3arpiKSbg1puL5UhnzG OyuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOJwMTDtO9NRtvy4nt6Jy9IEM7N6lRNhdqVJAXbsdr4=; b=Pt6OZ0AbUPPLJW/RafulYg615qwlxUCsNxUsudYseUTIZ06e7StXpWALLE4Bxnd5Aa 3VAvkFMdnezKB0lNtVlXwh6HMHGVAdwnB3K8Q43/gYEfWjWxpVV4x4pdLfk/42iNPyg7 /5Chj2DMzAPV4h/0RYIY/YN/NsH1Dt6ecxPBU+WHevoqg7NwEUuQSmoV/xgviTgWgyHP z4+O5LMxcdfLscYNV+66dHSS1rs2oM71GV3lu4abzSUnSFU1KGl0OMNzI4B2Y1BRk5kr NbBJpGq3oSxy0M/oZk/ShyQoNF3E6YR6e0IabAmZ6wD48buhbHPBUIvcGytr2tcB45Ub H5YQ== X-Gm-Message-State: AE9vXwNIKtVcHakW91RpsglBQaaaOfK1XBUNkvuTnWfpmg0lenbkUsY2/t35bSU7JnvvHQ== X-Received: by 10.194.11.72 with SMTP id o8mr3766265wjb.10.1472569774138; Tue, 30 Aug 2016 08:09:34 -0700 (PDT) Received: from [192.168.137.236] ([176.13.226.7]) by smtp.gmail.com with ESMTPSA id g67sm4402226wme.5.2016.08.30.08.09.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 30 Aug 2016 08:09:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2016 18:09:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <326E63EE-94C3-4C4F-A5FF-AC29BBDFA782@gmail.com> References: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 15:26:40 -0000 Hi, Stephen > On 30 Aug 2016, at 4:38 PM, Stephen Farrell = wrote: > I have a suggestion about this bit of work: >=20 > "IKEv1 using shared secret authentication was partially resistance to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will add a mode to IKEv2 or otherwise > modify IKEv2 to have similar quantum resistant properties than IKEv1 > had." >=20 > My suggestion is twofold: >=20 > 1) - s/will add/will consider adding/ >=20 > and to add to the end: >=20 > 2) "In doing this work the WG will consider ongoing work on > quantum-resistance=20 > in the CFRG, and whether it is better to re-instate the same level of > resistance > that was present in IKEv1 or to wait for more recent work (e.g. in = CFRG) > to=20 > mature." >=20 > The reason I suggest this is that it's possible the WG might conclude > that > it's better to wait for some newer QR stuff from CFRG. The current > wording > seems to commit the WG to firing ahead anyway, and we might overall be > better if there are fewer QR mechanisms proposed, rather than adding > some > now when it might be better to wait a while longer. There is a reason for this language. Obviously what this item suggests = is not the solution to the QC-equipped adversary that we are looking = for. But the good solution is not likely to surface any time soon.=20 In the meantime we are hearing that some deployments are reverting to = IKEv1 because of its perceived better quantum resistance. IKEv1 has been = deprecated for over ten years. In addition to some objective shortfalls, = IKEv1 has been considered a legacy feature for many implementers. For an = anecdote, we never bothered to implement IPv6 support in IKEv1. The = prospect of a user demanding not to have to choose between IPv6 and = quantum resistance is not something I look forward to. This is the motivation behind this item. If we were looking for the good = solution this item should probably have been phrased as =E2=80=9Cthe WG = will follow research into quantum resistant algorithms for = authentication and key exchange and consider their suitability to = IKE=E2=80=9D, because I don=E2=80=99t think we=E2=80=99re going to have = something concrete in the next 3-5 years. Fixing this to make it no = worse than IKEv1 (not aiming very high, I guess) is doable in months. Yoav From nobody Tue Aug 30 11:56:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0012D7E5; Tue, 30 Aug 2016 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aIoy060rwNii; Tue, 30 Aug 2016 11:55:45 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DBD12D7E4; Tue, 30 Aug 2016 11:55:43 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id m60so49118607uam.3; Tue, 30 Aug 2016 11:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wrOAwgBeeCNonmdIrPdYH0zWeeKHB7xLHBXw0VJIrLA=; b=D3TCOyCG5wBrePbk1CW0HHTG5m5HfvGiumQtSZxxvjuaapIuYoZMQb2I3M3NA0GxyI mk8PTPIy22S9swQmh16za2WmjBZ5jnpyM91k1JcdMKkY4Kg11LKwl7d+XJEgsJlxrNm4 N/QJoK3abaLMQLink8aFIWaoD+Kjct9EVGjM72JW9zLwtyTY5Nk2NZRWh4qVEGMiuCzb e4D0LI/Vx+FxnSG7qUwQH8TgMnEa2+X6XnvLA8te1YfWHMGFSXY3Iw18HQM29D2saH5v FMFxqf8hiw2P3s7Gj6Fj1BPft39fkF6KJdSfAUyUKxW67Y47SQfIopox9TXz6dF1CWas ILSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wrOAwgBeeCNonmdIrPdYH0zWeeKHB7xLHBXw0VJIrLA=; b=O5fn4eJV8JG4Ph95UxoRkSGViCN9OVib/E4q41kUBv9IPfjjEHgv0nzHSLwT9olpyx 3Cuo+Wd088KW5U1YIbRdyu3/WJVZ5+xkwk/9Rgl0E1dPNTSapqtzhtSwWlNL+rwKmF8C wQucC6u69h3YeLn4BiPgfL+/BK5vqVKPxdwrnQNnsDZUIOt/T+2weIPMHWutJyOQftNM I0454W5MUpsSvPwpFlMbDWSck0GcJQyfmq+dkXG2+4riulN0z4c8sjdVBFhq2cEfBqNp jUEiyOJrDj/7bhpilOrDiwu3Ocr5THbdQBNQtZaFBQBGDZUgSKs4v2mge93/57LV5F1r vcQQ== X-Gm-Message-State: AE9vXwOrJA46JlPMDlgr5jY3iKjvEPOm6CUBf17f5KOm4K62KUvHNfqzqesNUMf/V1RzGeMRHSbRXaSkOEjbWg== X-Received: by 10.159.34.177 with SMTP id 46mr3113082uan.111.1472583342672; Tue, 30 Aug 2016 11:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Tue, 30 Aug 2016 11:55:42 -0700 (PDT) In-Reply-To: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> References: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 30 Aug 2016 14:55:42 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 18:55:56 -0000 On Tue, Aug 30, 2016 at 9:38 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-ipsecme-10-00: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > There are some typos (s/MIT/MTI) and bits of English that > need to be tidied up. I went ahead and changed the one instance of MIT to MTI, thanks for catching that. I also read through through the English as well again and suggest changing the second to last paragraph to the following: Currently, widely used counter mode based ciphers send both the ESP sequence number and IV in form of counter, as they are very commonly the same. There has been interest to work on a document that will compress the packet and derive IV from the sequence number instead of sending it in separate field. The working group will specify how this compression can be negotiated in the IKEv2, and specify how the encryption algorithm and ESP format is used in this case. > > I have a suggestion about this bit of work: > > "IKEv1 using shared secret authentication was partially resistance to > quantum computers. IKEv2 removed this feature to make the protocol > more usable. The working group will add a mode to IKEv2 or otherwise > modify IKEv2 to have similar quantum resistant properties than IKEv1 > had." > > My suggestion is twofold: > > 1) - s/will add/will consider adding/ > > and to add to the end: > > 2) "In doing this work the WG will consider ongoing work on > quantum-resistance > in the CFRG, and whether it is better to re-instate the same level of > resistance > that was present in IKEv1 or to wait for more recent work (e.g. in CFRG) > to > mature." > > The reason I suggest this is that it's possible the WG might conclude > that > it's better to wait for some newer QR stuff from CFRG. The current > wording > seems to commit the WG to firing ahead anyway, and we might overall be > better if there are fewer QR mechanisms proposed, rather than adding > some > now when it might be better to wait a while longer. I'll leave this text alone from the WG response, at least for now. Being able to work on it in months makes sense even if it isn't the best long term solution. Thanks, Kathleen > > -- Best regards, Kathleen From nobody Tue Aug 30 12:05:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1623112D1CB; Tue, 30 Aug 2016 12:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2fN8oWaF-Zrr; Tue, 30 Aug 2016 12:05:40 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0DC12D7E6; Tue, 30 Aug 2016 12:05:40 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id l94so49853851ual.0; Tue, 30 Aug 2016 12:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fhFAGWMsGV/1h/Y7k/Gf8mPzw5ScOvyrBTZ5hjQKAjs=; b=GLIKTH9vbBidN58j1BXj9LL/MR3XPrRe8wiAbktFiPj2HpV+WkHbbkihujN/yo6zcg BxLjqL/K12PwQfghm6VPOquPK6lM/qlqC94dVwyQy/YBl641xg+vRQ7O7p6u5AarZ7jB 4LAqA8c9HUQ4qZgkMA4JZ7P4yiWZT8bVbhLEPOnkz1qgc2kbGYZtW2kQWjonzDHBnL7N 33HXr/kHjuCZcDV3SEyoDWsQny4Ikb588ov4SKYK1AnlSPy6jqMLM+Rrr00UTjYsj+30 R5RD+HeFd3v1K0DbLA4DybVJvHimItvEQgkZ/u1cdgPJiESJyanYb7n6aI0bwQXzP39D Etxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fhFAGWMsGV/1h/Y7k/Gf8mPzw5ScOvyrBTZ5hjQKAjs=; b=l6ahVHzLowegXcFMUh5OCVmtd34TTvPVo/z9AQAxA/vM1YjJkhl+e5+mR+HJHG5KiS c3t34IoZAavmdV4eC2gbB55b7oHpbGdB1iN1sZpC+D+u9m+WFzc0uebhdN4AuodEiAlU pIQV/8+eVcpazQr0Q9mqQSzT5U8W7BCC2MDo/zgrX5gHOrF2uQ0wWZhbC8n8IR4G9/Ji NFJ7tNdvYDlNjueW0bLOEi6bEN2SjEgbOFUFiz86vxDWRHiquHiAtUuLLLEikeaFAcDS iMqJtn84FrqCrzJRLcIf75G5DVlvd8YgB6VPeMLKClNTIL4gBd7PNK37O9bugPTcJ5y8 3gdw== X-Gm-Message-State: AE9vXwPChTUfKBu9D7urPs+76wOsC7A13ZeXseoXFfErHjJL5F2j9YTjsO+/Afjdf9qQmZqq5pxr6xqOQwBe5w== X-Received: by 10.31.98.133 with SMTP id w127mr3127782vkb.29.1472583939853; Tue, 30 Aug 2016 12:05:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Tue, 30 Aug 2016 12:05:39 -0700 (PDT) In-Reply-To: References: <147252008248.19114.6268958851439201313.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 30 Aug 2016 15:05:39 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, Spencer Dawkins , The IESG Subject: Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 19:05:42 -0000 On Mon, Aug 29, 2016 at 11:28 PM, Paul Wouters wrote: > On Mon, 29 Aug 2016, Spencer Dawkins wrote: > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This sentence doesn't parse for me - or maybe I just need more security >> clue? >> >> "IKEv1 using shared secret authentication was partially resistance to >> quantum computers." > > > s/resistance/resistant Update has been made, thanks. > >> I don't object to this text >> >> "There have been middle boxes blocking IKE negotiation over UDP. To >> make IKE work in these environments, IKE packets need to be >> encapsulated in a TCP tunnel. > > > "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec > tunnel was not meant. Instead, we meant "encapsulated in TCP". OK, I am changing this text too, thanks. > >> The group will define a mechanism to >> tunnel IKE and IPsec over a TCP-based connection. This method is >> intended to be used as a fallback when IKE cannot be negotiated over >> UDP. The group will create a method where IKEv2 and IPsec packets can >> be encapsulated in the TCP connection." > > > >> going for external review, but I'd love to understand better what the >> resulting protocol stack looks like. I get the part about encapsulating >> IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a >> general-purpose "IP over TCP" mechanism? > > > It will be "ESP over TCP" similar to how we now have "ESP over UDP". We should be more explicit here, I agree with Spencer. The IKE part is clear since that's UPD 500. Would this be transport mode ESP only? If that's the case, how is the following alteration to the text: The group will define a mechanism to tunnel IKE and IPsec over a TCP-based connection. This method is intended to be used as a fallback when IKE cannot be negotiated over UDP. The group will create a method where IKEv2 and IPsec ESP transport mode packets can be encapsulated in the TCP connection." Working group: If I've changed the intent too much, please suggest other wording. Thanks > > Paul > -- Best regards, Kathleen From nobody Tue Aug 30 12:07:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B295A12D7FB; Tue, 30 Aug 2016 12:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 6kcBI1AiagDX; Tue, 30 Aug 2016 12:06:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E96512D7EF; Tue, 30 Aug 2016 12:06:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6B3C8BE33; Tue, 30 Aug 2016 20:06:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oaK_z0uGlMs; Tue, 30 Aug 2016 20:06:35 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF97DBE2C; Tue, 30 Aug 2016 20:06:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472583995; bh=JJ8W+oSfZt64jc9iFx0/u31oCkTTnUQzVAYsdyJw1jo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=K0Mge1evjhOcYx4WXIfVUGmDIGqKvVjK65cXy7ZsDCxG7ppNvMqWL2wO/yKHHtyh0 ud1Tl+cVmfn3Gy22VaFIwwvQeDXvUUGbCt+SPfG00rIOI/02VPth1zZytVmHsZLDIy k0I4FzF/YxxiJcMYjLD9/p4UbJ3T8JsU0yutB1O0= To: Kathleen Moriarty References: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 30 Aug 2016 20:06:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000301030306010101070408" Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 19:06:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000301030306010101070408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30/08/16 19:55, Kathleen Moriarty wrote: > I'll leave this text alone from the WG response, at least for now. > Being able to work on it in months makes sense even if it isn't the > best long term solution. I'm ok with that. But note that my suggested wording is not meant to commit the WG to waiting on CFRG, only to leave that call for later. S. --------------ms000301030306010101070408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MzAx OTA2MzRaMC8GCSqGSIb3DQEJBDEiBCCs0xihAMZB3Hbsv06p9MQExxt6LhxNLv5U+eUr30aQ fTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAHIB3ml+8SiL709KwsIA/dDjxKXcj/2b3/OyMr9yp2N7BBe1s5BrCP kFjV0eVk9gG+afaMcrOmvVwwzVLh7MhTr1cgq9YQ4tOUkN3C+ckgLZD0cS4jG1vYym0nJydx uxmUAsdHC+zbT63eXsTZv/1e9rkFYxXaRyvRf/sJiKL2FSqs4KZA6TTcxxXAcl+B6bdbDZps mMAenX07gTgZ3PWY2nijfthsdAYFKRD2S/HuzJoIqUb5GWVMEHDSGEWQw0Q89wWvzph9ihNp xptiORnUq9Vz2FtQDPJa7ON4eNVVGiM4FdOztfOFdRI6H1Ro5j2rmdPQDojLtLDQLKbOQyMV AAAAAAAA --------------ms000301030306010101070408-- From nobody Tue Aug 30 12:10:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD6512D7F9; Tue, 30 Aug 2016 12:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rWwbSKs-B1j9; Tue, 30 Aug 2016 12:10:38 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BD212D74A; Tue, 30 Aug 2016 12:10:38 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id l94so50098851ual.0; Tue, 30 Aug 2016 12:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eOx43xyO03jYUYqDTyRuIVd0zUqqS1vQ/2uZFLyLfWc=; b=LZdG+Ng2f9RHPvW8RpzkSW0b4bqIWYX2ZdOEhTySbYZO5A2Hpo5YEXaHimzM4Cu9tT JU3ERbYHzYdvni+XxUV7NEvGCojxhyzAqGllCxw6OmHshMTlTyDFkjiaJB4CPsCOTLYg 7LFy5viSLHG1Ac8w/q1ZIZMm16SSTIUkLj8td+we/Elyijg/OpZGXHSJXLT9yPX9tsja xAAYrivKBKKrNEzCgT4FYbBrJvzAJ7QN9UBR6C8H7bSyAf0O/Wih+5G9hLbZnIKESCbM 3dI48DIIiKskCJR4o1lgxGaGXR2PzVIb1GKet4OELaze4e+83d+f1c08UQTm80XdlqV1 60Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eOx43xyO03jYUYqDTyRuIVd0zUqqS1vQ/2uZFLyLfWc=; b=k74xxQJKML9R1KcgUrWI8dFK6upJKfEk/i8kGk4XTm9PJkd6/fdUWGi+UxHK2zN+/b yZtKXGOx9Q8/Efz6tXS/JrJykHXHy+uVUx6EKhRYyTw/7foolFfssSMaYE0+kajCkylV O8gZ2qw/EJkbqefwERNyX8S16yDFaXi+0c5rfqlIlbRKKFU7m4f3HrdaSBoTNJlt0FHV rdVjCNiBTzbTwuFqtggeJKBaWv637XtL0+s/dc1zQQ1XJcq/YC+El5L415SP0aAcG2OV /Hq9lZo5I3BUBzBfu6+EPE1LxVdIgggOTAXFUaynLgLoXHU0TQjTwfI4wxkSNN89o5G2 JCKA== X-Gm-Message-State: AE9vXwOC7Bu1UdiLQVhcFyS+LlbJDWBjeeNuumlnZPiPCbUTXBlwOzMnC8eH33sZrf2KJGVnfhjEFSKHmipqJg== X-Received: by 10.176.1.67 with SMTP id 61mr2670822uak.99.1472584237211; Tue, 30 Aug 2016 12:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Tue, 30 Aug 2016 12:10:36 -0700 (PDT) In-Reply-To: References: <147256432865.23813.9321516334774936538.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 30 Aug 2016 15:10:36 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 19:10:40 -0000 On Tue, Aug 30, 2016 at 3:06 PM, Stephen Farrell wrote: > > > On 30/08/16 19:55, Kathleen Moriarty wrote: >> I'll leave this text alone from the WG response, at least for now. >> Being able to work on it in months makes sense even if it isn't the >> best long term solution. > > I'm ok with that. But note that my suggested wording is not meant > to commit the WG to waiting on CFRG, only to leave that call for > later. If others from the WG want to chime in, please do. I'll help with the text updates as agreed. Thanks! > > S. > -- Best regards, Kathleen From nobody Wed Aug 31 03:24:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8646112DAD5 for ; Wed, 31 Aug 2016 03:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 ideS-9V7rz9J for ; Wed, 31 Aug 2016 03:23:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AB212DACC for ; Wed, 31 Aug 2016 03:23:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7VANkXn005980 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Aug 2016 13:23:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7VANjMb016993; Wed, 31 Aug 2016 13:23:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22470.45104.891974.85938@fireball.acr.fi> Date: Wed, 31 Aug 2016 13:23:44 +0300 From: Tero Kivinen To: Kathleen Moriarty In-Reply-To: References: <147252008248.19114.6268958851439201313.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 17 min Archived-At: Cc: ipsecme-chairs@ietf.org, "ipsecme-chairs@tools.ietf.org" , "ipsec@ietf.org" , Spencer Dawkins , Paul Wouters , The IESG Subject: Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 10:23:55 -0000 Kathleen Moriarty writes: > >> "There have been middle boxes blocking IKE negotiation over UDP. To > >> make IKE work in these environments, IKE packets need to be > >> encapsulated in a TCP tunnel. > > > > > > "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec > > tunnel was not meant. Instead, we meant "encapsulated in TCP". > > OK, I am changing this text too, thanks. > > > >> The group will define a mechanism to > >> tunnel IKE and IPsec over a TCP-based connection. This method is > >> intended to be used as a fallback when IKE cannot be negotiated over > >> UDP. The group will create a method where IKEv2 and IPsec packets can > >> be encapsulated in the TCP connection." > > > > > > > >> going for external review, but I'd love to understand better what the > >> resulting protocol stack looks like. I get the part about encapsulating > >> IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a > >> general-purpose "IP over TCP" mechanism? > > > > > > It will be "ESP over TCP" similar to how we now have "ESP over UDP". > > We should be more explicit here, I agree with Spencer. The IKE part > is clear since that's UPD 500. Would this be transport mode ESP only? > If that's the case, how is the following alteration to the text: > > The group will define a mechanism to > tunnel IKE and IPsec over a TCP-based connection. This method is > intended to be used as a fallback when IKE cannot be negotiated over > UDP. The group will create a method where IKEv2 and IPsec ESP > transport mode packets can > be encapsulated in the TCP connection." > > Working group: If I've changed the intent too much, please suggest > other wording. The traffic inside the TCP-based connection is usually ESP tunnel mode, not transport mode, so the change you made is limiting it too much. I.e., this is intended for mobile phones / laptops etc doing VPN connection from the hotel to the enterprice vpn gateway and where the hotel etc firewall blocks all UDP traffic. So when UDP does not work we make TCP connection and encapsulate all IKE and ESP packets to that TCP connection. On those cases the VPN gateway usually assigns internal IP-address to the mobile device using configuration payloads in IKE, and then the mobile device uses tunnel mode ESP to send data to the internal enterprice network. So at least remove the "transport mode" and then it should be ok. The protocol stack will look like this: Data packet: IKEv2 packet Application data TCP header IKEv2 packet Inner IP-header IKEv2 header ESP Non-ESP Marker Length Length TCP header TCP header Outer IP-header Outer IP-header (Of course as this runs over normal TCP connection, the Length ESP + Inner IP-header + TCP header + Application data might get splitted to multiple actual packets, or there might be multiple inner packets inside the same TCP packet). This is similar than what we already have when doing UDP encapsulation of IPsec (RFC3948): 3.4. Tunnel Mode ESP Encapsulation ... AFTER APPLYING ESP/UDP -------------------------------------------------------------- IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| -------------------------------------------------------------- |<------------ encrypted ----------->| |<------------- authenticated ------------>| but instead of "UDP Hdr" we have TCP connection. -- kivinen@iki.fi From nobody Wed Aug 31 03:46:01 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B19C112D143; Wed, 31 Aug 2016 03:45:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 03:45:59 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 10:46:00 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-ipsecme-10-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Similar to Spencer's commet I have problems understanding what the following really means: "To make IKE work in these environments, IKE packets need to be encapsulated in a TCP tunnel. The group will define a mechanism to tunnel IKE and IPsec over a TCP-based connection. This method is intended to be used as a fallback when IKE cannot be negotiated over UDP. The group will create a method where IKEv2 and IPsec packets can be encapsulated in the TCP connection." Based on Tero's mail I understand how the stack looks like but that's not clear from the text because there is not really anything like a TCP tunnel. So the big question is, based on the stack indicated by Tero, do you have two full TCP connections running with two congestion control loops and retransmission mechanisms on two different endpoints? That's nothing I would recommend. I fully understand the need for a fallback mechanism to TCP but depending on what you actually aim for I'm not sure if this is the right wg for it; therefore my block for now. I hope we can resolve that quickly! From nobody Wed Aug 31 04:57:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887DD12DB19; Wed, 31 Aug 2016 04:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 F90TwwswVdCY; Wed, 31 Aug 2016 04:57:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7336812DB13; Wed, 31 Aug 2016 04:57:43 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7VBvfGu016156 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Aug 2016 14:57:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7VBveXF003791; Wed, 31 Aug 2016 14:57:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22470.50740.674721.131053@fireball.acr.fi> Date: Wed, 31 Aug 2016 14:57:40 +0300 From: Tero Kivinen To: "Mirja Kuehlewind" In-Reply-To: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 15 min Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 11:57:44 -0000 Mirja Kuehlewind writes: > Similar to Spencer's commet I have problems understanding what the > following really means: > > "To make IKE work in these environments, IKE packets need to be > encapsulated in a TCP tunnel. The group will define a mechanism to > tunnel IKE and IPsec over a TCP-based connection. This method is > intended to be used as a fallback when IKE cannot be negotiated over > UDP. The group will create a method where IKEv2 and IPsec packets can > be encapsulated in the TCP connection." > > Based on Tero's mail I understand how the stack looks like but that's not > clear from the text because there is not really anything like a TCP > tunnel. So the big question is, based on the stack indicated by Tero, do > you have two full TCP connections running with two congestion control > loops and retransmission mechanisms on two different endpoints? That's > nothing I would recommend. Short answer: Yes. There will be TCP inside TCP. > I fully understand the need for a fallback mechanism to TCP but depending > on what you actually aim for I'm not sure if this is the right wg for it; > therefore my block for now. I hope we can resolve that quickly! This method is already inside the 3GPP TS 24.302 (3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3, section F.3) [1]. This caused some problems to some IPsec vendors, as they need to implement it to support EPC, but the 3gpp specification did not consider or specify all needed things for the protocol, thus vendors needed to agree something that could really be used in interoperable way, and they also thought it would be better to do this work on the IETF, than in the 3GPP. IPsecME WG was considered right group to work on this, as this is mostly defining how this extension interacts with the IKE extensions etc (mobike, ike fragmentation, nat detection etc) [2]. The base 3GPP version did already specify how to put that ESP traffic inside the TCP, i.e. had TCP inside TCP already. What do you think would be better working group for this? [1] http://www.3gpp.org/DynaReport/24302.htm [2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ -- kivinen@iki.fi From nobody Wed Aug 31 05:09:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCB112D1B1 for ; Wed, 31 Aug 2016 05:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 vRizB7YRPjTw for ; Wed, 31 Aug 2016 05:09:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D39112D1AC for ; Wed, 31 Aug 2016 05:09:39 -0700 (PDT) Received: (qmail 23844 invoked from network); 31 Aug 2016 14:02:15 +0200 Received: from p5dec2def.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.239) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 31 Aug 2016 14:02:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <22470.50740.674721.131053@fireball.acr.fi> Date: Wed, 31 Aug 2016 14:02:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:09:43 -0000 Hi Tero, thanks for the reply. Very helpful background info. Maybe even put more = information in the charter text. When you say "the 3gpp specification did not consider or specify all = needed things for the protocol=E2=80=9C, can you be more specific here? I=E2=80=99m not saying that this is the wrong working group but it = really depends on what you want to do. If you already have a clear view = about what needs to be further specified and what the solution is, this = might be the right group. If there is an unknown number of open = questions to be answers, it might not. Mirja > Am 31.08.2016 um 13:57 schrieb Tero Kivinen : >=20 > Mirja Kuehlewind writes: >> Similar to Spencer's commet I have problems understanding what the >> following really means: >>=20 >> "To make IKE work in these environments, IKE packets need to be >> encapsulated in a TCP tunnel. The group will define a mechanism to >> tunnel IKE and IPsec over a TCP-based connection. This method is >> intended to be used as a fallback when IKE cannot be negotiated over >> UDP. The group will create a method where IKEv2 and IPsec packets can >> be encapsulated in the TCP connection." >>=20 >> Based on Tero's mail I understand how the stack looks like but that's = not >> clear from the text because there is not really anything like a TCP >> tunnel. So the big question is, based on the stack indicated by Tero, = do >> you have two full TCP connections running with two congestion control >> loops and retransmission mechanisms on two different endpoints? = That's >> nothing I would recommend.=20 >=20 > Short answer: Yes. There will be TCP inside TCP.=20 >=20 >> I fully understand the need for a fallback mechanism to TCP but = depending >> on what you actually aim for I'm not sure if this is the right wg for = it; >> therefore my block for now. I hope we can resolve that quickly! >=20 > This method is already inside the 3GPP TS 24.302 (3rd Generation > Partnership Project; Technical Specification Group Core Networks and > Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP > access networks; Stage 3, section F.3) [1]. >=20 > This caused some problems to some IPsec vendors, as they need to > implement it to support EPC, but the 3gpp specification did not > consider or specify all needed things for the protocol, thus vendors > needed to agree something that could really be used in interoperable > way, and they also thought it would be better to do this work on the > IETF, than in the 3GPP. >=20 > IPsecME WG was considered right group to work on this, as this is > mostly defining how this extension interacts with the IKE extensions > etc (mobike, ike fragmentation, nat detection etc) [2]. The base 3GPP > version did already specify how to put that ESP traffic inside the > TCP, i.e. had TCP inside TCP already. >=20 > What do you think would be better working group for this? >=20 > [1] http://www.3gpp.org/DynaReport/24302.htm > [2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > --=20 > kivinen@iki.fi >=20 From nobody Wed Aug 31 05:21:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132BF12DB26; Wed, 31 Aug 2016 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 DiiFPNU6Hr5W; Wed, 31 Aug 2016 05:21:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF8D12DB1F; Wed, 31 Aug 2016 05:21:35 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7VCLWwR000183 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Aug 2016 15:21:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7VCLWtO023577; Wed, 31 Aug 2016 15:21:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22470.52172.370022.168002@fireball.acr.fi> Date: Wed, 31 Aug 2016 15:21:32 +0300 From: Tero Kivinen To: "Mirja Kuehlewind \(IETF\)" In-Reply-To: <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 12 min Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:21:38 -0000 Mirja Kuehlewind (IETF) writes: > thanks for the reply. Very helpful background info. Maybe even put > more information in the charter text.=20 I think it belongs to the actual draft, not to the charter, perhaps we should put the draft-ietf-ipsecme-tcp-encaps in the charter, as a working draft.=20 > When you say "the 3gpp specification did not consider or specify all > needed things for the protocol=E2=80=9C, can you be more specific her= e=3F 3GPP just said that we make TCP tunnel, put 16-bit length header in front telling the length of the IKE or ESP packet coming after that, and then we put either ESP packet directly, or 4-bytes of zeros (Non-ESP marker we use in UDP encapsulation) and IKE packet. There is also keepalive timer sending packets over TCP to keep it alive (again similar what we have in UDP). They did not define how it interacts with MOBIKE, and changing of the IP-addresses, or and so on. There are also other newer extensiosns like IKEv2 message fragmentation and those were not considered in the 3gpp specification. To get better answer what was missing, it would be better to ask from the implementors who are implementing these things, my reading was just as an IANA expert, as they needed some IKE notify and configuration payload numbers. > I=E2=80=99m not saying that this is the wrong working group but it re= ally > depends on what you want to do. If you already have a clear view > about what needs to be further specified and what the solution is, > this might be the right group. If there is an unknown number of open > questions to be answers, it might not.=20 I think the current draft mostly already answers to the questions, and I do not think there are that many open issues with it. > > Am 31.08.2016 um 13:57 schrieb Tero Kivinen : > >=20 > > Mirja Kuehlewind writes: > >> Similar to Spencer's commet I have problems understanding what the= > >> following really means: > >>=20 > >> "To make IKE work in these environments, IKE packets need to be > >> encapsulated in a TCP tunnel. The group will define a mechanism to= > >> tunnel IKE and IPsec over a TCP-based connection. This method is > >> intended to be used as a fallback when IKE cannot be negotiated ov= er > >> UDP. The group will create a method where IKEv2 and IPsec packets = can > >> be encapsulated in the TCP connection." > >>=20 > >> Based on Tero's mail I understand how the stack looks like but tha= t's not > >> clear from the text because there is not really anything like a TC= P > >> tunnel. So the big question is, based on the stack indicated by Te= ro, do > >> you have two full TCP connections running with two congestion cont= rol > >> loops and retransmission mechanisms on two different endpoints=3F = That's > >> nothing I would recommend.=20 > >=20 > > Short answer: Yes. There will be TCP inside TCP.=20 > >=20 > >> I fully understand the need for a fallback mechanism to TCP but de= pending > >> on what you actually aim for I'm not sure if this is the right wg = for it; > >> therefore my block for now. I hope we can resolve that quickly! > >=20 > > This method is already inside the 3GPP TS 24.302 (3rd Generation > > Partnership Project; Technical Specification Group Core Networks an= d > > Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GP= P > > access networks; Stage 3, section F.3) [1]. > >=20 > > This caused some problems to some IPsec vendors, as they need to > > implement it to support EPC, but the 3gpp specification did not > > consider or specify all needed things for the protocol, thus vendor= s > > needed to agree something that could really be used in interoperabl= e > > way, and they also thought it would be better to do this work on th= e > > IETF, than in the 3GPP. > >=20 > > IPsecME WG was considered right group to work on this, as this is > > mostly defining how this extension interacts with the IKE extension= s > > etc (mobike, ike fragmentation, nat detection etc) [2]. The base 3G= PP > > version did already specify how to put that ESP traffic inside the > > TCP, i.e. had TCP inside TCP already. > >=20 > > What do you think would be better working group for this=3F > >=20 > > [1] http://www.3gpp.org/DynaReport/24302.htm > > [2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/= > > --=20 > > kivinen@iki.fi > >=20 >=20 --=20 kivinen@iki.fi From nobody Wed Aug 31 05:54:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AA712DB63; Wed, 31 Aug 2016 05:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 kNG9nIM1vCOx; Wed, 31 Aug 2016 05:54:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E928712DB62; Wed, 31 Aug 2016 05:54:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sPQLZ1sJpz7WB; Wed, 31 Aug 2016 14:53:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472648038; bh=CvFljRrWtADbifDK91C8NTKNlbO6GGoHdeBpT2/Pp2g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=F04HyogjrrQ/asnVIaDNgoZap0adOvWcNHi9yVZwXjUAa0XI6mFfA8jL734pcpmMl 1+eO07c/H/OSt0jPz6JFSgqyLCy3+9zHbNMjF+mJsfjtzIZ1KOSSSRZ5b6bAAjXpKv p80owAYjLuVwnO8HN325aRUQxhxRMF3mH0iInZR4= 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 ELlIXffVoee9; Wed, 31 Aug 2016 14:53:57 +0200 (CEST) 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; Wed, 31 Aug 2016 14:53:57 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 51BAE19C32C; Wed, 31 Aug 2016 08:53:56 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 51BAE19C32C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 39A8640D6FEB; Wed, 31 Aug 2016 08:53:56 -0400 (EDT) Date: Wed, 31 Aug 2016 08:53:56 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22470.50740.674721.131053@fireball.acr.fi> Message-ID: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, Mirja Kuehlewind , The IESG Subject: Re: [IPsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_Block_on_charter-ie?= =?iso-8859-15?q?tf-ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:54:03 -0000 On Wed, 31 Aug 2016, Tero Kivinen wrote: >> Based on Tero's mail I understand how the stack looks like but that's not >> clear from the text because there is not really anything like a TCP >> tunnel. So the big question is, based on the stack indicated by Tero, do >> you have two full TCP connections running with two congestion control >> loops and retransmission mechanisms on two different endpoints? That's >> nothing I would recommend. > > Short answer: Yes. There will be TCP inside TCP. Well, no. This is adding confusion. There will be an IPsec tunnel inside TCP, and the IPsec tunnel could be used to transport TCP or anything else. The ipsecme working group is not adding a TCP over TCP method. Paul From nobody Wed Aug 31 06:17:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB94712D528; Wed, 31 Aug 2016 06:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hRC2Wv-MYkjM; Wed, 31 Aug 2016 06:17:35 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C161912D4FB; Wed, 31 Aug 2016 06:17:34 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id w2so30763276wmd.0; Wed, 31 Aug 2016 06:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t06z2esbXtVKtytcfcmgoKe+clTnw19cJuh3xsRdiGg=; b=LIrI9GTgBcFJsM/T69R4tnErAZ3zGVGhdRznfkwhKatKJC4Eac5sZT0ZuOnTuFmqfT KxYlrIdAyOO/zt/AR+sUgsP+HZ4GEGH4RG5ZURL7RtOrcZUmYmFxGWdBMdEhWVhOpQFy JPGY9MZkDxDHC7qnbp/l4tmDLF8CmhUniGOiNMIWX2U5OuNzTQW3shN8bzHrbk1Cpy3Y QuP4KQezcKSPgt5nzd3UWPqA1zqPe+mIUIW9aupXaAx4aMQ0/OYk7/hFOSLCpl1Dk2nl 7MsOhqzNqnNnWaw22tafONv5dibtsUjOy5mk7STJuPhAc0TGpzOptbn831y1oQFY/EkR mbMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t06z2esbXtVKtytcfcmgoKe+clTnw19cJuh3xsRdiGg=; b=COYOdeYTFc/LggwxgEvo/3Mmp2tD7PvkAXNWv8RQYpfV0uVV0WwhU4tj9SDQUwraBE qda5XGQcjdWfdl86mAHgYLKMndCb04SZH3A8zB4tSAdh43bJaR9C19s2X+6WBmsYRQMG kvx/3MWU2r4kGyfTWqg0NUl88DboVF3iV19WNqT0ZEd039qVlE3JpPa6LHW/8Jy3e2UD lP9o6vNXcBxEpwQjDpibdfDcIYAuBz5UhFfF4u69A2+a1Sp/EAvIk85FJtctsbAHEkg/ EK2NViiIAj7rhbs6vsVmg+7a/EYzzlrs6w75EocEllyPYN3o0bZqRtPzTGnWnnYgmDyB 3Qnw== X-Gm-Message-State: AE9vXwNg/h7afEoJW2xdWWvGTkzaG1msAnT7LpNauKd7BZJZxJv6Hnpu6yGVAFwYPzau4w== X-Received: by 10.194.95.105 with SMTP id dj9mr9700824wjb.20.1472649453244; Wed, 31 Aug 2016 06:17:33 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id hy3sm44492999wjb.8.2016.08.31.06.17.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 06:17:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <22470.52172.370022.168002@fireball.acr.fi> Date: Wed, 31 Aug 2016 16:17:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, "Mirja Kuehlewind \(IETF\)" , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 13:17:38 -0000 > On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >=20 > Mirja Kuehlewind (IETF) writes: >> thanks for the reply. Very helpful background info. Maybe even put >> more information in the charter text.=20 >=20 > I think it belongs to the actual draft, not to the charter, perhaps we > should put the draft-ietf-ipsecme-tcp-encaps in the charter, as > a working draft.=20 >=20 >> When you say "the 3gpp specification did not consider or specify all >> needed things for the protocol=E2=80=9C, can you be more specific = here? >=20 > 3GPP just said that we make TCP tunnel, put 16-bit length header in > front telling the length of the IKE or ESP packet coming after that, > and then we put either ESP packet directly, or 4-bytes of zeros > (Non-ESP marker we use in UDP encapsulation) and IKE packet. >=20 > There is also keepalive timer sending packets over TCP to keep it > alive (again similar what we have in UDP). One more bit of information: some vendors have had a non-standardized = version of this or something similar for years. My employer has had it = since 2003, except that the header is a bit different. The pretty = ubiquitous SSL VPNs do pretty much the same except that they encrypt IP = packets plus headers into TLS records rather than ESP packets before = streaming them over TCP. Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the = TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D Yoav= From nobody Wed Aug 31 06:59:22 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A712D50E for ; Wed, 31 Aug 2016 06:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 Grp_aSu7zxAG for ; Wed, 31 Aug 2016 06:59:15 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0189112D50C for ; Wed, 31 Aug 2016 06:48:31 -0700 (PDT) Received: (qmail 31761 invoked from network); 31 Aug 2016 15:41:47 +0200 Received: from p5dec2def.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.239) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 31 Aug 2016 15:41:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> Date: Wed, 31 Aug 2016 15:41:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> To: Yoav Nir , Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 13:59:20 -0000 Hi all, thanks for providing the reference to the draft. That was very helpful = and confirmed my initial assumption that you don=E2=80=99t want to = =E2=80=9Achange=E2=80=98 TCP. So this work seems to be fine in this = group, however, the wording in the charter is very misleading. What's = about the following? "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE packets need to be encapsulated in ESP over TCP. Therefore the group will define a = mechanism to use IKE and IPsec over TCP. Further the group will provide guidance=20 how to detect when IKE cannot be negotiated over UDP and TCP as a = fallback should be used.=E2=80=9C I also removed some redundancy and added a point that guidance is needed = to detect blocking. We could still at the current draft as a starting = point=E2=80=A6 Mirja > Am 31.08.2016 um 15:17 schrieb Yoav Nir : >=20 >=20 >> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>=20 >> Mirja Kuehlewind (IETF) writes: >>> thanks for the reply. Very helpful background info. Maybe even put >>> more information in the charter text.=20 >>=20 >> I think it belongs to the actual draft, not to the charter, perhaps = we >> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >> a working draft.=20 >>=20 >>> When you say "the 3gpp specification did not consider or specify all >>> needed things for the protocol=E2=80=9C, can you be more specific = here? >>=20 >> 3GPP just said that we make TCP tunnel, put 16-bit length header in >> front telling the length of the IKE or ESP packet coming after that, >> and then we put either ESP packet directly, or 4-bytes of zeros >> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>=20 >> There is also keepalive timer sending packets over TCP to keep it >> alive (again similar what we have in UDP). >=20 > One more bit of information: some vendors have had a non-standardized = version of this or something similar for years. My employer has had it = since 2003, except that the header is a bit different. The pretty = ubiquitous SSL VPNs do pretty much the same except that they encrypt IP = packets plus headers into TLS records rather than ESP packets before = streaming them over TCP. >=20 > Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the = TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >=20 > Yoav From nobody Wed Aug 31 07:20:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08E212DD0F for ; Wed, 31 Aug 2016 07:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 nBiUpizzGRZs for ; Wed, 31 Aug 2016 07:20:11 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C95412D596 for ; Wed, 31 Aug 2016 06:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1472651843; x=2336565443; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ex6W1MVPK+NsoiPmmpJJOis/c+Y4ABY+d4LE52oK888=; b=rVbJutl83BWlnaPiI6FoX5qYpoOugwC9lsb+9io3YNAhjqiApQW4gdsCowGApsBb +7FuQ8JmETRrvffyi6Xstp4RSFHXtPp5cqqnYlY6uxf/ajlAqm+dFqHXdXjWJY/b 9SDPKeL/XV0poRacIkTANIETlFnYa7121mRTT7d8M+wZc0Zq+A1PeYSqjtM5qSOb fh3sSyCf2a2OxHTQ+gHh+E5qkPrR5l8L6EoUsvbNEV7eZYFMLYvM/XmpaIdSXKEC 7voJum4afJ+8PLjIMUlDHW7g7WQhOaSTcnglU7UfxSQafhgp/k8+n6ODMWHZiGOu NaueaF209dttOTCUoC8lOA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id C2.8B.07273.342E6C75; Wed, 31 Aug 2016 06:57:23 -0700 (PDT) X-AuditID: 11973e13-f794a6d000001c69-f5-57c6e243f173 Received: from nwk-mmpp-sz08.apple.com (nwk-mmpp-sz08.apple.com [17.128.115.25]) by relay3.apple.com (Apple SCV relay) with SMTP id 78.A6.18578.342E6C75; Wed, 31 Aug 2016 06:57:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.17.250] (unknown [17.153.17.250]) by nwk-mmpp-sz08.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OCS00H9L1FLMR30@nwk-mmpp-sz08.apple.com>; Wed, 31 Aug 2016 06:57:22 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <22470.45104.891974.85938@fireball.acr.fi> Date: Wed, 31 Aug 2016 06:57:21 -0700 Message-id: <194A9F3E-0AB0-4C61-AC21-86570ABB217E@apple.com> References: <147252008248.19114.6268958851439201313.idtracker@ietfa.amsl.com> <22470.45104.891974.85938@fireball.acr.fi> To: Tero Kivinen , Kathleen Moriarty , Spencer Dawkins X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUi2FAYrOv86Fi4waedfBYz/kxktti/5QWb xcw5H1gspq58zW7RsDPf4uj552wW729dYrJYNmUPswOHx85Zd9k9liz5yeRx+OtCFo/v85g8 vlz+zBbAGsVlk5Kak1mWWqRvl8CV8e34GuaChcoVd9unsjQwrpTuYuTkkBAwkfi0dR8jhC0m ceHeerYuRi4OIYG9jBJT2h8wwRT1H/4GlTjIKHFv+xKwBK+AoMSPyfdYuhg5OJgF5CUOnpcF CTMLaEl8f9TKAlHfxSTx5eV0VpAaYQEJic17EkFqhAWSJL53PAUbwyagInH82wZmEJtTwFzi RNcWZpByFgFViQWba0DGMAvsY5TY+vIg2CpeARuJ179tQcqFBL4zSmy/KgxSIyLQwyix5vhv FoibZSUWHb/CCpKQEPjNJvF13nO2CYwis5CcPQvh7FlIzl7AyLyKUSg3MTNHNzPPVC+xoCAn VS85P3cTIyiOptsJ72A8vcrqEKMAB6MSD++BWUfDhVgTy4orcw8xSnOwKInzzjI8Fi4kkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBUdCu7cc57lIGyb+yT09dNTPOucOgnnyo1SfS6+dqqaeh lv92/zw7Z6GshgNT+2n7rMeS7PtnbNob8F639m72K/HlhwVT7n/8t4Az44Ss4ba3S6QkKlbE 9C1j6pixcfOSSl+2xv+zGp9pbCv3SGu9XRmsfPVDXDpvgH7EfMs1xw4nXg/cdzo5RYmlOCPR UIu5qDgRADSk26+EAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUi2FAsqev86Fi4wYPP7BYz/kxktti/5QWb xcw5H1gspq58zW7RsDPf4uj552wW729dYrJYNmUPswOHx85Zd9k9liz5yeRx+OtCFo/v85g8 vlz+zBbAGsVlk5Kak1mWWqRvl8CV8e34GuaChcoVd9unsjQwrpTuYuTkkBAwkeg//I0NwhaT uHBvPZDNxSEkcJBR4t72JUwgCV4BQYkfk++xdDFycDALyEscPC8LEmYW0JL4/qiVBaK+i0ni y8vprCA1wgISEpv3JILUCAskSXzveAo2hk1AReL4tw3MIDangLnEia4tzCDlLAKqEgs214CM YRbYxyix9eVBsFW8AjYSr3/bgpQLCXxnlNh+VRikRkSgh1FizfHfLBA3y0osOn6FdQKj4Cwk l85CuHQWkksXMDKvYhQoSs1JrDTWSywoyEnVS87P3cQIDvvC4B2Mf5ZZHWIU4GBU4uE9MOto uBBrYllxZe4hRgkOZiUR3ul3j4UL8aYkVlalFuXHF5XmpBYfYkwGun8is5Rocj4wJvNK4g1N TAxMjI3NjI3NTcxJE1YS5918BGirQHpiSWp2ampBahHMFiYOTqkGxryZMde02MOFGm+k5uxu KGkPMNyVLhaw/nLgR4ni/7uzhdfGG351ODvl8+uPCi/F1F/6ZvH7fu2obKriWn9TZ6bm9Llh 5ZJGnv4rD7kyuzB9z+a8mH7HS5JL7mpva7jP7F//tWSZ75ZcUBCffz2r6ru0nvyh9Q/Y9OYK +yR+m5T6d36nA89PJZbijERDLeai4kQArwoBor8CAAA= Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, Paul Wouters , The IESG Subject: Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:20:14 -0000 > On Aug 31, 2016, at 3:23 AM, Tero Kivinen wrote: > > Kathleen Moriarty writes: >>>> "There have been middle boxes blocking IKE negotiation over UDP. To >>>> make IKE work in these environments, IKE packets need to be >>>> encapsulated in a TCP tunnel. >>> >>> >>> "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec >>> tunnel was not meant. Instead, we meant "encapsulated in TCP". >> >> OK, I am changing this text too, thanks. >>> >>>> The group will define a mechanism to >>>> tunnel IKE and IPsec over a TCP-based connection. This method is >>>> intended to be used as a fallback when IKE cannot be negotiated over >>>> UDP. The group will create a method where IKEv2 and IPsec packets can >>>> be encapsulated in the TCP connection." >>> >>> >>> >>>> going for external review, but I'd love to understand better what the >>>> resulting protocol stack looks like. I get the part about encapsulating >>>> IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a >>>> general-purpose "IP over TCP" mechanism? In effect, yes: we prefer that IKE/IPSec tunnels are run over UDP for various reasons (performance, etc), but having a fallback over TCP allows it to be a generic tunneling mechanism over TCP, such that implementations can use this as a standardized VPN that works on UDP or TCP, and not need a proprietary protocol. >>> >>> >>> It will be "ESP over TCP" similar to how we now have "ESP over UDP". >> >> We should be more explicit here, I agree with Spencer. The IKE part >> is clear since that's UPD 500. Would this be transport mode ESP only? >> If that's the case, how is the following alteration to the text: >> >> The group will define a mechanism to >> tunnel IKE and IPsec over a TCP-based connection. This method is >> intended to be used as a fallback when IKE cannot be negotiated over >> UDP. The group will create a method where IKEv2 and IPsec ESP >> transport mode packets can >> be encapsulated in the TCP connection." >> >> Working group: If I've changed the intent too much, please suggest >> other wording. > > The traffic inside the TCP-based connection is usually ESP tunnel > mode, not transport mode, so the change you made is limiting it too > much. > > I.e., this is intended for mobile phones / laptops etc doing VPN > connection from the hotel to the enterprice vpn gateway and where the > hotel etc firewall blocks all UDP traffic. So when UDP does not work > we make TCP connection and encapsulate all IKE and ESP packets to that > TCP connection. On those cases the VPN gateway usually assigns > internal IP-address to the mobile device using configuration payloads > in IKE, and then the mobile device uses tunnel mode ESP to send data > to the internal enterprice network. > > So at least remove the "transport mode" and then it should be ok. Right. If we would specific any mode specifically, it should specify tunnel mode, not transport mode. The proposed change to the text is fine apart from the specification of the mode! Thanks, Tommy > > The protocol stack will look like this: > > Data packet: IKEv2 packet > > Application data > TCP header IKEv2 packet > Inner IP-header IKEv2 header > ESP Non-ESP Marker > Length Length > TCP header TCP header > Outer IP-header Outer IP-header > > (Of course as this runs over normal TCP connection, the Length ESP + > Inner IP-header + TCP header + Application data might get splitted to > multiple actual packets, or there might be multiple inner packets > inside the same TCP packet). > > This is similar than what we already have when doing UDP encapsulation > of IPsec (RFC3948): > > 3.4. Tunnel Mode ESP Encapsulation > ... > AFTER APPLYING ESP/UDP > -------------------------------------------------------------- > IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP| > |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth| > -------------------------------------------------------------- > |<------------ encrypted ----------->| > |<------------- authenticated ------------>| > > but instead of "UDP Hdr" we have TCP connection. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Aug 31 07:29:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B883812DC10 for ; Wed, 31 Aug 2016 07:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 BDVeF8MbeskO for ; Wed, 31 Aug 2016 07:29:51 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82CD12DC1C for ; Wed, 31 Aug 2016 07:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1472652619; x=2336566219; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t6xCvj7tuvN9Z56vTnIBeQjM3Xsoy63VFuYfgsBCsMY=; b=PWLZdh7nUCcPlX+2QDEWeLt8xorWYNmlLIzGH3nkfWq/2h1+Giyj/q9khfIEQyyJ 5o88n8By+jXFEMMJhPkyhm5JklkjDW1p1+vLV80gkmh0gnjUe2QFbcYG3NA2i56d PIRuAGOvBpFjAXntwcYD28Z5bWxo9XXqEGdlAnJB5g8wnb51Y8IjTPxtZMUxCMS5 H0n8Z8KDrqXwB/0b+yfoJA5SvQPIGSstXig711LA4QOtnR3w+bK74UVh0N6DCBTY ef0GMZbIvtrh1YtnfCMy2HmDZ5rUrVuq3eDZErCKiOZeFtyXM58EKQSObZyRBSgk 1E2ZXRyL5Aa1E5SLnrvHgA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 38.86.10360.B45E6C75; Wed, 31 Aug 2016 07:10:19 -0700 (PDT) X-AuditID: 11973e11-f79e76d000002878-31-57c6e54b1191 Received: from nwk-mmpp-sz08.apple.com (nwk-mmpp-sz08.apple.com [17.128.115.25]) by relay3.apple.com (Apple SCV relay) with SMTP id F7.F8.18578.B45E6C75; Wed, 31 Aug 2016 07:10:19 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.17.250] (unknown [17.153.17.250]) by nwk-mmpp-sz08.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OCS00HWV216MR30@nwk-mmpp-sz08.apple.com>; Wed, 31 Aug 2016 07:10:19 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> Date: Wed, 31 Aug 2016 07:10:18 -0700 Content-transfer-encoding: quoted-printable Message-id: <24F712D4-BC9B-4BAF-A7D7-78F6D180BED1@apple.com> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUi2FAYrOv99Fi4wapmSYsZfyYyW7y4/pHZ Yv+WF2wWM+d8YLGYuvI1u8XR88/ZLJYe+8DkwO6xc9Zddo8lS34yeRz+upDFo+XjQlaPL5c/ swWwRnHZpKTmZJalFunbJXBlTJr4gKXgj1TF457jLA2M70S7GDk5JARMJM43zGOFsMUkLtxb z9bFyMUhJLCXUWLJ9f3MMEWXft1hhkgcZJQ4fvg8C0iCV0BQ4sfke0A2BwezgLrElCm5EDVd TBKbD7xgB4kLC0hIbN6TCBIXFmhjlPg7fTo7SC+bgIrE8W8bwBZwCthK/Jq2GCzOIqAqMf37 ZyYQm1lgC6PEi8umELa2xJN3F1gh9tpIzGnpgDpoMpPEmcddbCAJEQFjicOTv0O9Iyux6PgV VpAiCYHPbBIHvjYwTmAUmYXk8FkIh89CsmMBI/MqRqHcxMwc3cw8I73EgoKcVL3k/NxNjKAo mm4nuIPx+CqrQ4wCHIxKPLwZM46GC7EmlhVX5h5ilOZgURLnnWV4LFxIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDo5d5QNDZVX59Iiek76vPunLqwOz55u1lanxF6z1bljz46XN/kfN1I7uT 6fobNh/4UvC19O78xzdYHn1mKSo/ycK8rU3s3anjh3XvsrI/n/b85Du1ol+M1S+4i5iUTBwd JrrXLPyqbh8fxdXw/PDKif9Fv8l5zPx3Szvp0DuTY5tmLnaaZXbgpoESS3FGoqEWc1FxIgBj eG23gwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUi2FAsqev99Fi4weeTIhYz/kxktnhx/SOz xf4tL9gsZs75wGIxdeVrdouj55+zWSw99oHJgd1j56y77B5Llvxk8jj8dSGLR8vHhaweXy5/ ZgtgjeKySUnNySxLLdK3S+DKmDTxAUvBH6mKxz3HWRoY34l2MXJySAiYSFz6dYcZwhaTuHBv PVsXIxeHkMBBRonjh8+zgCR4BQQlfky+B2RzcDALqEtMmZILUdPFJLH5wAt2kLiwgITE5j2J IHFhgTZGib/Tp7OD9LIJqEgc/7YBbAGngK3Er2mLweIsAqoS079/ZgKxmQW2MEq8uGwKYWtL PHl3gRVir43EnJYOZohlk5kkzjzuYgNJiAgYSxye/J0V4mpZiUXHr7BOYBScheTWWQi3zkIy dgEj8ypGgaLUnMRKY73EgoKcVL3k/NxNjOCgLwzewfhnmdUhRgEORiUe3gOzjoYLsSaWFVfm HmKU4GBWEuH1eHQsXIg3JbGyKrUoP76oNCe1+BBjMtAzE5mlRJPzgRGZVxJvaGJiYGJsbGZs bG5iTpqwkjjv5iNAWwXSE0tSs1NTC1KLYLYwcXBKNTAW9UQZhpVsLvVVOdcvtr21IFmxQEP1 BFeo1hXdFdrdt1dELZtlIr329uqupMPHnrjs6mRbs9XcM49L4eqhrzcFuefEvb+45vo3x4fy ZZWn2ffJOxUv88nSX3jixufp7ZeNVhcIRPTaJb1uufUngy/9xYGqmxlde27edxBu5vhSqzRF v9phprYSS3FGoqEWc1FxIgD5KW5kvgIAAA== Archived-At: Cc: ipsecme-chairs@ietf.org, Yoav Nir , ipsecme-chairs@tools.ietf.org, Tero Kivinen , IPsecME WG , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:29:55 -0000 Thanks everyone for chiming in. I want to highlight that the point of = the draft is to nail down the IKE-specific concerns of encapsulating the = tunnel in streams. As mentioned by Tero, this includes how to specify = the boundaries of messages within the stream; and how to interact with = MOBIKE, redirection, fragmentation, and so on. The protocol really could be summarized as "how to encapsulate IKE and = IPSec in any stream-like protocol", and it specifically mentions that = this applies beyond direct TCP streams. If we want to have work in other = groups to change how the outer TCP works, that's great. Any work that = would be done in that area could benefit such tunnels without requiring = changes to the IPSec aspect. The practice of putting tunnels over TCP when absolutely necessitated by = the restrictions of a network is common practice. If we do not specify = this here, devices will still do it, just without a standard. As Yoav = mentioned, this is common practice across essentially every non-IKE VPN = tunnel protocol, and leads to a splintering of protocols to do the same = thing. Please do read the draft (current version = https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02); it = specifically calls out why TCP-in-TCP (which can happen in this = scenario) is problematic, and so it specifies several times that this is = only to be used as a fallback from UDP. We've done fairly extensive testing around the implications of this = protocol, and made sure we were satisfied with the results before we = proposed the draft.=20 Thanks, Tommy > On Aug 31, 2016, at 6:17 AM, Yoav Nir wrote: >=20 >=20 >> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>=20 >> Mirja Kuehlewind (IETF) writes: >>> thanks for the reply. Very helpful background info. Maybe even put >>> more information in the charter text.=20 >>=20 >> I think it belongs to the actual draft, not to the charter, perhaps = we >> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >> a working draft.=20 >>=20 >>> When you say "the 3gpp specification did not consider or specify all >>> needed things for the protocol=E2=80=9C, can you be more specific = here? >>=20 >> 3GPP just said that we make TCP tunnel, put 16-bit length header in >> front telling the length of the IKE or ESP packet coming after that, >> and then we put either ESP packet directly, or 4-bytes of zeros >> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>=20 >> There is also keepalive timer sending packets over TCP to keep it >> alive (again similar what we have in UDP). >=20 > One more bit of information: some vendors have had a non-standardized = version of this or something similar for years. My employer has had it = since 2003, except that the header is a bit different. The pretty = ubiquitous SSL VPNs do pretty much the same except that they encrypt IP = packets plus headers into TLS records rather than ESP packets before = streaming them over TCP. >=20 > Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the = TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >=20 > Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Aug 31 07:31:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91F12D563; Wed, 31 Aug 2016 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no 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 zP9EZs7tSpJc; Wed, 31 Aug 2016 07:31:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DDD12D630; Wed, 31 Aug 2016 07:11:34 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u7VEBUfg022271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Aug 2016 17:11:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u7VEBU01007820; Wed, 31 Aug 2016 17:11:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22470.58770.462917.441477@fireball.acr.fi> Date: Wed, 31 Aug 2016 17:11:30 +0300 From: Tero Kivinen To: "Mirja Kuehlewind \(IETF\)" In-Reply-To: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Cc: IPsecME WG , ipsecme-chairs@ietf.org, The IESG , Yoav Nir Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:31:06 -0000 Mirja Kuehlewind (IETF) writes: > thanks for providing the reference to the draft. That was very > helpful and confirmed my initial assumption that you don=E2=80=99t wa= nt to > =E2=80=9Achange=E2=80=98 TCP. So this work seems to be fine in this g= roup, however, > the wording in the charter is very misleading. What's about the > following=3F Yes, we do NOT want to make any changes to the TCP, not the TCP outside or the TCP inside (or UDP, ICMP whatever inside, the inside traffic can of course be something else than TCP, but usually there will be TCP also).=20 > "There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE packets need to be > encapsulated in ESP over TCP. Therefore the group will define a > mechanism to use IKE and IPsec over TCP. Further the group will > provide guidance how to detect when IKE cannot be negotiated over > UDP and TCP as a fallback should be used.=E2=80=9C That is bit misleading, as IKE packets are not encpasulated in the ESP, instead both IKE and ESP packets are encapsulated in (very simple) encapsulation protocol that is running over TCP. I.e., the very= simple encapsulation protocol consists just the 2-octet length prefixing the packet, and nothing else. So more accurate text would be: There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. Further the group will provide guidance how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used. > I also removed some redundancy and added a point that guidance is > needed to detect blocking. We could still at the current draft as a > starting point...=20 --=20 kivinen@iki.fi From nobody Wed Aug 31 07:41:35 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86EB12DCD3; Wed, 31 Aug 2016 07:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 b9xo4W7WyAIV; Wed, 31 Aug 2016 07:41:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42D412DCE4; Wed, 31 Aug 2016 07:17:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sPSBR1pvvzJ7j; Wed, 31 Aug 2016 16:17:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1472653023; bh=bWLXxZ1uPgXUvTzhjoZOgwiEN08EnwP3T2GF6+nIRB4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cuxS0MEZ5hkDVVqwcNCDYRwHBA+C4DUvIKnHhkMPp5nweblemRvGV+Q06mwIKVPhw RF0oLUZWroV3/NL5/16elagRis/mflUUAMlhyflVuTSgIgAdFftXr0RjeZECp5fAH3 YlVIw1nMFlgsPdtfCCdrKqg43LhlgTk1W5NtIE3c= 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 Gp7QWzi64MTC; Wed, 31 Aug 2016 16:17:01 +0200 (CEST) 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; Wed, 31 Aug 2016 16:17:01 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0E71019C32E; Wed, 31 Aug 2016 10:16:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0E71019C32E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EF2BE40D6FEB; Wed, 31 Aug 2016 10:16:59 -0400 (EDT) Date: Wed, 31 Aug 2016 10:16:59 -0400 (EDT) From: Paul Wouters To: "Mirja Kuehlewind (IETF)" In-Reply-To: Message-ID: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: ipsecme-chairs@ietf.org, ipsecme-chairs@tools.ietf.org, Tero Kivinen , IPsecME WG , Yoav Nir , The IESG Subject: Re: [IPsec] =?iso-8859-15?q?Mirja_K=FChlewind=27s_Block_on_charter-ie?= =?iso-8859-15?q?tf-ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:41:34 -0000 On Wed, 31 Aug 2016, Mirja Kuehlewind (IETF) wrote: > thanks for providing the reference to the draft. That was very helpful and confirmed my initial assumption that you don’t want to ‚change‘ TCP. So this work seems to be fine in this group, however, the wording in the charter is very misleading. What's about the following? > > "There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE packets need to be > encapsulated in ESP over TCP. Therefore the group will define a mechanism to > use IKE and IPsec over TCP. Further the group will provide guidance > how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used.“ "IKE packets need to be encapsulated in ESP over TCP" is not correct. Both IKE and ESP are "independently" encapsulated over TCP. First the IKE negotiation happens, normally over UDP port 500 or when NAT is involves over UDP port 4500. We are now introducing a method to encapsulate this over TCP. Once the IKE session is up, we have negotiated an ESP method, which we will _also_ need to encapsulate over the same TCP stream. As with ESP over UDP, we place markers in the stream to distinguish IKE from ESP packets within the TCP stream. Paul From nobody Wed Aug 31 07:49:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764BB12D550 for ; Wed, 31 Aug 2016 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 K2iFbxpu_z7j for ; Wed, 31 Aug 2016 07:49:09 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95DC12D662 for ; Wed, 31 Aug 2016 07:24:16 -0700 (PDT) Received: (qmail 1654 invoked from network); 31 Aug 2016 16:24:14 +0200 Received: from p5dec2def.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.239) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 31 Aug 2016 16:24:14 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <22470.58770.462917.441477@fireball.acr.fi> Date: Wed, 31 Aug 2016 16:24:13 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> <22470.58770.462917.441477@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , ipsecme-chairs@ietf.org, The IESG , Yoav Nir Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:49:13 -0000 Hi all, > Am 31.08.2016 um 16:11 schrieb Tero Kivinen : > > There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE and ESP packets need to be > transmitted over TCP. Therefore the group will define a mechanism to > use IKE and IPsec over TCP. Further the group will provide guidance > how to detect when IKE cannot be negotiated over UDP and TCP as a > fallback should be used. This text is fine. Sorry I was missing a previous comment. Mirja From nobody Wed Aug 31 07:52:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3703312DA7A for ; Wed, 31 Aug 2016 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 NHx03C2Fa3cZ for ; Wed, 31 Aug 2016 07:52:02 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE8A12DBBE for ; Wed, 31 Aug 2016 07:28:04 -0700 (PDT) Received: (qmail 2007 invoked from network); 31 Aug 2016 16:28:02 +0200 Received: from p5dec2def.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.239) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 31 Aug 2016 16:28:02 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <24F712D4-BC9B-4BAF-A7D7-78F6D180BED1@apple.com> Date: Wed, 31 Aug 2016 16:28:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> <24F712D4-BC9B-4BAF-A7D7-78F6D180BED1@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsecme-chairs@ietf.org, Yoav Nir , ipsecme-chairs@tools.ietf.org, Tero Kivinen , IPsecME WG , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:52:13 -0000 Hi Tommy, thanks for the info. I understand the need for using TCP and also the = need for standardization here. It was just not clear to me what exactly = need to be done because I didn=E2=80=99t have the reference to the = draft. You as you said below what you need is guidance on "how to encapsulate = IKE and IPSec in a stream-like protocol=E2=80=9C. Maybe that the wording = we could also use in the charter to clarify what the wg will do=E2=80=A6? Mirja > Am 31.08.2016 um 16:10 schrieb Tommy Pauly : >=20 > Thanks everyone for chiming in. I want to highlight that the point of = the draft is to nail down the IKE-specific concerns of encapsulating the = tunnel in streams. As mentioned by Tero, this includes how to specify = the boundaries of messages within the stream; and how to interact with = MOBIKE, redirection, fragmentation, and so on. >=20 > The protocol really could be summarized as "how to encapsulate IKE and = IPSec in any stream-like protocol", and it specifically mentions that = this applies beyond direct TCP streams. If we want to have work in other = groups to change how the outer TCP works, that's great. Any work that = would be done in that area could benefit such tunnels without requiring = changes to the IPSec aspect. >=20 > The practice of putting tunnels over TCP when absolutely necessitated = by the restrictions of a network is common practice. If we do not = specify this here, devices will still do it, just without a standard. As = Yoav mentioned, this is common practice across essentially every non-IKE = VPN tunnel protocol, and leads to a splintering of protocols to do the = same thing. Please do read the draft (current version = https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02); it = specifically calls out why TCP-in-TCP (which can happen in this = scenario) is problematic, and so it specifies several times that this is = only to be used as a fallback from UDP. >=20 > We've done fairly extensive testing around the implications of this = protocol, and made sure we were satisfied with the results before we = proposed the draft.=20 >=20 > Thanks, > Tommy >=20 >> On Aug 31, 2016, at 6:17 AM, Yoav Nir wrote: >>=20 >>=20 >>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>>=20 >>> Mirja Kuehlewind (IETF) writes: >>>> thanks for the reply. Very helpful background info. Maybe even put >>>> more information in the charter text.=20 >>>=20 >>> I think it belongs to the actual draft, not to the charter, perhaps = we >>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >>> a working draft.=20 >>>=20 >>>> When you say "the 3gpp specification did not consider or specify = all >>>> needed things for the protocol=E2=80=9C, can you be more specific = here? >>>=20 >>> 3GPP just said that we make TCP tunnel, put 16-bit length header in >>> front telling the length of the IKE or ESP packet coming after that, >>> and then we put either ESP packet directly, or 4-bytes of zeros >>> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>>=20 >>> There is also keepalive timer sending packets over TCP to keep it >>> alive (again similar what we have in UDP). >>=20 >> One more bit of information: some vendors have had a non-standardized = version of this or something similar for years. My employer has had it = since 2003, except that the header is a bit different. The pretty = ubiquitous SSL VPNs do pretty much the same except that they encrypt IP = packets plus headers into TLS records rather than ESP packets before = streaming them over TCP. >>=20 >> Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the = TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >>=20 >> Yoav >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Wed Aug 31 07:56:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1154E12DC4F for ; Wed, 31 Aug 2016 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 Dkg9CYAO11m4 for ; Wed, 31 Aug 2016 07:56:08 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D826E12D5D7 for ; Wed, 31 Aug 2016 07:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1472653843; x=2336567443; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pWR498tMB1P8VkLS7uPKOPq9wB596k5UgmMfaKQtt+8=; b=k+7TibvYtiv39JPK9lRzY7eUoHmJVqfPMEoge2W2yjziHfG1MIdRKXmJuZoC9D0X bSPEM9Wnf+/xbc4AQlRrLp4Ex7xd8pR1uUIz69IdOBjcjVuGFW+0JsJxMMDX5+nP S20YUuwJUuVipwEQPoc7d2Ko/YWpjMYul6oDlNSf8OPMAXzp4ldBhGWH+9cuVwQI XaK+NxBH/IolyrKiaZzvPO3jgy1xUZB0VMltdceg/GYnHa2MpkZRfLUtSOdN56ZX d1r+904FC9m2Vpg//1c53d2EHlVM7rmwxA7e9S1eNeg644Kzmf+iBXmZiIa7yTDe KFNmCy/gIlvdUjzv/fFWAg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 4D.5A.10360.31AE6C75; Wed, 31 Aug 2016 07:30:43 -0700 (PDT) X-AuditID: 11973e11-f79e76d000002878-f0-57c6ea132c05 Received: from nwk-mmpp-sz08.apple.com (nwk-mmpp-sz08.apple.com [17.128.115.25]) by relay3.apple.com (Apple SCV relay) with SMTP id 85.FC.18578.21AE6C75; Wed, 31 Aug 2016 07:30:43 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.17.250] (unknown [17.153.17.250]) by nwk-mmpp-sz08.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OCS00HWJ2Z6MR40@nwk-mmpp-sz08.apple.com>; Wed, 31 Aug 2016 07:30:42 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Wed, 31 Aug 2016 07:30:42 -0700 Content-transfer-encoding: quoted-printable Message-id: <2FE3792A-D7D0-43F9-ACC4-0DCB69AB038E@apple.com> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUi2FAYrCv86li4wYdJghYz/kxktnhx/SOz xf4tL9gsZs75wGIxdeVrdouj55+zWSw99oHJgd1j56y77B5Llvxk8jj8dSGLR8vHhaweXy5/ ZgtgjeKySUnNySxLLdK3S+DKOP3PuqBbvmLR6u/MDYztkl2MnBwSAiYSU+/eYIKwxSQu3FvP 1sXIxSEksJdRYvaxZSwwRc9efWSFSBxklPh48w4zSIJXQFDix+R7QEUcHMwC6hJTpuRC1HQx SfRNOcoOEhcWkJDYvCcRJC4s0MYo8Xf6dHaQXjYBFYnj3zaAzeEUcJKY9+A+2BwWAVWJ749C QcLMAlsYJT6dTICwtSWevLvACrHWRuLznyOMELtOM0nsXDcHbKaIgLHE4cnfWSGOlpVYdPwK 2NESAu/ZJI5dWM88gVFkFpK7ZyHcPQvJjgWMzKsYhXITM3N0M/OM9BILCnJS9ZLzczcxgiJo up3gDsbjq6wOMQpwMCrx8GbMOBouxJpYVlyZe4hRmoNFSZx3luGxcCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2M194vXsO/44H0Cm2z1R8uamVd6bOYsanpiKFbiFPShUU/BGY67NI64Hl2 +nQf5aJUcaF9fh4Xrwvc1S8JKT1t/PtJdq/85OV3natMmNz/sUz4emieVuIBdrVlPq9/BrZy Pq/oe9AYnZV9KfFLvl3dU6W3L60XxT3r0mztXrJuh/PsFoaNTdIPlViKMxINtZiLihMBHOUL 8YECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUi2FAsqSv86li4wccUixl/JjJbvLj+kdli /5YXbBYz53xgsZi68jW7xdHzz9kslh77wOTA7rFz1l12jyVLfjJ5HP66kMWj5eNCVo8vlz+z BbBGcdmkpOZklqUW6dslcGWc/mdd0C1fsWj1d+YGxnbJLkZODgkBE4lnrz6yQthiEhfurWfr YuTiEBI4yCjx8eYdZpAEr4CgxI/J91i6GDk4mAXUJaZMyYWo6WKS6JtylB0kLiwgIbF5TyJI XFigjVHi7/Tp7CC9bAIqEse/bQCbwyngJDHvwX2wOSwCqhLfH4WChJkFtjBKfDqZAGFrSzx5 d4EVYq2NxOc/Rxghdp1mkti5bg7YTBEBY4nDk79DHS0rsej4FdYJjIKzkJw6C+HUWUjGLmBk XsUoUJSak1hprJdYUJCTqpecn7uJERzuhcE7GP8sszrEKMDBqMTD++LlsXAh1sSy4srcQ4wS HMxKIrynnwGFeFMSK6tSi/Lji0pzUosPMSYD/TKRWUo0OR8Yi3kl8YYmJgYmxsZmxsbmJuak CSuJ824+cjRcSCA9sSQ1OzW1ILUIZgsTB6dUA6NwnZT63Jvz/SYkTH0od3/xwsPtqwrCFHe8 +ndaI11amlXxysPjBws/R7c2v8ue8n/+Qe7OgMCPUc7zT39/mrVh3pHbGacDGeUO1d9bddbW LLqt9/DT0K2eAZxS3XdW8qwK0LryzPP+1sc684/aF23bbrVp6u+Dj7iZk090xXz8FSbrZMoa EHxTiaU4I9FQi7moOBEAkgFUhbsCAAA= Archived-At: Cc: ipsecme-chairs@ietf.org, ipsecme-chairs@tools.ietf.org, Tero Kivinen , IPsecME WG , Yoav Nir , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:56:12 -0000 > On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi all, >=20 > thanks for providing the reference to the draft. That was very helpful = and confirmed my initial assumption that you don=E2=80=99t want to = =E2=80=9Achange=E2=80=98 TCP. So this work seems to be fine in this = group, however, the wording in the charter is very misleading. What's = about the following? >=20 > "There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE packets need to be > encapsulated in ESP over TCP. Therefore the group will define a = mechanism to > use IKE and IPsec over TCP. Further the group will provide guidance=20 > how to detect when IKE cannot be negotiated over UDP and TCP as a = fallback should be used.=E2=80=9C >=20 > I also removed some redundancy and added a point that guidance is = needed to detect blocking. We could still at the current draft as a = starting point=E2=80=A6 "IKE packets need to be encapsulated in ESP over TCP" is not correct, = since IKE does not run over ESP. IKE and ESP packets run alongside one = another in the stream, as they do when using UDP encapsulation. How about: "There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, both IKE packets and tunneled ESP packets need to be encapsulated in TCP. Therefore the group will define=20= a mechanism to use IKE and IPsec over TCP, and define the scenarios in which it is appropriate to use this method." The draft covers the applicability of TCP encapsulation, but I strongly = believe that specific algorithm for fallback is out of scope. This will = be highly context-dependent, and we will have different algorithms for = different devices and scenarios. I have planned on writing an = informational draft as a follow-on to describe the methods we use, but = that should be independent of the protocol to define the IKE/ESP = messages in a stream, which is a much more general protocol. Thanks, Tommy >=20 > Mirja >=20 >=20 >> Am 31.08.2016 um 15:17 schrieb Yoav Nir : >>=20 >>=20 >>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>>=20 >>> Mirja Kuehlewind (IETF) writes: >>>> thanks for the reply. Very helpful background info. Maybe even put >>>> more information in the charter text.=20 >>>=20 >>> I think it belongs to the actual draft, not to the charter, perhaps = we >>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >>> a working draft.=20 >>>=20 >>>> When you say "the 3gpp specification did not consider or specify = all >>>> needed things for the protocol=E2=80=9C, can you be more specific = here? >>>=20 >>> 3GPP just said that we make TCP tunnel, put 16-bit length header in >>> front telling the length of the IKE or ESP packet coming after that, >>> and then we put either ESP packet directly, or 4-bytes of zeros >>> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>>=20 >>> There is also keepalive timer sending packets over TCP to keep it >>> alive (again similar what we have in UDP). >>=20 >> One more bit of information: some vendors have had a non-standardized = version of this or something similar for years. My employer has had it = since 2003, except that the header is a bit different. The pretty = ubiquitous SSL VPNs do pretty much the same except that they encrypt IP = packets plus headers into TLS records rather than ESP packets before = streaming them over TCP. >>=20 >> Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the = TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >>=20 >> Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Aug 31 12:36:42 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B931012D0BD; Wed, 31 Aug 2016 12:36:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 12:36:40 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 19:36:41 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-ipsecme-10-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems like a lot of documents for a 16-month window based on this group's past publication rate. Good to be ambitious, but I'm just wondering how realistic this is. From nobody Wed Aug 31 15:12:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC70912D08C for ; Wed, 31 Aug 2016 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 dYBShAs8jZ3E for ; Wed, 31 Aug 2016 15:12:35 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A8112D7B3 for ; Wed, 31 Aug 2016 15:12:30 -0700 (PDT) Received: (qmail 30271 invoked from network); 1 Sep 2016 00:05:05 +0200 Received: from p5dec2def.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.45.239) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Sep 2016 00:05:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> Date: Thu, 1 Sep 2016 00:05:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> References: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 22:12:37 -0000 That=E2=80=99s actually a good point that I forgot to mention as well. = Actually my question is, why is this limited needed at all? > Am 31.08.2016 um 21:36 schrieb Alissa Cooper : >=20 > Alissa Cooper has entered the following ballot position for > charter-ietf-ipsecme-10-00: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This seems like a lot of documents for a 16-month window based on this > group's past publication rate. Good to be ambitious, but I'm just > wondering how realistic this is. >=20 >=20 From nobody Wed Aug 31 18:40:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF87312D81D; Wed, 31 Aug 2016 18:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iUebZCTueYQu; Wed, 31 Aug 2016 18:40:10 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95BB12D818; Wed, 31 Aug 2016 18:39:06 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id i32so120235567uai.2; Wed, 31 Aug 2016 18:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Saq7A0jwOII1x7xkN5ZPa++QFllr5hQJFcOSG0Xq1Hk=; b=Fs0Pvsgtoe7MCmH7vd1iVMSY0+yjvKqZ20QRqdegiwZWDfYdPXnTl+SuRbLBJTiZ8o FF13zdfmNNmU6tgvgzpp3vM5eBPGXPDVYHaZe5ofxuG9B+o+ZuuoUHzZmH4Fw3QyPWju vX5Xdyg+eoCHH5uCiOvHo5VZbWsA/POaAl1F78GpdYlkSeynFX7oGwIQGPRiYD9uHBNc CeSQnRxFzfDs3zXideyU6DNeZ3tNhxjShwv4Hu8SaUHhfvP6p9p3dExCWnJWeqkg9IaF 2R1GOIZSHGbAT/5Yu4NYinVGmeYfxxEHc8g5CKm4nxh5suiaIpjDUuszzuJ3vcpobHBI 15Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Saq7A0jwOII1x7xkN5ZPa++QFllr5hQJFcOSG0Xq1Hk=; b=XFVd88Jom2XDmcXcdi+ewHrSRB+glxLcIMSm2j86F1EVOdvjBb+I05EqVo5qw8KTYG q5dQ6K+gmQbewcmRpq4rQvuKwc6VlecL4dreXdcEupbEUMsMx330H8MFUJ9CF042Gx1g Bz3xH6Z5JaIaDoMI7CmdIdwGLrz0hvm3XRrjheJmJlzqeNvNuPf1klFzCOXzHALw2oR+ Cxxu7EHejYJCc9wLvQ3zfW2QGI5OIm6iA0LxxSJTKEEiNEuqSmjTRpMgha5E4kk+DBr0 AYXX9x2eAIgKTpG8jpfYdQDFEFsrQ5IVwEIzpD5M6mE4BmaU0c9g3+6WWO4FvUWx1swv Pw8A== X-Gm-Message-State: AE9vXwMz/Byz4iO1GhaWToVC/EnhltD+pdJcH40WUwq+iHn+0d7dZw5otmusVlsxaA6+EU7+1W7vRxkOYLsqpA== X-Received: by 10.159.53.1 with SMTP id o1mr7459851uao.15.1472693945849; Wed, 31 Aug 2016 18:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 31 Aug 2016 18:39:05 -0700 (PDT) In-Reply-To: <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> References: <147267220071.31935.11277403442737346313.idtracker@ietfa.amsl.com> <213F05E8-C281-493F-8229-F9529949DAD9@kuehlewind.net> From: Kathleen Moriarty Date: Wed, 31 Aug 2016 21:39:05 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , ipsecme-chairs@ietf.org, Alissa Cooper , The IESG Subject: Re: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-10-00: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:40:12 -0000 On Wed, Aug 31, 2016 at 6:05 PM, Mirja Kuehlewind (IETF) wrote: > That=E2=80=99s actually a good point that I forgot to mention as well. Ac= tually my question is, why is this limited needed at all? The WG has had this in their charter for some time. The previous chairs with the WG have wanted to keep a window set since this is a maintenance WG as a way to prevent it from living on beyond it's usefulness. They believe that it's okay to shutdown the WG if it dwindles and would like to have ways to determine if that is necessary. They are also fine with a temporary closing to then reopen as another follow on effort. This is a follow on WG itself after the original WG responsible for IPsec had closed for a few years. > > >> Am 31.08.2016 um 21:36 schrieb Alissa Cooper : >> >> Alissa Cooper has entered the following ballot position for >> charter-ietf-ipsecme-10-00: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This seems like a lot of documents for a 16-month window based on this >> group's past publication rate. Good to be ambitious, but I'm just >> wondering how realistic this is. Yes, it's ambitious. I'll leave that to the chairs to respond. In the past they have tried to keep the date to a reasonable one to complete work or to close if the WG became too inactive since it's along-standing one. It has gotten some new life recently, so I don't expect this WG to close too soon. >> >> > --=20 Best regards, Kathleen From nobody Wed Aug 31 18:53:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD3C12D7DC; Wed, 31 Aug 2016 18:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Y3NygnU1uTrP; Wed, 31 Aug 2016 18:53:40 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865E512B051; Wed, 31 Aug 2016 18:53:27 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id i32so120660940uai.2; Wed, 31 Aug 2016 18:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zfDP0aISjKbZvfwj8U3FpLToayjKGm9Rjoftlca8VZI=; b=y5jUruwOYx46zxDQ5QaTjOdDfr9dmStobLbzNIq9i/o9xOoFJaQ6mQmacDOjkXC6OV BE9+Pp00FJDHhgeMEYkMqjJLM04FGv2wlZuGYqDeZFuGVzemjMIFKkf5PilS2P3h+VK/ O0BhNsqtT8MiL8rpi573f+D517NZAwLeJBvk48pf0yewjC+eEL2herK75ESDIALeWJTc OVs9IYhGnXp1FG9L9iaDU/Dz3qzLwpNc1PfA6WJiVzMmn6AHymc0MT4yD1NQ7US/WZ9c IZv4fMouKQ7i1evfRUHZklrce+hfCD57sYanZZwXVLs2Q/24pYzTYjj+cHP6z/VhVhEC 8uVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zfDP0aISjKbZvfwj8U3FpLToayjKGm9Rjoftlca8VZI=; b=EJ6n4mqlM/lqZ1NBgqKZypV/X5w0vUhLALo0wrQbG2Rx5p2PNhVliR2eHzodrE913T DXXCEHEfyYYqU19tIXdl15RsgcDKExTILO3vgLvUbQ+9l9l6/oUtSDp52U5bsC5znNzQ Pea7m0zeilKSMCAXFsSr7zuPG9PBvQQ9zhXN8F4YNyq48kkAxqq8cwJnQ9Fv2550u957 tFmKWNU57NPN3ZD1ExigN8eTkklV//sMaohYIpSK1GSOVH7ANI/65X3RawIfmZRBtzpy WQRG8y606peN2/GntFdJo2fo58K2kC+VT6MdaZp4hiDl9vL2p1tKUgDWPsk+P9qFejNI nbyw== X-Gm-Message-State: AE9vXwO+uwAhwavMGZgNvj+Qtw4TrkbVtrcfhwgiN3yEliEFJfvtJbxhUJd77gL68at6zYvCb9rjdN9h5BIPyQ== X-Received: by 10.31.92.135 with SMTP id q129mr7788589vkb.156.1472694806624; Wed, 31 Aug 2016 18:53:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 31 Aug 2016 18:53:26 -0700 (PDT) In-Reply-To: <2FE3792A-D7D0-43F9-ACC4-0DCB69AB038E@apple.com> References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> <2FE3792A-D7D0-43F9-ACC4-0DCB69AB038E@apple.com> From: Kathleen Moriarty Date: Wed, 31 Aug 2016 21:53:26 -0400 Message-ID: To: Tommy Pauly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ipsecme-chairs@ietf.org, "ipsecme-chairs@tools.ietf.org" , Yoav Nir , IPsecME WG , "Mirja Kuehlewind \(IETF\)" , Tero Kivinen , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:53:42 -0000 Tommy, On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly wrote: > >> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) wrote: >> >> Hi all, >> >> thanks for providing the reference to the draft. That was very helpful a= nd confirmed my initial assumption that you don=E2=80=99t want to =E2=80=9A= change=E2=80=98 TCP. So this work seems to be fine in this group, however, = the wording in the charter is very misleading. What's about the following? >> >> "There have been middle boxes blocking IKE negotiation over UDP. To >> make IKE work in these environments, IKE packets need to be >> encapsulated in ESP over TCP. Therefore the group will define a mechanis= m to >> use IKE and IPsec over TCP. Further the group will provide guidance >> how to detect when IKE cannot be negotiated over UDP and TCP as a fallba= ck should be used.=E2=80=9C >> >> I also removed some redundancy and added a point that guidance is needed= to detect blocking. We could still at the current draft as a starting poin= t=E2=80=A6 > > "IKE packets need to be encapsulated in ESP over TCP" is not correct, sin= ce IKE does not run over ESP. IKE and ESP packets run alongside one another= in the stream, as they do when using UDP encapsulation. > > How about: > > "There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, both IKE packets and tunneled ESP > packets need to be encapsulated in TCP. Therefore the group will define > a mechanism to use IKE and IPsec over TCP, and define the scenarios > in which it is appropriate to use this method." Are you okay with Tero's proposed wording since Mirja has agreed to it. The suggested wording is: There have been middle boxes blocking IKE negotiation over UDP. To make IKE work in these environments, IKE and ESP packets need to be transmitted over TCP. Therefore the group will define a mechanism to use IKE and IPsec over TCP. Further the group will provide guidance how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used. Sorry for my delayed response to make sure this was addressed, I was off today and driving for a good portion of the day. Thanks, Kathleen > > The draft covers the applicability of TCP encapsulation, but I strongly b= elieve that specific algorithm for fallback is out of scope. This will be h= ighly context-dependent, and we will have different algorithms for differen= t devices and scenarios. I have planned on writing an informational draft a= s a follow-on to describe the methods we use, but that should be independen= t of the protocol to define the IKE/ESP messages in a stream, which is a mu= ch more general protocol. > > Thanks, > Tommy > >> >> Mirja >> >> >>> Am 31.08.2016 um 15:17 schrieb Yoav Nir : >>> >>> >>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>>> >>>> Mirja Kuehlewind (IETF) writes: >>>>> thanks for the reply. Very helpful background info. Maybe even put >>>>> more information in the charter text. >>>> >>>> I think it belongs to the actual draft, not to the charter, perhaps we >>>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >>>> a working draft. >>>> >>>>> When you say "the 3gpp specification did not consider or specify all >>>>> needed things for the protocol=E2=80=9C, can you be more specific her= e? >>>> >>>> 3GPP just said that we make TCP tunnel, put 16-bit length header in >>>> front telling the length of the IKE or ESP packet coming after that, >>>> and then we put either ESP packet directly, or 4-bytes of zeros >>>> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>>> >>>> There is also keepalive timer sending packets over TCP to keep it >>>> alive (again similar what we have in UDP). >>> >>> One more bit of information: some vendors have had a non-standardized v= ersion of this or something similar for years. My employer has had it since= 2003, except that the header is a bit different. The pretty ubiquitous SSL= VPNs do pretty much the same except that they encrypt IP packets plus head= ers into TLS records rather than ESP packets before streaming them over TCP= . >>> >>> Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because the T= CP does not tunnel. That is part of the function of ESP. Perhaps we should = be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >>> >>> Yoav >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > --=20 Best regards, Kathleen From nobody Wed Aug 31 18:57:17 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13812B030; Wed, 31 Aug 2016 18:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 18:57:10 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Subject: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:57:10 -0000 Ben Campbell has entered the following ballot position for charter-ietf-ipsecme-10-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Alissa's concern about the number of documents for the time window. From nobody Wed Aug 31 18:59:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175A412B040 for ; Wed, 31 Aug 2016 18:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kBSs68o4gxUz for ; Wed, 31 Aug 2016 18:59:02 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8334A12B03C for ; Wed, 31 Aug 2016 18:59:02 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id q42so62405282uaq.1 for ; Wed, 31 Aug 2016 18:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=zkfmyysxQs9XhN1rcDCYKczKkqH/JmEHnXwhjgMRdgQ=; b=oHaF+aKAfq85NfQAbevSlwUGBGB4zngiyPqvEsX7ZxFTG8L1Pz4AGaVzCXUTjinOyL E1esbLRrnV6UZ/cCa+WkdOqJ3atUgz8owdVfCdWIfo2jScpNvB8NibpQ36HI7JKqbbRU WU2Vjs+RvjV1GaxyDyg8WwStHShTcLDz+FNyk365iDhFz+hQ4eLUE6vkI9FWfOHWBFp/ 2enCbOlLfLX89Ux4S218EjTFS1iaHDUHRJE7bScXhVg5sCSlAFlgSQDc0+uB3oy/dfH9 deHJLHTuTm4WbsRquhqVgA9WtmslnFvQLulc+OxHrtEW+ZHOK4Q6RGmKwNF7LHvOFh7I xypg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zkfmyysxQs9XhN1rcDCYKczKkqH/JmEHnXwhjgMRdgQ=; b=YC7RTVDWsFYQMmOxTj9dvRW5d6qP2PtEwThTfWT+giLXVdRJuYZdTr58F+FlyvJmcO hH8PgAH38mrjX7kNeZn1AE1/8yi0j5CW0SnLcyW8WloRJZYla2NJcr847H2Xs4FkYvKZ OqdnBa6nwF4NM/AY+eOIquPjOPxhctCQiScHWMzz+5yw688r7dDitiUtXWYDXsmGEmYq 7kgx/BEwi43BEGgHo9jnFzItu6x8uHRi39CWo9r1CUUJ3mPCK9ZCUv88l2rYj+dXqmO5 cD5H7yBa0itSvPOCGbJNMBnbeBBOh4eCe6CtOtqn7YX7rKrFoHXzYz7Vn7X2aqbTMbuu lA5w== X-Gm-Message-State: AE9vXwOksrT2Njv39etIpXjeCcgCisyWf/XpOjeFqbqP2n+tBbqRfic0/rUBm7XOdKgjSt8kMmT/Oa3d54BIfg== X-Received: by 10.31.129.11 with SMTP id c11mr7557442vkd.25.1472695141527; Wed, 31 Aug 2016 18:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Wed, 31 Aug 2016 18:59:01 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 31 Aug 2016 21:59:01 -0400 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] charter X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:59:04 -0000 Hello, I just updated the proposed charter text to match the most recent discussions with the IESG. Please do read it to make sure the WG is in agreement with the changes. I believe the WG is fine with them. https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ I used Tero's wording on the changes discussed with Mirja. If it should follow Tommy's suggestion, please let me know. Thank you. -- Best regards, Kathleen From nobody Wed Aug 31 19:53:37 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238CB12D7EF; Wed, 31 Aug 2016 19:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Tay3HFUYeA-I; Wed, 31 Aug 2016 19:53:34 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486BD12D0C8; Wed, 31 Aug 2016 19:53:24 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id l2so71858333qkf.3; Wed, 31 Aug 2016 19:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wx9UzS4T/OP6RpVUgJ3tljyDl3tQT3klyWt32jlQwYI=; b=KsnO5QmJLGsnOfJoep18kFQHwDiTFifuF2obCYTzbaqiGcCfBfG5o+6Ey2W7Sk0p85 Fmg0KK26Ra4Zm3inPGZ3uE2oX3ANdgmFMH2eOSZvcV8a5LDeCxcN5+G8a2QMT1oRYwNg GcKv36wS/zFTT1ZnGHgS+qNLpf1+6504c9i36mv7JlUfqPdvUV+U8IPh7YmW9n335nW0 qiISKU4nNApnMOCkbMX1eB+KoYHKNnjXhVzsK+4bBRZLXp+SylZFgiAYq8gl5xx2lLBt co+ohjQ/inyPe09++og7i894W7uH5QACD63aUn4dMHrX0wIQXfPVBWCNIstCl4vSEMTl v0Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wx9UzS4T/OP6RpVUgJ3tljyDl3tQT3klyWt32jlQwYI=; b=bWjQpFBOr75W5o27KrNt4oedl2ULpO5rml4JlKeZvH7RdauoYJJyo0K846ArukybKW o1oPhWb/x4pflc3sN5KKf1oyW94lTnDqvUS65zBOzalUkB3gJg6vpaGo809nb2vou5i7 fZU9SPunomiDKBe9smAyZlL3p4XE+RT64f/yti+w8swOQ1SAKBF+3mU6TbBuRzwDtPuy W0Fltm4sIuCrfB/Y7PDapIaMYBYyTT762YthBCKbecvO/1blYXikIq8lnIsf09M/brC9 rGhJBUE05wzOuy/k/qOa6Hd0ZLMB8XoJexIBNuBu41xunMPY577B3RVW37+EUu6o/UYy 1MVQ== X-Gm-Message-State: AE9vXwM+YaajwqdOOLu8zI+HRa7NMdBE949HxPmjjm+SY/cDeUXgP+WdZTXD68IUgQMiXw== X-Received: by 10.55.72.196 with SMTP id v187mr11573625qka.37.1472698403473; Wed, 31 Aug 2016 19:53:23 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id c23sm1629160qtc.45.2016.08.31.19.53.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 19:53:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G35) In-Reply-To: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 22:53:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com> References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> To: Ben Campbell Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 02:53:36 -0000 Tero & Dave, Could you respond on the timeline and if you think it's reasonable and why o= r if it should be changed. Thanks, Kathleen=20 Sent from my iPhone > On Aug 31, 2016, at 9:57 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > charter-ietf-ipsecme-10-01: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I share Alissa's concern about the number of documents for the time > window. >=20 >=20 From nobody Wed Aug 31 20:14:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154CE12D5C0 for ; Wed, 31 Aug 2016 20:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.639 X-Spam-Level: X-Spam-Status: No, score=-4.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.com 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 BgZjgVv2I2tb for ; Wed, 31 Aug 2016 20:13:58 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66F212D16F for ; Wed, 31 Aug 2016 20:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1472699638; x=2336613238; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RmSO/lbrNtQ00nqGSwT3hT5TuXfLIDhm2LUchyBYgPE=; b=FUy0hVr0XeFCYmTAfgXwuekif8tvUOnNAehIR5Z/4EMINMHFw1bBh5vr9klkFhVc /dYBtGpx3yyD2TZQ/OrHIcLNhX/Y8PzG8ak89QSFMzpfsNTA3UeumKkryxGpsGoT CGMoiUmx4RgW8mCovF1iYVA1vWAvYsKR9h0IL4zZSDxQivO54ZEA5ghbgDxh+xJD rI+kG1k3gaBWkd477zt6U3wxWZDbRqibkBXsAf13sT/K4o+hDawLd80Debk4SawB R/DSuZzAUu6YKS/d3JxWQX+Tk3gm699sjImCKiD4PDhcPlJtHNjM/MpWsV2iwBdN JFiym+pyNdPlsnOUjdPvEw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 05.2A.07273.6FC97C75; Wed, 31 Aug 2016 20:13:58 -0700 (PDT) X-AuditID: 11973e13-f794a6d000001c69-4a-57c79cf6a3a3 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay5.apple.com (Apple SCV relay) with SMTP id 5A.73.30701.5FC97C75; Wed, 31 Aug 2016 20:13:58 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XvGE6zB7uInpKKQFHwSVJQ)" Received: from [17.153.27.233] (unknown [17.153.27.233]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OCT00IOE2B9U410@nwk-mmpp-sz09.apple.com>; Wed, 31 Aug 2016 20:13:57 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <3EAA1FDC-D534-4512-B845-905DFF1F425C@apple.com> Date: Wed, 31 Aug 2016 20:13:57 -0700 In-reply-to: To: Kathleen Moriarty References: <147264035968.5285.5678053907364382538.idtracker@ietfa.amsl.com> <22470.50740.674721.131053@fireball.acr.fi> <1F2E47DA-98F5-44C2-8EE6-E185F2AC8855@kuehlewind.net> <22470.52172.370022.168002@fireball.acr.fi> <80F0837E-9F50-4A46-A35F-27D45251253D@gmail.com> <2FE3792A-D7D0-43F9-ACC4-0DCB69AB038E@apple.com> X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUi2FAYofttzvFwg2UPeCxm/JnIbPHi+kdm i/1bXrBZzJzzgcVi6srX7BYNO/Mtjp5/zmax9NgHJgcOj52z7rJ7LFnyk8nj8NeFLB4tHxey eny5/JktgDWKyyYlNSezLLVI3y6BK6N/93aWggOfGSua1hxha2C8fpGxi5GTQ0LARGLuz5tQ tpjEhXvr2boYuTiEBPYySiy8M40FpmjDhIlQiYOMEv+ftjCDJHgFBCV+TL4HVsQsECax985f qKIuJomPz/uBHA4OYQEJic17EkFq2ARUJI5/2wDVayPx9/kWsHphgTZGib/Tp7ODJFgEVCXO nuljBbE5BYIlrj9ZwAJSxCzQySRx4v1/sCIRAQuJNc3foLYdZZbY8auZFeJWWYlFx6+wgiQk BCazS6xe94h9AqPwLCTnzkJy7iygC5kF1CWmTMmFCGtLPHl3gRXCVpNY+HsRE7L4Aka2VYxC uYmZObqZeaZ6iQUFOal6yfm5mxhBUTjdTngH4+lVVocYBTgYlXh4Hd4cCxdiTSwrrsw9xCjN waIkzns+4Hi4kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYjd60PLFwjVS+gHKnC3fcybfKX y216+VuWhuhMup+sdPrn/IgbAs6maj4KTR4X7qlGT93N8/b0rm3TL6mcjYozf9Cx78DpT68f cnXy1OnyLtWzeXHctap69/q7M1osm3muPGjjeuf6XGyx5Wtzi08Raw7ceqccmPVDefL37g3+ 7zdtuxLdvjlJiaU4I9FQi7moOBEAm04AMqMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUi2FAcoPttzvFwg94FrBYz/kxktnhx/SOz xf4tL9gsZs75wGIxdeVrdouGnfkWR88/Z7NYeuwDkwOHx85Zd9k9liz5yeRx+OtCFo+WjwtZ Pb5c/swWwBrFZZOSmpNZllqkb5fAldG/eztLwYHPjBVNa46wNTBev8jYxcjJISFgIrFhwkQ2 CFtM4sK99UA2F4eQwEFGif9PW5hBErwCghI/Jt9jAbGZBcIk9t75C1XUxSTx8Xk/kMPBISwg IbF5TyJIDZuAisTxbxugem0k/j7fAlYvLNDGKPF3+nR2kASLgKrE2TN9rCA2p0CwxPUnC1hA ipgFOpkkTrz/D1YkImAhsab5G9S2o8wSO341s0LcKiux6PgV1gmMArOQXDgLyYWzgI5iFlCX mDIlFyKsLfHk3QVWCFtNYuHvRUzI4gsY2VYxChSl5iRWmuolFhTkpOol5+duYgRHTWHEDsb/ y6wOMQpwMCrx8Dq+ORYuxJpYVlyZe4hRgoNZSYR37czj4UK8KYmVValF+fFFpTmpxYcYJzIC vTmRWUo0OR8Y03kl8YYmJgYmxsZmxsbmJua0FFYS591y5Gi4kEB6YklqdmpqQWoRzFFMHJxS DYw7N9fXer3VOBVav8+7QKznm2jMGi69xNArtaEz511ZnynZF9d7hnXZSstTKl66ynctKxJC djCe2G7ivsx/xvKmGAcGUekd283N/RRvWLS91t20bfa3ROVJa+d9Lpnyle/23+JjSqrRRg6y NivOLjxb8PSGpPAm/57zug8VZcSTa6sY/74PdVJiKc5INNRiLipOBAAn/18pDQMAAA== Archived-At: Cc: ipsecme-chairs@ietf.org, "ipsecme-chairs@tools.ietf.org" , Yoav Nir , IPsecME WG , "Mirja Kuehlewind \(IETF\)" , Tero Kivinen , The IESG Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?ipsecme-10-00=3A_=28with_BLOCK=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 03:14:01 -0000 --Boundary_(ID_XvGE6zB7uInpKKQFHwSVJQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Kathleen, > On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty = wrote: >=20 > Tommy, >=20 > On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly > wrote: >>=20 >>> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi all, >>>=20 >>> thanks for providing the reference to the draft. That was very = helpful and confirmed my initial assumption that you don=E2=80=99t want = to =E2=80=9Achange=E2=80=98 TCP. So this work seems to be fine in this = group, however, the wording in the charter is very misleading. What's = about the following? >>>=20 >>> "There have been middle boxes blocking IKE negotiation over UDP. To >>> make IKE work in these environments, IKE packets need to be >>> encapsulated in ESP over TCP. Therefore the group will define a = mechanism to >>> use IKE and IPsec over TCP. Further the group will provide guidance >>> how to detect when IKE cannot be negotiated over UDP and TCP as a = fallback should be used.=E2=80=9C >>>=20 >>> I also removed some redundancy and added a point that guidance is = needed to detect blocking. We could still at the current draft as a = starting point=E2=80=A6 >>=20 >> "IKE packets need to be encapsulated in ESP over TCP" is not correct, = since IKE does not run over ESP. IKE and ESP packets run alongside one = another in the stream, as they do when using UDP encapsulation. >>=20 >> How about: >>=20 >> "There have been middle boxes blocking IKE negotiation over UDP. To >> make IKE work in these environments, both IKE packets and tunneled = ESP >> packets need to be encapsulated in TCP. Therefore the group will = define >> a mechanism to use IKE and IPsec over TCP, and define the scenarios >> in which it is appropriate to use this method." >=20 > Are you okay with Tero's proposed wording since Mirja has agreed to > it. The suggested wording is: >=20 > There have been middle boxes blocking IKE negotiation over UDP. To > make IKE work in these environments, IKE and ESP packets need to be > transmitted over TCP. Therefore the group will define a mechanism to > use IKE and IPsec over TCP. Further the group will provide guidance > how to detect when IKE cannot be negotiated over UDP and TCP as a > fallback should be used. The final sentence seems like it's missing a word after "guidance": "Further the group will provide guidance how to detect when IKE cannot be negotiated over UDP and TCP as a fallback should be used." How about: "The group will also provide guidance on how to detect when IKE cannot = be negotiated over UDP, and TCP should be used as a fallback". =46rom a content perspective, I am fine with this as long as the primary = draft leaves the algorithm as a fairly open-ended suggestion. I think it = is appropriate to say that the IKE_SA_INIT should be sent over UDP = several times, after which point a fallback to TCP is appropriate if so = configured on the device (and that this fallback may be sooner if there = is historical reason to believe it is necessary). Any more specifics = about timing and how to measure expected response times, etc, would be = out of scope. Does that work? Thanks, Tommy >=20 > Sorry for my delayed response to make sure this was addressed, I was > off today and driving for a good portion of the day. >=20 > Thanks, > Kathleen >=20 >>=20 >> The draft covers the applicability of TCP encapsulation, but I = strongly believe that specific algorithm for fallback is out of scope. = This will be highly context-dependent, and we will have different = algorithms for different devices and scenarios. I have planned on = writing an informational draft as a follow-on to describe the methods we = use, but that should be independent of the protocol to define the = IKE/ESP messages in a stream, which is a much more general protocol. >>=20 >> Thanks, >> Tommy >>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>> Am 31.08.2016 um 15:17 schrieb Yoav Nir : >>>>=20 >>>>=20 >>>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: >>>>>=20 >>>>> Mirja Kuehlewind (IETF) writes: >>>>>> thanks for the reply. Very helpful background info. Maybe even = put >>>>>> more information in the charter text. >>>>>=20 >>>>> I think it belongs to the actual draft, not to the charter, = perhaps we >>>>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as >>>>> a working draft. >>>>>=20 >>>>>> When you say "the 3gpp specification did not consider or specify = all >>>>>> needed things for the protocol=E2=80=9C, can you be more specific = here? >>>>>=20 >>>>> 3GPP just said that we make TCP tunnel, put 16-bit length header = in >>>>> front telling the length of the IKE or ESP packet coming after = that, >>>>> and then we put either ESP packet directly, or 4-bytes of zeros >>>>> (Non-ESP marker we use in UDP encapsulation) and IKE packet. >>>>>=20 >>>>> There is also keepalive timer sending packets over TCP to keep it >>>>> alive (again similar what we have in UDP). >>>>=20 >>>> One more bit of information: some vendors have had a = non-standardized version of this or something similar for years. My = employer has had it since 2003, except that the header is a bit = different. The pretty ubiquitous SSL VPNs do pretty much the same except = that they encrypt IP packets plus headers into TLS records rather than = ESP packets before streaming them over TCP. >>>>=20 >>>> Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term because = the TCP does not tunnel. That is part of the function of ESP. Perhaps we = should be saying =E2=80=9CTCP streaming of ESP and IKE packets=E2=80=9D >>>>=20 >>>> Yoav >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Boundary_(ID_XvGE6zB7uInpKKQFHwSVJQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Kathleen,

On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Tommy,

On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly = <tpauly@apple.com> wrote:

On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind = (IETF) <ietf@kuehlewind.net> wrote:

Hi all,

thanks for providing the = reference to the draft. That was very helpful and confirmed my initial = assumption that you don=E2=80=99t want to =E2=80=9Achange=E2=80=98 TCP. = So this work seems to be fine in this group, however, the wording in the = charter is very misleading. What's about the following?

"There have been middle boxes blocking IKE negotiation over = UDP. To
make IKE work in these environments, IKE packets = need to be
encapsulated in ESP over TCP. Therefore the = group will define a mechanism to
use IKE and IPsec over = TCP. Further the group will provide guidance
how to detect = when IKE cannot be negotiated over UDP and TCP as a fallback should be = used.=E2=80=9C

I also removed some = redundancy and added a point that guidance is needed to detect blocking. = We could still at the current draft as a starting point=E2=80=A6

"IKE packets need to be = encapsulated in ESP over TCP" is not correct, since IKE does not run = over ESP. IKE and ESP packets run alongside one another in the stream, = as they do when using UDP encapsulation.

How = about:

"There have been middle boxes = blocking IKE negotiation over UDP. To
make IKE work in = these environments, both IKE packets and tunneled ESP
packets need to be encapsulated in TCP. Therefore the group = will define
a mechanism to use IKE and IPsec over TCP, and = define the scenarios
in which it is appropriate to use = this method."

Are you okay with Tero's proposed wording = since Mirja has agreed to
it.  The suggested wording = is:

There have been = middle boxes blocking IKE negotiation over UDP. To
make IKE work in = these environments, IKE and ESP packets need to be
transmitted over = TCP. Therefore the group will define a mechanism to
use IKE and IPsec = over TCP. Further the group will provide guidance
how to detect when = IKE cannot be negotiated over UDP and TCP as a
fallback should be = used.

The final = sentence seems like it's missing a word after "guidance":

"Further the group will provide guidance
how = to detect when IKE cannot be negotiated over UDP and TCP as a
fallback should be used."

How about:

"The = group will also provide guidance on how to detect when IKE cannot be = negotiated over UDP, and TCP should be used as a = fallback".

=46rom a content = perspective, I am fine with this as long as the primary draft leaves the = algorithm as a fairly open-ended suggestion. I think it is appropriate = to say that the IKE_SA_INIT should be sent over UDP several times, after = which point a fallback to TCP is appropriate if so configured on the = device (and that this fallback may be sooner if there is historical = reason to believe it is necessary). Any more specifics about timing and = how to measure expected response times, etc, would be out of scope. Does = that work?

Thanks,
Tommy


Sorry for my = delayed response to make sure this was addressed, I was
off today and = driving for a good portion of the day.

Thanks,
Kathleen


The draft = covers the applicability of TCP encapsulation, but I strongly believe = that specific algorithm for fallback is out of scope. This will be = highly context-dependent, and we will have different algorithms for = different devices and scenarios. I have planned on writing an = informational draft as a follow-on to describe the methods we use, but = that should be independent of the protocol to define the IKE/ESP = messages in a stream, which is a much more general protocol.

Thanks,
Tommy


Mirja


Am 31.08.2016 um 15:17 schrieb Yoav Nir <ynir.ietf@gmail.com>:


On 31 Aug 2016, at 3:21 = PM, Tero Kivinen <kivinen@iki.fi> wrote:

Mirja Kuehlewind (IETF) writes:
thanks for the reply. Very helpful background = info. Maybe even put
more information in the charter = text.

I think it belongs to = the actual draft, not to the charter, perhaps we
should = put the draft-ietf-ipsecme-tcp-encaps in the charter, as
a = working draft.

When you say "the 3gpp specification did not consider or = specify all
needed things for the protocol=E2=80=9C, can = you be more specific here?

3GPP = just said that we make TCP tunnel, put 16-bit length header in
front telling the length of the IKE or ESP packet coming = after that,
and then we put either ESP packet directly, or = 4-bytes of zeros
(Non-ESP marker we use in UDP = encapsulation) and IKE packet.

There is = also keepalive timer sending packets over TCP to keep it
alive (again similar what we have in UDP).

One more bit of information: some = vendors have had a non-standardized version of this or something similar = for years. My employer has had it since 2003, except that the header is = a bit different. The pretty ubiquitous SSL VPNs do pretty much the same = except that they encrypt IP packets plus headers into TLS records rather = than ESP packets before streaming them over TCP.

Perhaps =E2=80=9CTCP tunnel=E2=80=9D is a misleading term = because the TCP does not tunnel. That is part of the function of ESP. = Perhaps we should be saying =E2=80=9CTCP streaming of ESP and IKE = packets=E2=80=9D

Yoav

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




-- 

Best regards,
Kathleen

= --Boundary_(ID_XvGE6zB7uInpKKQFHwSVJQ)--