From nobody Sun Nov 1 17:28:18 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CA11B400C for ; Sun, 1 Nov 2015 17:28:16 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO294PvwED7q for ; Sun, 1 Nov 2015 17:28:13 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 13E5E1B4009 for ; Sun, 1 Nov 2015 17:28:13 -0800 (PST) Received: by pabfh17 with SMTP id fh17so6658558pab.0 for ; Sun, 01 Nov 2015 17:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=uc9waDSv8ign7inet3yz18XD/0QfsggB+V3OOBi/Oew=; b=mY0QYbI9ZhCa0iIDO6Evl6JG5jWu52/QrVK2+3NE4x2F0f4SCcuJUdCT9hY4ym2SKA fKtSboHdTwMhCQ94MBSBccZv5j/+QEaO4zymOvmW4OgJ3X5z/Ku32KubuuqBlBAoNC4i oFpjicQWoGxadwPzrVdFKw/hdacvmUOS97XHVJlbZcF9SftRQJ4j04aTeni5nbq8u+xw BpWzJYT9mseHPHd+j3IFQqci3BuotvHT3yFPP1BMZ5Og0xOH0jbSvAhsqiHHD3tbAyes FWVbwEdHePB54YXC7uBacGvjz9JglzS+7dUswcuXlYxNBU4siBeHr1Cj0GHNC2aefDny HXcw== X-Received: by 10.66.121.199 with SMTP id lm7mr24305599pab.30.1446427692648; Sun, 01 Nov 2015 17:28:12 -0800 (PST) Received: from t20010c4000003024ac2aff0a4c032f4c.v6.meeting.ietf94.jp (t20010c4000003024ac2aff0a4c032f4c.v6.meeting.ietf94.jp. [2001:c40:0:3024:ac2a:ff0a:4c03:2f4c]) by smtp.gmail.com with ESMTPSA id u10sm20493509pbs.63.2015.11.01.17.28.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 17:28:11 -0800 (PST) From: Yoav Nir Content-Type: multipart/mixed; boundary="Apple-Mail=_CCBAF1F4-E837-4847-984A-926D967EA613" Message-Id: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> Date: Mon, 2 Nov 2015 10:28:08 +0900 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:28:17 -0000 --Apple-Mail=_CCBAF1F4-E837-4847-984A-926D967EA613 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all Since we=E2=80=99ve had quite a bit of bikeshedding about this on the = list, we=E2=80=99d like to gather and has it out face to face. So this Wednesday at 7:00 PM, right after the plenaries, we=E2=80=99ll = meet at room 421 to hash this out. Everyone=E2=80=99s invited, obviously. Yoav P.S. Someone=E2=80=99s asked me off-list whether there is any IPsecME = document that says not to trust SHA-1 in signatures, both AUTH payload = and certificates, the way the TLS 1.3 document may end up saying for = TLS. I=E2=80=99m wondering if RFC4307bis might be the place for this, in = particular the signature in AUTH payload. Just something to think about = before we bikeshed.RFC4307bis Bikeshedding Session. --Apple-Mail=_CCBAF1F4-E837-4847-984A-926D967EA613 Content-Disposition: attachment; filename=RFC4307_Bikeshedding_Session.ics Content-Type: text/calendar; name="RFC4307_Bikeshedding_Session.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0AVERSION:2.0=0D=0APRODID:-//www.marudot.com//iCal=20= Event=20Maker=0D=0AX-WR-CALNAME:RFC4307=20Bikeshedding=20Session=0D=0A= CALSCALE:GREGORIAN=0D=0ABEGIN:VTIMEZONE=0D=0ATZID:Asia/Tokyo=0D=0A= TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Tokyo=0D=0A= X-LIC-LOCATION:Asia/Tokyo=0D=0ABEGIN:STANDARD=0D=0ATZOFFSETFROM:+0900=0D=0A= TZOFFSETTO:+0900=0D=0ATZNAME:JST=0D=0ADTSTART:19700101T000000=0D=0A= END:STANDARD=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A= DTSTAMP:20151102T012630Z=0D=0AUID:20151102T012630Z-928189842@marudot.com=0D= =0ADTSTART;TZID=3D"Asia/Tokyo":20151104T190000=0D=0A= DTEND;TZID=3D"Asia/Tokyo":20151104T210000=0D=0ASUMMARY:RFC=204307bis=20= Bikeshedding=20Session=0D=0ADESCRIPTION:Discuss=20the=20algorithms=20and=20= their=20level=20of=20requirement=0D=0ALOCATION:Room=20421=0D=0A= BEGIN:VALARM=0D=0AACTION:DISPLAY=0D=0ADESCRIPTION:RFC=204307bis=20= Bikeshedding=20Session=0D=0ATRIGGER:-PT15M=0D=0AEND:VALARM=0D=0A= END:VEVENT=0D=0AEND:VCALENDAR= --Apple-Mail=_CCBAF1F4-E837-4847-984A-926D967EA613-- From nobody Sun Nov 1 18:44:55 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4117E1B4288 for ; Sun, 1 Nov 2015 18:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doY-sKNcP05B for ; Sun, 1 Nov 2015 18:44:52 -0800 (PST) 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 364E61B4286 for ; Sun, 1 Nov 2015 18:44:52 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3npz9Z0jP5z9J; Mon, 2 Nov 2015 03:44:50 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Xld3NJ6N X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ihu8Sy_c4Ouc; Mon, 2 Nov 2015 03:44:49 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 2 Nov 2015 03:44:49 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id 7E2F38008F; Sun, 1 Nov 2015 21:44:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1446432288; bh=PVF39+z5fK0NPxG1L8MjwT/+3/jxEFzf06rYiF4JCg0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Xld3NJ6NTNSVCuxUgQlml7GVh3a3QpLzWXgcWXw3cH5X+qMF7Luy79K+t1JyUqDBK Qf13/6H7MKVIURKiyj506rhPJqfjh829jpnmd/0PraRfmXrtFoP9cSEMq6Yw1jq5Rx +Hz8lCB1jtXAaMHQmNti0XwlFFhh95vk84Ectymc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tA22im2M017777; Sun, 1 Nov 2015 21:44:48 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 1 Nov 2015 21:44:48 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> Message-ID: References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> User-Agent: Alpine 2.20 (LFD 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 WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 02:44:54 -0000 On Mon, 2 Nov 2015, Yoav Nir wrote: > P.S. Someone’s asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. I’m wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. We should have text to clarify the difference of algorithm use in IKE/IPsec and in AUTH processing. Initial thought is that AUTH processing crypto restrictions don't beling in 4307bis. Paul From nobody Sun Nov 1 19:22:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231821B326E for ; Sun, 1 Nov 2015 19:22:03 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoOtFfcmpxzH for ; Sun, 1 Nov 2015 19:22:01 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 B0E451B326F for ; Sun, 1 Nov 2015 19:22:01 -0800 (PST) Received: by pasz6 with SMTP id z6so133632403pas.2 for ; Sun, 01 Nov 2015 19:22:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iu/zl/MdugG2MxzROZ2vYrcIBzEeDCFdxLI6kYtr8cQ=; b=XZQBzimp58a3MGvlTgxwDgCPyyPMcYaDedccuM1NTKfTFDPdGI1UjGhOot3CuMcVMU Ycpps3QlIGh5nuGRVxdLcJY8myigm0SM1kW784Isp/r+svlGT8uYz+bkpD9NnpM4Odcg 3uySlFynBB3+XGUgEWLhr1T63gUpX4bFGGqt/iSxc36oHrs6UzV01DTDNXkXRAz2dXjK /2Viyd53VDPjxBSD/AL0qSSnQ0ISXOBe/Wc05LFm5lxV5ypImIOkp6vuAj0LLZ+NDzPM Wvd2hUWR5r1eK+ktrpk5kqmcQVdAXI5NwUUtj7SfpZU5X8QdwqW1Hfs8igWPMgStznZO 4yAA== X-Received: by 10.66.124.165 with SMTP id mj5mr24014173pab.58.1446434521446; Sun, 01 Nov 2015 19:22:01 -0800 (PST) Received: from t20010c400000302461c962c009e4ded2.v6.meeting.ietf94.jp (t20010c400000302461c962c009e4ded2.v6.meeting.ietf94.jp. [2001:c40:0:3024:61c9:62c0:9e4:ded2]) by smtp.gmail.com with ESMTPSA id cn4sm20764343pbc.94.2015.11.01.19.21.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 19:22:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Mon, 2 Nov 2015 12:21:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:22:03 -0000 > On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >=20 > On Mon, 2 Nov 2015, Yoav Nir wrote: >=20 >> P.S. Someone=E2=80=99s asked me off-list whether there is any IPsecME = document that says not to trust SHA-1 in signatures, both AUTH payload = and certificates, the way the TLS 1.3 document may end up saying for = TLS. I=E2=80=99m wondering if RFC4307bis might be the place for this, in = particular the signature in AUTH payload. Just something to think about = before we bikeshed.RFC4307bis Bikeshedding Session. >=20 > We should have text to clarify the difference of algorithm use in > IKE/IPsec and in AUTH processing. Initial thought is that AUTH > processing crypto restrictions don't beling in 4307bis. I think we do need some kind of statement along the lines: - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says = =E2=80=9CSHOULD use SHA-1=E2=80=9D and this is a document from only last = year=E2=80=A6) - Don=E2=80=99t use DSS because that is only defined with SHA-1. - With ECDSA no need to specify because each curve comes with a hash - PSK is fine because you are using a PRF. - With anything else, don=E2=80=99t use any hash weaker than SHA-256. If not here, where does this advice go? Yoav From nobody Sun Nov 1 19:27:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611E11B32A8 for ; Sun, 1 Nov 2015 19:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUDYQm3hYjDa for ; Sun, 1 Nov 2015 19:27:44 -0800 (PST) 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 131AB1B32A7 for ; Sun, 1 Nov 2015 19:27:44 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nq0722RPcz36j; Mon, 2 Nov 2015 04:27:42 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=SEOB4wM/ X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id hJMqDtOjKtqX; Mon, 2 Nov 2015 04:27:41 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 2 Nov 2015 04:27:41 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPS id 7793580061; Sun, 1 Nov 2015 22:27:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1446434860; bh=kSnpscv2E013X8lqDyhLNUyf1/ewIM8PJH3l1nZedbI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SEOB4wM/E8vrnG6e+RnGcHbxEMNrU9GKnL2xYeRk5JKCYUHkC1gow9giZJG1BKNQQ TwOMSB4EJ4jAhQiadbtltpxhBIN6j7y2RRItH26l98ybVXwQK2Rr9qzV5z7yXi2ef3 hdFgcfQ7P2bCfFna7KKXVoKczDdmQcKDj7CZG2Bk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tA23Reki019140; Sun, 1 Nov 2015 22:27:40 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 1 Nov 2015 22:27:40 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> Message-ID: References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> User-Agent: Alpine 2.20 (LFD 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 WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:27:45 -0000 On Mon, 2 Nov 2015, Yoav Nir wrote: >>> P.S. Someone’s asked me off-list whether there is any IPsecME document that says not to trust SHA-1 in signatures, both AUTH payload and certificates, the way the TLS 1.3 document may end up saying for TLS. I’m wondering if RFC4307bis might be the place for this, in particular the signature in AUTH payload. Just something to think about before we bikeshed.RFC4307bis Bikeshedding Session. >> >> We should have text to clarify the difference of algorithm use in >> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >> processing crypto restrictions don't beling in 4307bis. > > I think we do need some kind of statement along the lines: > - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says “SHOULD use SHA-1” and this is a document from only last year…) > - Don’t use DSS because that is only defined with SHA-1. > - With ECDSA no need to specify because each curve comes with a hash > - PSK is fine because you are using a PRF. > - With anything else, don’t use any hash weaker than SHA-256. > > If not here, where does this advice go? I see your point. But for instance for X509 certificates, I really would like to not make any statement and point to whatever equivalent of PKIX documents there are on that. Does the TLS WG have any documents on crypto agility for PKIX? Paul From nobody Sun Nov 1 19:38:19 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A531ACE96 for ; Sun, 1 Nov 2015 19:38:18 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3CI6Pvbl9xs for ; Sun, 1 Nov 2015 19:38:16 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 9D25B1ACEBE for ; Sun, 1 Nov 2015 19:38:16 -0800 (PST) Received: by pabfh17 with SMTP id fh17so10038258pab.0 for ; Sun, 01 Nov 2015 19:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tTbh4ZVXXA39gcCh20oleomhXAVnunA8vTk6Tc6K8Rk=; b=ryB4XxeZrnM7S1yUNkWuJUre13tlbsGhp0m1Vrnli9xMr4Kknn66V/0M71SlEtXMo8 xM8qJZgW4ft1cCpHDQA0RUhbKWxXAhYNiE706dNo3Go6pLBP6EC70/ysyEE8bUOsdOh5 KCC0DV8PrzUPT1RA/ZEUwvUZ6rb8WUtIxldizgUM6rmSy8SPE7b5poIFJ3ofUGpCv+yU K5fHFfZ+7VB6H4zL9CFL94GtK6ZU3IUqPF4AW4vQeoqg7hAcph5ygOX4wpRioEtgzDOA RYo1CeCdnXP7c9YCXWDxrVFWn4grDWRTY86IhNLX9HrQgcKFz7PuOqWKW6lWJsY0ED9L JcrA== X-Received: by 10.66.242.138 with SMTP id wq10mr24492490pac.2.1446435496345; Sun, 01 Nov 2015 19:38:16 -0800 (PST) Received: from t20010c400000302461c962c009e4ded2.v6.meeting.ietf94.jp (t20010c400000302461c962c009e4ded2.v6.meeting.ietf94.jp. [2001:c40:0:3024:61c9:62c0:9e4:ded2]) by smtp.gmail.com with ESMTPSA id ea5sm20816393pbc.92.2015.11.01.19.38.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 19:38:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Mon, 2 Nov 2015 12:38:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:38:18 -0000 > On 2 Nov 2015, at 12:27 PM, Paul Wouters wrote: >=20 > On Mon, 2 Nov 2015, Yoav Nir wrote: >=20 >>>> P.S. Someone=E2=80=99s asked me off-list whether there is any = IPsecME document that says not to trust SHA-1 in signatures, both AUTH = payload and certificates, the way the TLS 1.3 document may end up saying = for TLS. I=E2=80=99m wondering if RFC4307bis might be the place for = this, in particular the signature in AUTH payload. Just something to = think about before we bikeshed.RFC4307bis Bikeshedding Session. >>>=20 >>> We should have text to clarify the difference of algorithm use in >>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >>> processing crypto restrictions don't beling in 4307bis. >>=20 >> I think we do need some kind of statement along the lines: >> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 = says =E2=80=9CSHOULD use SHA-1=E2=80=9D and this is a document from only = last year=E2=80=A6) >> - Don=E2=80=99t use DSS because that is only defined with SHA-1. >> - With ECDSA no need to specify because each curve comes with a hash >> - PSK is fine because you are using a PRF. >> - With anything else, don=E2=80=99t use any hash weaker than SHA-256. >>=20 >> If not here, where does this advice go? >=20 > I see your point. But for instance for X509 certificates, I really = would > like to not make any statement and point to whatever equivalent of = PKIX > documents there are on that. Does the TLS WG have any documents on > crypto agility for PKIX? The TLS list currently has a thread about whether TLS 1.3 should = prohibit SHA-1 only in signatures or also in the certificate chain.=20 It=E2=80=99s not decided yet, but they *are* prohibiting SHA-1 in the = protocol (CertificateVerify message), and current spec prohibits server = certificate signed with SHA-1 (only EE certificate) when another = certificate exists. Yoav From nobody Sun Nov 1 19:44:30 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020BD1AD0B1 for ; Sun, 1 Nov 2015 19:44:29 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urJQxjR-yCxM for ; Sun, 1 Nov 2015 19:44:27 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 316951AD0B0 for ; Sun, 1 Nov 2015 19:44:27 -0800 (PST) Received: by padec8 with SMTP id ec8so25067028pad.1 for ; Sun, 01 Nov 2015 19:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JibUOMtD++1e6QaXXmWv30ZcsHurp+/dKuZ0QuffyrA=; b=zE05czZ1O+xdfh4FmvovDvbOICcR4hPuHCeS3x68xYDqxzQaM5sPZnTdZWJtCdJKNV 1nOIzWhNJZuvAsXoHRAWwksStXXnf/h017bbmAFT/9l/6JM1FTufUOv4HCcTIhp1AM0/ UZBSa2dW2Bu9eyMdXxkihhIL1ngx2m205biRQ/hbwhDUxtQghwMZJxZ4QMvqpToiHmR9 OFvdOJv6YtZIYZIcwWuskT5u9IJWhy440X/hlo7qSW4VH7Kx/5VJNvM7WTW2822CK/pU EQ3mOt5pSi/u+nWVFd9KBCEJ0ME7CYWk5RoZX3ZQv3qfKquX8vH9jsv31UJW42WcYud5 bXiA== X-Received: by 10.68.217.41 with SMTP id ov9mr24686209pbc.118.1446435866719; Sun, 01 Nov 2015 19:44:26 -0800 (PST) Received: from t20010c400000302461c962c009e4ded2.v6.meeting.ietf94.jp (t20010c400000302461c962c009e4ded2.v6.meeting.ietf94.jp. [2001:c40:0:3024:61c9:62c0:9e4:ded2]) by smtp.gmail.com with ESMTPSA id by6sm20968408pab.25.2015.11.01.19.44.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Nov 2015 19:44:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Mon, 2 Nov 2015 12:44:22 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <35385DF3-0A02-449F-91A5-4A70F801C9C6@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:44:29 -0000 Forgot the link=E2=80=A6 > On 2 Nov 2015, at 12:38 PM, Yoav Nir wrote: >=20 >=20 >> On 2 Nov 2015, at 12:27 PM, Paul Wouters wrote: >>=20 >> On Mon, 2 Nov 2015, Yoav Nir wrote: >>=20 >>>>> P.S. Someone=E2=80=99s asked me off-list whether there is any = IPsecME document that says not to trust SHA-1 in signatures, both AUTH = payload and certificates, the way the TLS 1.3 document may end up saying = for TLS. I=E2=80=99m wondering if RFC4307bis might be the place for = this, in particular the signature in AUTH payload. Just something to = think about before we bikeshed.RFC4307bis Bikeshedding Session. >>>>=20 >>>> We should have text to clarify the difference of algorithm use in >>>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >>>> processing crypto restrictions don't beling in 4307bis. >>>=20 >>> I think we do need some kind of statement along the lines: >>> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 = says =E2=80=9CSHOULD use SHA-1=E2=80=9D and this is a document from only = last year=E2=80=A6) >>> - Don=E2=80=99t use DSS because that is only defined with SHA-1. >>> - With ECDSA no need to specify because each curve comes with a hash >>> - PSK is fine because you are using a PRF. >>> - With anything else, don=E2=80=99t use any hash weaker than = SHA-256. >>>=20 >>> If not here, where does this advice go? >>=20 >> I see your point. But for instance for X509 certificates, I really = would >> like to not make any statement and point to whatever equivalent of = PKIX >> documents there are on that. Does the TLS WG have any documents on >> crypto agility for PKIX? >=20 > The TLS list currently has a thread about whether TLS 1.3 should = prohibit SHA-1 only in signatures or also in the certificate chain.=20 = https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E >=20 > It=E2=80=99s not decided yet, but they *are* prohibiting SHA-1 in the = protocol (CertificateVerify message), and current spec prohibits server = certificate signed with SHA-1 (only EE certificate) when another = certificate exists. >=20 > Yoav >=20 From nobody Mon Nov 2 01:32:49 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863041B35AC for ; Mon, 2 Nov 2015 01:32:48 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaWzxXg5Tvv7 for ; Mon, 2 Nov 2015 01:32:47 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 D981C1B35A8 for ; Mon, 2 Nov 2015 01:32:46 -0800 (PST) Received: by obbwb3 with SMTP id wb3so90601321obb.0 for ; Mon, 02 Nov 2015 01:32:46 -0800 (PST) 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-type:content-transfer-encoding; bh=NPER4eHxVZQHIT5T/mXUspxKkoOf7xjFWfjSxbIfnbA=; b=FynVwux/rq9J5HLs8XMlCS1a79LyAvONTshSVHhWgmtmVWHhonCRo4ghMnuhRGY7I+ C4CVwYCgsm8/LjSdpAVCx/xDRlTsJgpGN/g7eE9eOY/uK4Sp0Amz63hC3s7hnxf9vtC5 WMTC68Sh3FRS2FDhHIngQQaEy0g5rEJrRPJw5Dn6WnRT02R3jbtUuZEAq+R6/7cqV91w meAfKKbx7nFln5i/w5mep2S1OsaOpKjQlcLLAMYdIdFgwFzO5b+RVypn9ENuXQeibuM7 tPfGwTywx3dP2d7bh73sLvkU0hSTeLxyZtNH31OAPSBurBdhNitpzQmb9Be0o/03FvAw fWvA== X-Received: by 10.60.165.72 with SMTP id yw8mr13213809oeb.45.1446456766303; Mon, 02 Nov 2015 01:32:46 -0800 (PST) Received: from [172.18.133.40] (cowboy.intuit.com. [65.204.229.11]) by smtp.googlemail.com with ESMTPSA id r65sm8608824oif.7.2015.11.02.01.32.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 01:32:44 -0800 (PST) To: Yoav Nir , Paul Wouters References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> <35385DF3-0A02-449F-91A5-4A70F801C9C6@gmail.com> From: Yaron Sheffer Message-ID: <56372DB8.5040508@gmail.com> Date: Mon, 2 Nov 2015 11:32:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <35385DF3-0A02-449F-91A5-4A70F801C9C6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 09:32:48 -0000 >>>> If not here, where does this advice go? >>> >>> I see your point. But for instance for X509 certificates, I really would >>> like to not make any statement and point to whatever equivalent of PKIX >>> documents there are on that. Does the TLS WG have any documents on >>> crypto agility for PKIX? >> >> The TLS list currently has a thread about whether TLS 1.3 should prohibit SHA-1 only in signatures or also in the certificate chain. > > https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E >> >> It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol (CertificateVerify message), and current spec prohibits server certificate signed with SHA-1 (only EE certificate) when another certificate exists. >> For TLS, the industry is moving faster than the WG on this. Chrome warnings are causing people to migrate to all-SHA256 certificate chains soon. IKE often works with custom certs and private CAs, so the IPsec community needs to set its own standards. Thanks, Yaron From nobody Mon Nov 2 01:43:02 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515111A0053 for ; Mon, 2 Nov 2015 01:43:01 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7HdHSKcVTlq for ; Mon, 2 Nov 2015 01:42:59 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 A90FD1A01FC for ; Mon, 2 Nov 2015 01:42:59 -0800 (PST) Received: by padec8 with SMTP id ec8so35048395pad.1 for ; Mon, 02 Nov 2015 01:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j7WRerNntpeWKXOa2kDoxgRJyJLIXZz0MWmzkEl2kf0=; b=ykFLZstHk/FtxxrYPnduY/ZP5Hb4Ekrmt6i8Ds4HVJszp/Mjg8fTKOnIBWDEOhZuie mBt4244sCJmuz5Ah2XHzg+XDRFecb34VXPcm3MpbA7O/5zGhFgFgJBJ/T857f05NQmSG q1MbUyYjygg6/EnfVhTWi+hTWQjeAe25tmFqqTJeiZzKpVItaKiWbJ3kT5+hKlIEZEav 7u6tQM24rzh7l9F2dISYlgKi13mrWVEanMdO+KH1/hZYirdVw1Y9j7rQlgfI5FrQ3AI/ XggEOxj+mPXJiONtajiuwMwAvDd6e1Eja7J+rLCFKOz9CPem+9Agwwf4/Qod8pKlAJly D9mg== X-Received: by 10.68.163.195 with SMTP id yk3mr25885114pbb.120.1446457379406; Mon, 02 Nov 2015 01:42:59 -0800 (PST) Received: from dhcp-24-150.meeting.ietf94.jp ([133.93.24.150]) by smtp.gmail.com with ESMTPSA id bc2sm22948469pbd.2.2015.11.02.01.42.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 01:42:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <56372DB8.5040508@gmail.com> Date: Mon, 2 Nov 2015 18:42:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <18582120-C952-4420-B7B1-69B927F8CE8B@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> <35385DF3-0A02-449F-91A5-4A70F801C9C6@gmail.com> <56372DB8.5040508@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 09:43:01 -0000 > On 2 Nov 2015, at 6:32 PM, Yaron Sheffer = wrote: >=20 >>>>> If not here, where does this advice go? >>>>=20 >>>> I see your point. But for instance for X509 certificates, I really = would >>>> like to not make any statement and point to whatever equivalent of = PKIX >>>> documents there are on that. Does the TLS WG have any documents on >>>> crypto agility for PKIX? >>>=20 >>> The TLS list currently has a thread about whether TLS 1.3 should = prohibit SHA-1 only in signatures or also in the certificate chain. >>=20 >> = https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E >>>=20 >>> It=E2=80=99s not decided yet, but they *are* prohibiting SHA-1 in = the protocol (CertificateVerify message), and current spec prohibits = server certificate signed with SHA-1 (only EE certificate) when another = certificate exists. >>>=20 >=20 > For TLS, the industry is moving faster than the WG on this. Chrome = warnings are causing people to migrate to all-SHA256 certificate chains = soon. IKE often works with custom certs and private CAs, so the IPsec = community needs to set its own standards. Chrome is both a TLS implementation and a PKIX relying party. The = question there is not whether signing intermediate certificates with = SHA-1 is good or bad. It=E2=80=99s definitely bad. These chains ought to = be rejected. The only question is whether such advice belongs in the TLS = spec or some PKIX document (tentatively named =E2=80=9CSHA-1 die, die, = die=E2=80=9D) As for IKE, yes we often work with private CAs, but if those CAs sign = certificates with SHA-1, it would make it as easy to forge as if they = were public CAs. Issuance usually involves generating a certificate = request and running an enrollment protocol, no matter how many layers of = pretty purple GUI my employer hides this under. So if your private CA signs with SHA-1, it should be modified to sign = with something better, just as it should have been modified to issue = certificates with 2048-bit RSA rather than 1024-bit. Just like TLS, we = can specify requirements on the certificates in an IPsecME spec, or we = can rely on PKIX best practices. But what algorithm is used in the AUTH = payload? That=E2=80=99s entirely up to us. Yoav From nobody Mon Nov 2 06:35:39 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2E1B373F for ; Mon, 2 Nov 2015 06:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oFKsCvRLnWP for ; Mon, 2 Nov 2015 06:35:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8934A1B2C94 for ; Mon, 2 Nov 2015 06:35:36 -0800 (PST) X-AuditID: c1b4fb2d-f79626d000004282-8b-563774b60f9d Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.87.17026.6B477365; Mon, 2 Nov 2015 15:35:34 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.39]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 15:35:34 +0100 From: John Mattsson To: "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt Thread-Index: AQHRFXu7qgXgtELg9k6Y0s/OKlhTiQ== Date: Mon, 2 Nov 2015 14:35:33 +0000 Message-ID: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <3895668F6FF74E419F981A44AE08DE1D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvre62EvMwg74NRhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoPjL9kKlolVfPg5m62B8Y5oFyMHh4SAicTkf2ldjJxAppjE hXvr2boYuTiEBI4wSlw4cBvKWcQo0XW6mR2kik3AQGLungY2EFtEQFXi1LLprCC2sICrxLee fnaIuJvEwiVTWSBsPYmpRy8wgdgsAioSbbtfMoLYvAL2Ehtf/wGrYQTa/P3UGrAaZgFxiVtP 5jNBXCQgsWTPeWYIW1Ti5eN/rBC2ksSK7ZcYQR5gFtCUWL9LH6LVWmLd2TksELaixJTuh+wQ qwQlTs58wjKBUWQWkg2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjEC4+Hglt+6OxhXv3Y8xCjAwajEw2uQaBYmxJpYVlyZe4hRgoNZSYT3WZ55mBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXHeFqYHoUIC6YklqdmpqQWpRTBZJg5OqQZGg33BC3aa6Uyttzlvl5T4 5kPNj6UyU/l3ih4PXfBz0i3V8hjJOJmlyyrlWWUOJjlWrP0kfS/rVsB0w/ySzPPdVx9O+7TQ v+Gyrf+xTTLLNONbvP2PWvRMzMt2mHtpf9e9v/EXG7h6Vud5Zpf79CvL3jhXWDP5ZvzZpWsW LQ69o3fsz70HE3YcV2Ipzkg01GIuKk4EAMyjI12DAgAA Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 14:35:38 -0000 U29tZSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWlwc2VjbWUtcmZjNDMwN2Jpcy0wMA0KDQpJbiBn ZW5lcmFsLCB2ZXJ5IGdvb2QgYW5kIHZlcnkgbmVlZGVkLg0KDQoNCi0gQWJzdHJhY3Qgc2F5czoN CuKAnFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgY3VycmVudCBzZXQgb2YgYWxnb3JpdGhtcyB0 aGF0IGFyZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGFzIHBhcnQgb2YgSUtFdjIsIGFzIHdlbGwg YXMgYWxnb3JpdGhtcyB0aGF0IHNob3VsZCBiZSBpbXBsZW1lbnRlZCBiZWNhdXNlIHRoZXkgbWF5 IGJlIHByb21vdGVkIHRvIG1hbmRhdG9yeSBhdCBzb21lIGZ1dHVyZSB0aW1lLuKAnQ0KDQpUaGUg aW50cm9kdWN0aW9uIGFsc28gb25seSB0YWxrcyBhYm91dCBNVEkgYW5kIGJlbGlldmVkIHRvIGJl IGZ1dHVyZSBNVEkuIEVOQ1JfREVTIGRvZXMgbm90IGZpdCBpbiBlaXRoZXIgb2YgdGhlc2UgY2F0 ZWdvcmllcy4gSSBhbSBhbGwgZm9yIHNwZWNpZnlpbmcgTVVTVCBOT1QgZm9yIHN1Y2ggYWxnb3Jp dGhtcywgYnV0IHRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIHNob3VsZCBiZSB1cGRhdGVk Lg0KDQoNCi0gQlRXLCBXaGF0IGRvZXMgaXQgbWVhbiB0aGF0IGFuIGFsZ29yaXRobSBsaWtlIEVO Q1JfUkM1IGlzIG5vdCBsaXN0ZWQsIGRvZXMgdGhhdCBtZWFuIOKAnE1BWeKAnSwg4oCcTVVTVCBO T1TigJ0sIG9yIOKAnHRvdGFsbHkgdW5zcGVjaWZpZWTigJ0/DQoNCg0KLSBTZWN0aW9uIDMuMi4g c2F5cyDigJxXaGVuIGFuIEFFQUQgYWxnb3JpdGhtIChzZWUgU2VjdGlvbiAzLjEpIGlzIHVzZWQs IG5vIGFsZ29yaXRobSBmcm9tIHRoaXMgdGFibGUgbmVlZHMgdG8gYmUgdXNlZC7igJ0gU2hvdWxk buKAmXQgdGhpcyBiZSDigJxNVVNUIE5PVCBiZSB1c2Vk4oCdLg0KDQoNCi0gU2VjdGlvbiAzLjEu IEkgdGhpbmsgQUVTX0NDTV84IHNob3VsZCBzb21laG93IGJlIHJlc3RyaWN0ZWQgdG8gSW9ULCBh cyB1c2luZyA2NCBiaXQgdGFncyBpbiBJS0UgZG9lcyBub3Qgc291bmQgbGlrZSBnZW5lcmFsIGdv b2QgYWR2aXNlLiBBbHNvIElvVCBpbXBsZW1lbnRhdGlvbnMgd291bGQgcHJvYmFibHkganVzdCBp bXBsZW1lbnQg4oCcRU5DUl9BRVNfQ0NNXzjigJ0sIOKAnFBSRl9ITUFDX1NIQTJfMjU2IiwgYW5k ICIyNTYtYml0IHJhbmRvbSBFQ1AgZ3JvdXAiIGFuZCBza2lwIGV2ZXJ5dGhpbmcgZWxzZS4gSXQg c2VlbSB0byBtYWtlIG1vcmUgc2Vuc2UgdG8gc3BlY2lmeSBhbiBJb1QgcHJvZmlsZSBpbiBhIHNl cGFyYXRlIHNlY3Rpb24uDQoNCg0KLSBTZWN0aW9uIDMuNC4gVGhlIERpZmZpZS1IZWxsbWFuIGdy b3VwIHRhYmxlIGRpdmVyZ2VzIGhlYXZpbHkgZnJvbSB0aGUgcmVzdCB3aXRoIG9ubHkgMTEyLWJp dCBzZWN1cml0eSBhcyBNVVNULCBhbmQgbm8gZ3JvdXAgb2ZmZXJpbmcgMTI4LWJpdCBzZWN1cml0 eSBhcyBldmVuIFNIT1VMRCsuIFRoaXMgbWF5IGJlIG9rLCBidXQgSSB0aGluayB0aGUgaXBzZWNt ZSBncm91cCBzaG91bGQgdHJ5IHRvIGZ1bGZpbGwgZ2VuZXJhbCByZWNvbW1lbmRhdGlvbnMgb24g c2VjdXJpdHkgbGV2ZWxzIChOSVNULCBFQ1JZUFQpIGFuZCBoYXZlIGEgcGxhbiBvbiBob3cgdG8g bWFrZSAyMDQ4LWJpdCBNT1BEIGEgTVVTVCBOT1QgYmVmb3JlIDIwMzAuIE5vdCBiZWluZyBhYmxl IHRvIGZvcmJpZCAxMDI0LWJpdCBNT1BEIGlzIHRoaXMgZHJhZnQgaXMgYSBmYWlsdXJlLCBsZXTi gJlzIG5vdCByZXBlYXQgaXQuDQoNCg0KLSBBdCBsZWFzdCDigJxBRVMtWENCQy1QUkYtMTI44oCd IGFuZCDigJwyNTYtYml0IHJhbmRvbSBFQ1AgZ3JvdXDigJ0gc2hvdWxkIGhhdmUgcmVmZXJlbmNl cyB0byBwb2ludCBvdXQgd2hpY2ggb2YgdGhlIFJGQ3MgdGhhdCBhcmUgTVRJLg0KDQoNCkNoZWVy cywNCkpvaG4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSm9obiBN YXR0c3Nvbg0KTVNjIEVuZ2luZWVyaW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJh dGlvbiBhbmQgRWNvbm9taWNzDQpFcmljc3NvbiBJRVRGIFNlY3VyaXR5IENvb3JkaW5hdG9yIA0K U2VuaW9yIFJlc2VhcmNoZXIsIFNlY3VyaXR5DQoNCg== From nobody Mon Nov 2 16:42:09 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3411AC39E for ; Mon, 2 Nov 2015 16:42:08 -0800 (PST) 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 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 omREAOBjBbqe for ; Mon, 2 Nov 2015 16:42:06 -0800 (PST) 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 16F481AC39F for ; Mon, 2 Nov 2015 16:42:05 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tA30g1ZK007678 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2015 02:42:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tA30g1fe026390; Tue, 3 Nov 2015 02:42:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22072.729.246850.109764@fireball.acr.fi> Date: Tue, 3 Nov 2015 02:42:01 +0200 From: Tero Kivinen To: John Mattsson In-Reply-To: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 25 min Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 00:42:08 -0000 John Mattsson writes: > - BTW, What does it mean that an algorithm like ENCR=5FRC5 is not > listed, does that mean =E2=80=9CMAY=E2=80=9D, =E2=80=9CMUST NOT=E2=80= =9D, or =E2=80=9Ctotally unspecified=E2=80=9D=3F It means this document does not specify whether they should be used or not, i.e. MAY. > - Section 3.2. says =E2=80=9CWhen an AEAD algorithm (see Section 3.1)= is > used, no algorithm from this table needs to be used.=E2=80=9D Shouldn= =E2=80=99t this > be =E2=80=9CMUST NOT be used=E2=80=9D. This document just states the fact, the actual MUST NOT is in the RFC5282, and I do not think we should repeat that here. I.e. this text just states the fact of life based on the RFC5282, but does not make any requirements.=20 > - Section 3.1. I think AES=5FCCM=5F8 should somehow be restricted to > IoT, as using 64 bit tags in IKE does not sound like general good > advise. Also IoT implementations would probably just implement > =E2=80=9CENCR=5FAES=5FCCM=5F8=E2=80=9D, =E2=80=9CPRF=5FHMAC=5FSHA2=5F= 256", and "256-bit random ECP > group" and skip everything else. It seem to make more sense to > specify an IoT profile in a separate section. The IoT devices talk to each other, but also to more general purpose servers, i.e., in your home you might have some kind home area network server, where all the IoT devices connect to. In that case those bigger boxes do want to implement the same AES=5FCCM=5F8 just so that those IoT devices which didn't implement anything else can talk to them. I.e. I think it is good thing to require real systems to have SHOULD for the AES=5FCCM=5F8. Of couse if your implementation is never expecte= d to talk to IoT devices, then that is good reason to go against the SHOULD and leave the AES=5FCCM=5F8 implementation out. > - Section 3.4. The Diffie-Hellman group table diverges heavily from > the rest with only 112-bit security as MUST, and no group offering > 128-bit security as even SHOULD+. That depends how you calculate the securities of the Diffie-Hellman groups. If you check RFC3526 that gives two strengh estimates for 2014-bit group, 110 and 160 bits. The 160 bit strength takes also account the memory prices in the calculations, the 110 assumes memory is free, and CPU cost is only thing that matters.=20 > This may be ok, but I think the ipsecme group should try to fulfill > general recommendations on security levels (NIST, ECRYPT) and have a > plan on how to make 2048-bit MOPD a MUST NOT before 2030. I think we are going to replace this document several times before 2030. We actually should have replaced this already few years ago, so this update is already bit late, but I would assume we might make new version after we get those new EC groups now being defined to the implementations. On the other hand there are lots of people still running IKEv1, so getting them to implementations might get time. > Not being able to forbid 1024-bit MOPD is this draft is a failure, > let=E2=80=99s not repeat it. We should move it to MUST NOT in next update, and then we can also revisit the discussion of 2048-bit MODP group.=20 --=20 kivinen@iki.fi From nobody Mon Nov 2 17:43:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082651B2B58 for ; Mon, 2 Nov 2015 17:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgGpl6U3Td1N for ; Mon, 2 Nov 2015 17:43:42 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674731B2B57 for ; Mon, 2 Nov 2015 17:43:41 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-ed-5638114bfa46 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.65.29154.B4118365; Tue, 3 Nov 2015 02:43:39 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.39]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 02:43:30 +0100 From: John Mattsson To: Tero Kivinen Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt Thread-Index: AQHRFXu7qgXgtELg9k6Y0s/OKlhTiZ6JZSyAgACoCoA= Date: Tue, 3 Nov 2015 01:43:29 +0000 Message-ID: References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> <22072.729.246850.109764@fireball.acr.fi> In-Reply-To: <22072.729.246850.109764@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7q663oEWYwcU7shb7t7xgszh6/jmb A5PHkiU/mTwOf13IEsAUxWWTkpqTWZZapG+XwJVx5fxZtoI+9YoLN7awNzD2qHUxcnJICJhI dD9vYoWwxSQu3FvP1sXIxSEkcJhRouPGUkYIZxGjxKEJu9hBqtgEDCTm7mlgA7FFBBQldj/Z ygRiMwuoStzdPxVskrCAq8S3nn52iBo3iYVLprJ0MXIA2VYSW464gYRZBFQk9rbuAWvlFTCX WPcApIQTaFe2xK1p38BsTgEziVfrFjGD2IxAx30/tQZqlbjErSfzmSCOFpBYsuc8M4QtKvHy 8T9WkFWiAnoSe5ZLQoSVJFZsv8QIEmYW0JRYv0sfYoq1xOMna1khbEWJKd0P2SGuEZQ4OfMJ ywRGiVlIls1C6J6FpHsWku5ZSLoXMLKuYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMwINb flvtYDz43PEQowAHoxIP74ZN5mFCrIllxZW5hxglOJiVRHhfclmECfGmJFZWpRblxxeV5qQW H2KU5mBREudtZnoQKiSQnliSmp2aWpBaBJNl4uCUamCMyTU5n6F+Otzhn9/Jsxq2Nvb/itrC n/9etLk6/vKDGj/byF0PGkVOzQhr+XOj97KgR8vnmd8aZNxEeGc4rFRbGCzTHF1+oN74oLmU waN5Bd/Ovq4pC7aO5Jxfuang3tyNcvfDk39LK4rmZr3eLDizvfA2L/NKaUa+0zN81v+2fXDh /uOfJ3OVWIozEg21mIuKEwFHyzZgvAIAAA== Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:43:44 -0000 T24gMDMvMTEvMTUgMDk6NDIsICJUZXJvIEtpdmluZW4iIDxraXZpbmVuQGlraS5maT4gd3JvdGU6 DQoNCg0KPj4tIFNlY3Rpb24gMy4yLiBzYXlzIOKAnFdoZW4gYW4gQUVBRCBhbGdvcml0aG0gKHNl ZSBTZWN0aW9uIDMuMSkgaXMNCj4+IHVzZWQsIG5vIGFsZ29yaXRobSBmcm9tIHRoaXMgdGFibGUg bmVlZHMgdG8gYmUgdXNlZC7igJ0gU2hvdWxkbuKAmXQgdGhpcw0KPj4gYmUg4oCcTVVTVCBOT1Qg YmUgdXNlZOKAnS4NCj4NCj5UaGlzIGRvY3VtZW50IGp1c3Qgc3RhdGVzIHRoZSBmYWN0LCB0aGUg YWN0dWFsIE1VU1QgTk9UIGlzIGluIHRoZQ0KPlJGQzUyODIsIGFuZCBJIGRvIG5vdCB0aGluayB3 ZSBzaG91bGQgcmVwZWF0IHRoYXQgaGVyZS4gSS5lLiB0aGlzIHRleHQNCj5qdXN0IHN0YXRlcyB0 aGUgZmFjdCBvZiBsaWZlIGJhc2VkIG9uIHRoZSBSRkM1MjgyLCBidXQgZG9lcyBub3QgbWFrZQ0K PmFueSByZXF1aXJlbWVudHMuDQoNClRoZW4geW91IHNob3VsZCBwcm9iYWJseSByZW1vdmUgdGhl IOKAmE1VU1QnIGluICJBbGdvcml0aG1zIHRoYXQgYXJlIG5vdA0KQUVBRCBNVVNUIGJlIHVzZWQg aW4gY29uanVuY3Rpb24gd2l0aCB0aGUgaW50ZWdyaXR5IGFsZ29yaXRobXMgaW4gU2VjdGlvbg0K My4yLuKAnQ0KDQoNCj4+LSBTZWN0aW9uIDMuMS4gSSB0aGluayBBRVNfQ0NNXzggc2hvdWxkIHNv bWVob3cgYmUgcmVzdHJpY3RlZCB0bw0KPj4gSW9ULCBhcyB1c2luZyA2NCBiaXQgdGFncyBpbiBJ S0UgZG9lcyBub3Qgc291bmQgbGlrZSBnZW5lcmFsIGdvb2QNCj4+IGFkdmlzZS4gQWxzbyBJb1Qg aW1wbGVtZW50YXRpb25zIHdvdWxkIHByb2JhYmx5IGp1c3QgaW1wbGVtZW50DQo+PiDigJxFTkNS X0FFU19DQ01fOOKAnSwg4oCcUFJGX0hNQUNfU0hBMl8yNTYiLCBhbmQgIjI1Ni1iaXQgcmFuZG9t IEVDUA0KPj4gZ3JvdXAiIGFuZCBza2lwIGV2ZXJ5dGhpbmcgZWxzZS4gSXQgc2VlbSB0byBtYWtl IG1vcmUgc2Vuc2UgdG8NCj4+IHNwZWNpZnkgYW4gSW9UIHByb2ZpbGUgaW4gYSBzZXBhcmF0ZSBz ZWN0aW9uLg0KPg0KPlRoZSBJb1QgZGV2aWNlcyB0YWxrIHRvIGVhY2ggb3RoZXIsIGJ1dCBhbHNv IHRvIG1vcmUgZ2VuZXJhbCBwdXJwb3NlDQo+c2VydmVycywgaS5lLiwgaW4geW91ciBob21lIHlv dSBtaWdodCBoYXZlIHNvbWUga2luZCBob21lIGFyZWEgbmV0d29yaw0KPnNlcnZlciwgd2hlcmUg YWxsIHRoZSBJb1QgZGV2aWNlcyBjb25uZWN0IHRvLiBJbiB0aGF0IGNhc2UgdGhvc2UNCj5iaWdn ZXIgYm94ZXMgZG8gd2FudCB0byBpbXBsZW1lbnQgdGhlIHNhbWUgQUVTX0NDTV84IGp1c3Qgc28g dGhhdA0KPnRob3NlIElvVCBkZXZpY2VzIHdoaWNoIGRpZG4ndCBpbXBsZW1lbnQgYW55dGhpbmcg ZWxzZSBjYW4gdGFsayB0bw0KPnRoZW0uDQo+DQo+SS5lLiBJIHRoaW5rIGl0IGlzIGdvb2QgdGhp bmcgdG8gcmVxdWlyZSByZWFsIHN5c3RlbXMgdG8gaGF2ZSBTSE9VTEQNCj5mb3IgdGhlIEFFU19D Q01fOC4gT2YgY291c2UgaWYgeW91ciBpbXBsZW1lbnRhdGlvbiBpcyBuZXZlciBleHBlY3RlZA0K PnRvIHRhbGsgdG8gSW9UIGRldmljZXMsIHRoZW4gdGhhdCBpcyBnb29kIHJlYXNvbiB0byBnbyBh Z2FpbnN0IHRoZQ0KPlNIT1VMRCBhbmQgbGVhdmUgdGhlIEFFU19DQ01fOCBpbXBsZW1lbnRhdGlv biBvdXQuDQoNClRoYXQgc291bmQgcmVhc29uYWJsZSwgYnV0IHNob3VsZG7igJl0IHRoZSBJb1Qg ZGV2aWNlcyBoYXZlIHNvbWUgZ3VpZGVsaW5lcw0KKG1heWJlIGp1c3QgYSBzZW50ZW5jZSkgb24g d2hhdCB0aGV5IHNob3VsZCBpbXBsZW1lbnQ/IFdlIGtub3cgdGhhdCB0aGV5DQp3aWxsIG5vdCBp bXBsZW1lbnQgZXZlcnl0aGluZywgYW5kIGlmIHRoZXkgY2hvc2UgZGlmZmVyZW50IHN1YnNldHMs IHRoZXkNCndpbGwgbm90IGJlIGFibGUgdG8gdGFsayB0byBlYWNoIG90aGVyLg0KDQo+Pi0gU2Vj dGlvbiAzLjQuIFRoZSBEaWZmaWUtSGVsbG1hbiBncm91cCB0YWJsZSBkaXZlcmdlcyBoZWF2aWx5 IGZyb20NCj4+IHRoZSByZXN0IHdpdGggb25seSAxMTItYml0IHNlY3VyaXR5IGFzIE1VU1QsIGFu ZCBubyBncm91cCBvZmZlcmluZw0KPj4gMTI4LWJpdCBzZWN1cml0eSBhcyBldmVuIFNIT1VMRCsu DQo+DQo+VGhhdCBkZXBlbmRzIGhvdyB5b3UgY2FsY3VsYXRlIHRoZSBzZWN1cml0aWVzIG9mIHRo ZSBEaWZmaWUtSGVsbG1hbg0KPmdyb3Vwcy4gSWYgeW91IGNoZWNrIFJGQzM1MjYgdGhhdCBnaXZl cyB0d28gc3RyZW5naCBlc3RpbWF0ZXMgZm9yDQo+MjAxNC1iaXQgZ3JvdXAsIDExMCBhbmQgMTYw IGJpdHMuIFRoZSAxNjAgYml0IHN0cmVuZ3RoIHRha2VzIGFsc28NCj5hY2NvdW50IHRoZSBtZW1v cnkgcHJpY2VzIGluIHRoZSBjYWxjdWxhdGlvbnMsIHRoZSAxMTAgYXNzdW1lcyBtZW1vcnkNCj5p cyBmcmVlLCBhbmQgQ1BVIGNvc3QgaXMgb25seSB0aGluZyB0aGF0IG1hdHRlcnMuDQoNClRoZXJl IGlzIGFsc286DQotIExlbnN0cmEgKGh0dHA6Ly9pbmZvc2NpZW5jZS5lcGZsLmNoL3JlY29yZC8x NjQ1MzkvZmlsZXMvTlBERi0zMi5wZGYpDQpnaXZpbmcgdGhlIGVzdGltYXRlIDk1IGJpdCBzdHJl bmd0aA0KLSBUaGUgSUVURiBCQ1AgKFJGQzM3NjYpIGdpdmluZyB0aGUgZXN0aW1hdGUgMTAzIGJp dCBzdHJlbmd0aA0KLSBFQ1JZUFQgZ2l2aW5nIHRoZSBlc3RpbWF0ZSAxMDMgYml0IHN0cmVuZ3Ro DQoNClNvIGlmIGFueXRoaW5nLCBJIHdvdWxkIHNheSB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgaXMg dGhhdCAyMDQ4IE1PRFAgbWF5DQpub3QgZXZlbiBnaXZlIDExMiBiaXRzIHNlY3VyaXR54oCmDQoN Cj4+VGhpcyBtYXkgYmUgb2ssIGJ1dCBJIHRoaW5rIHRoZSBpcHNlY21lIGdyb3VwIHNob3VsZCB0 cnkgdG8gZnVsZmlsbA0KPj4gZ2VuZXJhbCByZWNvbW1lbmRhdGlvbnMgb24gc2VjdXJpdHkgbGV2 ZWxzIChOSVNULCBFQ1JZUFQpIGFuZCBoYXZlIGENCj4+IHBsYW4gb24gaG93IHRvIG1ha2UgMjA0 OC1iaXQgTU9QRCBhIE1VU1QgTk9UIGJlZm9yZSAyMDMwLg0KPg0KPkkgdGhpbmsgd2UgYXJlIGdv aW5nIHRvIHJlcGxhY2UgdGhpcyBkb2N1bWVudCBzZXZlcmFsIHRpbWVzIGJlZm9yZQ0KPjIwMzAu IFdlIGFjdHVhbGx5IHNob3VsZCBoYXZlIHJlcGxhY2VkIHRoaXMgYWxyZWFkeSBmZXcgeWVhcnMg YWdvLCBzbw0KPnRoaXMgdXBkYXRlIGlzIGFscmVhZHkgYml0IGxhdGUsIGJ1dCBJIHdvdWxkIGFz c3VtZSB3ZSBtaWdodCBtYWtlIG5ldw0KPnZlcnNpb24gYWZ0ZXIgd2UgZ2V0IHRob3NlIG5ldyBF QyBncm91cHMgbm93IGJlaW5nIGRlZmluZWQgdG8gdGhlDQo+aW1wbGVtZW50YXRpb25zLg0KDQpU aGF0IHNvdW5kcyByZWFsbHkgZ29vZC4gSXTigJlzIHZlcnkgaW1wb3J0YW50IHRoYXQgYm90aCB0 aGlzIGFuZCBSRkM3MzIxDQpnZXRzIHVwZGF0ZWQgcmVndWxhcmx5Lg0KDQo+IE9uIHRoZSBvdGhl ciBoYW5kIHRoZXJlIGFyZSBsb3RzIG9mIHBlb3BsZSBzdGlsbA0KPnJ1bm5pbmcgSUtFdjEsIHNv IGdldHRpbmcgdGhlbSB0byBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgZ2V0IHRpbWUuDQoNCkJ1dCBJ S0V2MSBpcyBub3QgaW4gc2NvcGUgZm9yIFJGQzQzMDcgb3IgUkZDNDMwN2JpcyBzbyB3aGF0IHRo ZXkgaW1wbGVtZW50DQpvciBub3Qgc2hvdWxkIG5vdCBiZSB0YWtlbiBpbnRvIGNvbnNpZGVyYXRp b24uDQoNCg0K From nobody Mon Nov 2 17:48:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F171B2B73 for ; Mon, 2 Nov 2015 17:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0ULfQuWWupK for ; Mon, 2 Nov 2015 17:48:28 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7D34F1B2B8F for ; Mon, 2 Nov 2015 17:48:26 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E057D10224008; Mon, 2 Nov 2015 17:48:25 -0800 (PST) Received: from 133.93.25.39 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 Nov 2015 17:48:26 -0800 (PST) Message-ID: <6284ffff9a7dfa007a9c3ef07f003166.squirrel@www.trepanning.net> In-Reply-To: <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> Date: Mon, 2 Nov 2015 17:48:26 -0800 (PST) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:48:31 -0000 On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: > >> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >> >> On Mon, 2 Nov 2015, Yoav Nir wrote: >> >>> P.S. Someone’s asked me off-list whether there is any IPsecME >>> document that says not to trust SHA-1 in signatures, both AUTH payload >>> and certificates, the way the TLS 1.3 document may end up saying for >>> TLS. I’m wondering if RFC4307bis might be the place for this, in >>> particular the signature in AUTH payload. Just something to think about >>> before we bikeshed.RFC4307bis Bikeshedding Session. >> >> We should have text to clarify the difference of algorithm use in >> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >> processing crypto restrictions don't beling in 4307bis. > > I think we do need some kind of statement along the lines: > - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says > “SHOULD use SHA-1” and this is a document from only last year…) > - Don’t use DSS because that is only defined with SHA-1. > - With ECDSA no need to specify because each curve comes with a hash Do you mean each _signature_ comes with a hash because you can use different hash algorithms to sign with any given curve. X9.62 in section 7.3, under Actions subsection e sub 1, even specifies what to do if the hash function used in the signature produces a digest that is greater than the length of the prime used in the curve definition-- namely, take the left-most length of prime bits of the digest to construct intermediate variable E. Dan. > - PSK is fine because you are using a PRF. > - With anything else, don’t use any hash weaker than SHA-256. > > If not here, where does this advice go? > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Nov 2 17:57:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A441A017E for ; Mon, 2 Nov 2015 17:57:23 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30IOKAdGToO9 for ; Mon, 2 Nov 2015 17:57:22 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 DCA181A017A for ; Mon, 2 Nov 2015 17:57:21 -0800 (PST) Received: by pabfh17 with SMTP id fh17so3238066pab.0 for ; Mon, 02 Nov 2015 17:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BQKgk17v6OSj5dJGihTo19Bxus/j28RrYovUwky3Eb8=; b=ZneoTtfUz8Ga7wA9QSNf8zAm/EewfDgafAHjC4nRFS8yNRtN2/dPzO0uPPpbpTRVPI cu0L/xytd2ynvMVDlI8fWkZ/v5xiIkpwWJpjoTXyjuEiKt3NvSN2tgrMiX5VEzGJ0Iv1 vto2O3e/7haoTYYuLbXurSYmWqWiPcB4DbE2I1bCt5yXdBs7RkzUNP2GIZ1/omW0TcyK lmZtT074JWabfQtfD5WC0xAcy/O+jNcUG/5cXvSovfsMcqqqv1hFMbZwfrrrHmMFyS40 dofj6Aa8i/HzdcZoXiJmcYDjNcxJYIYPv6A8AvhwpOTvLdV6upRpgIE1nu2Hwlyuu/Th OzFA== X-Received: by 10.68.220.194 with SMTP id py2mr30196056pbc.37.1446515841535; Mon, 02 Nov 2015 17:57:21 -0800 (PST) Received: from t20010c4000003024ac3ee19e76c6a265.v6.meeting.ietf94.jp (t20010c4000003024ac3ee19e76c6a265.v6.meeting.ietf94.jp. [2001:c40:0:3024:ac3e:e19e:76c6:a265]) by smtp.gmail.com with ESMTPSA id k5sm26314060pbq.74.2015.11.02.17.57.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 17:57:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <22072.729.246850.109764@fireball.acr.fi> Date: Tue, 3 Nov 2015 10:57:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6A2ABF31-EA4E-4794-9143-9A27AC5A08DC@gmail.com> References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> <22072.729.246850.109764@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "ipsec@ietf.org" , John Mattsson Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 01:57:24 -0000 > On 3 Nov 2015, at 9:42 AM, Tero Kivinen wrote: >=20 > John Mattsson writes: >> - BTW, What does it mean that an algorithm like ENCR_RC5 is not >> listed, does that mean =E2=80=9CMAY=E2=80=9D, =E2=80=9CMUST NOT=E2=80=9D= , or =E2=80=9Ctotally unspecified=E2=80=9D? >=20 > It means this document does not specify whether they should be used or > not, i.e. MAY. To elaborate a bit: there are a whole bunch of algorithms in each = category, and we didn=E2=80=99t want to grab the entire table from IANA.=20= The document lists the MUSTs and SHOULDs. That is the purpose of the = document. Other algorithms are mentioned only if they=E2=80=99re ones = that have previously been widely implemented and widely deployed, and = that we believe it is time for them to no longer be so widely deployed. = That is why DES, 3DES, MD5 and Group 2 get special mention. RC5 has = never been very popular in IPSec, and the same can be said for Blowfish, = Tiger, KPDK_MD5, and brainpoolP512r1. So we don=E2=80=99t mention those. Yoav From nobody Mon Nov 2 18:04:17 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91E71A1A79 for ; Mon, 2 Nov 2015 18:04:15 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn_y9gAf24VD for ; Mon, 2 Nov 2015 18:04:11 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 C2A3F1A8724 for ; Mon, 2 Nov 2015 18:04:10 -0800 (PST) Received: by padec8 with SMTP id ec8so3359490pad.1 for ; Mon, 02 Nov 2015 18:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZjcmVf6RfKr/PX8zIeRgB9s4YJz0Q7PMZ0G+IlF3Qrw=; b=lvDG2vvwNWbbeSMRgTrn3nqxWbRYeWVqxVA1KB/FKAQKv01euSfyidqF4znCpcBHVh iW2/ncITpRY8W9jI8buDgK8dsGn2LyXYrIaP6hvI3jvbnqgejka55n1AE3vem3mTy4pC nCX6Fl+tNXl95Eibkjs+eNpI+jd2W4wLJwt4Y42B5MQvV3nWb2PQKBLZ2JuyOtOf69CU wTyeox3DyvoZUIEq8ctyvtW752mMaD5ai5PZOKqqqipSX1zQOfORH6iB2SsPDNYRWE3r cr3IF9fEjEcdYao83z6aeNReGv9wW9h9NfpuYG9TAXhz6b9l1mKrFchQEyB9XX7cIDYA rPIw== X-Received: by 10.68.229.3 with SMTP id sm3mr5259230pbc.146.1446516250479; Mon, 02 Nov 2015 18:04:10 -0800 (PST) Received: from dhcp-24-150.meeting.ietf94.jp ([133.93.24.150]) by smtp.gmail.com with ESMTPSA id d2sm26450917pat.24.2015.11.02.18.04.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 18:04:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 (Normal) In-Reply-To: <6284ffff9a7dfa007a9c3ef07f003166.squirrel@www.trepanning.net> Date: Tue, 3 Nov 2015 11:04:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> <6284ffff9a7dfa007a9c3ef07f003166.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:04:16 -0000 > On 3 Nov 2015, at 10:48 AM, Dan Harkins wrote: >=20 >=20 >=20 > On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: >>=20 >>> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >>>=20 >>> On Mon, 2 Nov 2015, Yoav Nir wrote: >>>=20 >>>> P.S. Someone=C3=A2=C2=80=C2=99s asked me off-list whether there is = any IPsecME >>>> document that says not to trust SHA-1 in signatures, both AUTH = payload >>>> and certificates, the way the TLS 1.3 document may end up saying = for >>>> TLS. I=C3=A2=C2=80=C2=99m wondering if RFC4307bis might be the = place for this, in >>>> particular the signature in AUTH payload. Just something to think = about >>>> before we bikeshed.RFC4307bis Bikeshedding Session. >>>=20 >>> We should have text to clarify the difference of algorithm use in >>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH >>> processing crypto restrictions don't beling in 4307bis. >>=20 >> I think we do need some kind of statement along the lines: >> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 = says >> =C3=A2=C2=80=C2=9CSHOULD use SHA-1=C3=A2=C2=80=C2=9D and this is a = document from only last year=C3=A2=C2=80=C2=A6) >> - Don=C3=A2=C2=80=C2=99t use DSS because that is only defined with = SHA-1. >> - With ECDSA no need to specify because each curve comes with a hash >=20 > Do you mean each _signature_ comes with a hash because you can > use different hash algorithms to sign with any given curve. X9.62 in > section 7.3, under Actions subsection e sub 1, even specifies what > to do if the hash function used in the signature produces a digest > that is greater than the length of the prime used in the curve > definition-- namely, take the left-most length of prime bits of the > digest to construct intermediate variable E. X9.62 allows it, but IKEv2 does not. See the IKEv2 Authentication = Method table at=20 = http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ik= ev2-parameters-12 There is 1 for =E2=80=9CRSA Digital Signature=E2=80=9D and you can = encode any hash function the you would like, but for ECDSA there is: 9 - ECDSA with SHA-256 on the P-256 curve 10 - ECDSA with SHA-384 on the P-384 curve 11 - ECDSA with SHA-512 on the P-521 curve So unless you go by RFC 7427, you can=E2=80=99t mix and match. Yoav From nobody Mon Nov 2 18:04:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C671A1AB9 for ; Mon, 2 Nov 2015 18:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z3Vede2AhuA for ; Mon, 2 Nov 2015 18:04:28 -0800 (PST) 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 728FF1A9176 for ; Mon, 2 Nov 2015 18:04:19 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nqZDK3JqCzDJj; Tue, 3 Nov 2015 03:04:17 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=H3vm1oIm X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id T4zawiMwi_DV; Tue, 3 Nov 2015 03:04:16 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 3 Nov 2015 03:04:16 +0100 (CET) Received: from [133.93.83.135] (dhcp-83-135.meeting.ietf94.jp [133.93.83.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 1EA9C800B0; Mon, 2 Nov 2015 21:04:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1446516255; bh=wwnUz746lkdBsLPi7uPZuq8b3ZG9/FsPXze9o0ghqZ0=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=H3vm1oImjSTadeUerd58VuIvUqyGTVPP/JGz7tYPjnnHSoIM1uanxno3K8o2lrbtq lN55Ts6GdHj9wjxmaE+2wMv6JD0znbJWZMNbFVS9ZBdv8P+I32qf4pzdQS2t9lkOla UradT5wFFTrerz9CYg12gnHslTOKDViuuxGTtbQE= References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> <22072.729.246850.109764@fireball.acr.fi> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13B143) From: Paul Wouters Date: Tue, 3 Nov 2015 11:04:11 +0900 To: John Mattsson Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:04:31 -0000 > That sound reasonable, but shouldn=E2=80=99t the IoT devices have some gui= delines > (maybe just a sentence) on what they should implement? We know that they > will not implement everything, and if they chose different subsets, they > will not be able to talk to each other. >=20 I'd rather point to the minimal-IKE https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00 Paul= From nobody Mon Nov 2 18:05:09 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCE21A1B5A for ; Mon, 2 Nov 2015 18:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuk6UjhjKLXz for ; Mon, 2 Nov 2015 18:04:56 -0800 (PST) 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 E6D371AC413 for ; Mon, 2 Nov 2015 18:04:55 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nqZF13VdQzWf; Tue, 3 Nov 2015 03:04:53 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=MtabzIYV X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5eOCnjRLneHN; Tue, 3 Nov 2015 03:04:52 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 3 Nov 2015 03:04:52 +0100 (CET) Received: from [133.93.83.135] (dhcp-83-135.meeting.ietf94.jp [133.93.83.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 618988009F; Mon, 2 Nov 2015 21:04:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1446516291; bh=YktKqBTFCKJWGggn1Q0VMeDwWLOKUxuwgY1tvaBxeUM=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=MtabzIYVVhTpXPu1C8L0tIp9APaqZbITYcvo0RRHmow5xJ8JXYDalqwOD+SzX+yyQ JjmbBgOHOpSmtlgT7ZrQ/DLjS2mvBR0hjaDFfrqQLL1e918oDJhGXOi3i69JDWHHDV 6Y5VtO2SB9kRmrYNa/VAcj4dI68h8gcdE7qw5YTM= References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> <22072.729.246850.109764@fireball.acr.fi> <6A2ABF31-EA4E-4794-9143-9A27AC5A08DC@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <6A2ABF31-EA4E-4794-9143-9A27AC5A08DC@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13B143) From: Paul Wouters Date: Tue, 3 Nov 2015 11:04:50 +0900 To: Yoav Nir Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen , John Mattsson Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:05:01 -0000 But we should explain that in the introduction :) Sent from my iPhone > On Nov 3, 2015, at 10:57, Yoav Nir wrote: >=20 >=20 >> On 3 Nov 2015, at 9:42 AM, Tero Kivinen wrote: >>=20 >> John Mattsson writes: >>> - BTW, What does it mean that an algorithm like ENCR_RC5 is not >>> listed, does that mean =E2=80=9CMAY=E2=80=9D, =E2=80=9CMUST NOT=E2=80=9D= , or =E2=80=9Ctotally unspecified=E2=80=9D? >>=20 >> It means this document does not specify whether they should be used or >> not, i.e. MAY. >=20 > To elaborate a bit: there are a whole bunch of algorithms in each category= , and we didn=E2=80=99t want to grab the entire table from IANA.=20 >=20 > The document lists the MUSTs and SHOULDs. That is the purpose of the docum= ent. Other algorithms are mentioned only if they=E2=80=99re ones that have p= reviously been widely implemented and widely deployed, and that we believe i= t is time for them to no longer be so widely deployed. That is why DES, 3DES= , MD5 and Group 2 get special mention. RC5 has never been very popular in IP= Sec, and the same can be said for Blowfish, Tiger, KPDK_MD5, and brainpoolP5= 12r1. So we don=E2=80=99t mention those. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Nov 2 20:30:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92111B2D5C for ; Mon, 2 Nov 2015 20:30:08 -0800 (PST) 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 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 v2lNpnDMJbYI for ; Mon, 2 Nov 2015 20:30:06 -0800 (PST) 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 9CC181B2D57 for ; Mon, 2 Nov 2015 20:30:05 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tA34U1gk017300 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2015 06:30:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tA34U1Cd020311; Tue, 3 Nov 2015 06:30:01 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22072.14408.985101.132893@fireball.acr.fi> Date: Tue, 3 Nov 2015 06:30:00 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <8E795DD4-DF63-452D-96AA-F6D7BE232530@ericsson.com> <22072.729.246850.109764@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Cc: "ipsec@ietf.org" , John Mattsson Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:30:08 -0000 Paul Wouters writes: > > That sound reasonable, but shouldn=E2=80=99t the IoT devices have s= ome guidelines > > (maybe just a sentence) on what they should implement=3F We know th= at they > > will not implement everything, and if they chose different subsets,= they > > will not be able to talk to each other. > >=20 >=20 > I'd rather point to the minimal-IKE >=20 > https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00 Minimal IKEv2 cannot modify the mandatory to implement algorithms. LWIG charter says that: =09The group shall focus only on techniques that have been used =09in actual implementations and do not impact interoperability =09with other devices. The techniques shall also not affect =09conformance to the relevant specifications. I.e. the minimal IKEv2 should still be interoperable with any IKEv2 client. We had this discussion there when we said that even when certificates are mandatory to implement in IKEv2, they are not mandatory to use, i.e. you can also use shared key authentication (which is also mandatory to implement). The minimal IKEv2 cannot say that implementations should use some specific algorithm unless that is mandatory to implement, as otherwise it would not be interoperable to existing IKEv2 implementations implementing only mandatory to implement algorithms. Thats why minimal IKEv2 will not say anything about the algorithms, as that would not be in charter with LWIG WG. Here in the IPsecME WG, we can do that, i.e. I think adding separate section for constrained devices, and list what algorithms they should implement is good idea.=20 --=20 kivinen@iki.fi From nobody Mon Nov 2 20:34:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53661B2D72 for ; Mon, 2 Nov 2015 20:34:02 -0800 (PST) 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 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 noUF9udfys_V for ; Mon, 2 Nov 2015 20:34:01 -0800 (PST) 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 66A391B2D71 for ; Mon, 2 Nov 2015 20:34:01 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tA34XwHH009497 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2015 06:33:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tA34Xwkb018057; Tue, 3 Nov 2015 06:33:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22072.14646.672637.788399@fireball.acr.fi> Date: Tue, 3 Nov 2015 06:33:58 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> <6284ffff9a7dfa007a9c3ef07f003166.squirrel@www.trepanning.net> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: IPsecME WG , Dan Harkins Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:34:03 -0000 Yoav Nir writes: > There is 1 for =E2=80=9CRSA Digital Signature=E2=80=9D and you can en= code any hash > function the you would like, but for ECDSA there is:=20 > 9 - ECDSA with SHA-256 on the P-256 curve > 10 - ECDSA with SHA-384 on the P-384 curve > 11 - ECDSA with SHA-512 on the P-521 curve Also number 3 DSS Digital Signature uses a SHA-1 hash.... > So unless you go by RFC 7427, you can=E2=80=99t mix and match. So everybody should move to use that :-) --=20 kivinen@iki.fi From nobody Mon Nov 2 20:58:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04801B2E1A for ; Mon, 2 Nov 2015 20:58:56 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63abG6o9vG6D for ; Mon, 2 Nov 2015 20:58:55 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 533D81B2E0C for ; Mon, 2 Nov 2015 20:58:55 -0800 (PST) Received: by padhk6 with SMTP id hk6so1528684pad.1 for ; Mon, 02 Nov 2015 20:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wqsrpHNIA9Qv6E0xLPRYccy/vRWJ7KeQFkzu660Rwq8=; b=cAb2zZwsAKCeaJHHYVtt+dyT2RRNFkYs473/LQj58/s/1nIRSWNUAe89hHTq+oQ1oo 29rXTGbTz+nUG05EhOpK/GzyHZxmAmWdlb/Nn67Pa6mhF171LLsYG882yDHvdMa2URpp jhwollg4lwBwjykx4uUhFq7wz8tx7M0lxFuSGrX7LwsbUYvEkmQ+gNvmi7HHtYb38mYP 2VQvniAb4WZq5OoIpBaszqtSbrbqjo2dtrZhbdykuLG6ptkFGG64ubMQV2oL44dQHRp/ 7tsSHIkTD7EaDfcMU2KIoZPNPw2eGYtGj7MjCtyXuVAgFnxUmybzH35VXFHARjz/NulL FnPA== X-Received: by 10.68.161.133 with SMTP id xs5mr31724167pbb.13.1446526735057; Mon, 02 Nov 2015 20:58:55 -0800 (PST) Received: from dhcp-24-150.meeting.ietf94.jp ([133.93.24.150]) by smtp.gmail.com with ESMTPSA id yk5sm27071122pac.5.2015.11.02.20.58.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 20:58:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <22072.14646.672637.788399@fireball.acr.fi> Date: Tue, 3 Nov 2015 13:58:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <81A4F70F-D446-4328-AB7F-13E1362297F6@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> <6284ffff9a7dfa007a9c3ef07f003166.squirrel@www.trepanning.net> <22072.14646.672637.788399@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG , Dan Harkins Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:58:57 -0000 > On 3 Nov 2015, at 1:33 PM, Tero Kivinen wrote: >=20 > Yoav Nir writes: >> There is 1 for =E2=80=9CRSA Digital Signature=E2=80=9D and you can = encode any hash >> function the you would like, but for ECDSA there is:=20 >> 9 - ECDSA with SHA-256 on the P-256 curve >> 10 - ECDSA with SHA-384 on the P-384 curve >> 11 - ECDSA with SHA-512 on the P-521 curve >=20 > Also number 3 DSS Digital Signature uses a SHA-1 hash.... >=20 >> So unless you go by RFC 7427, you can=E2=80=99t mix and match. >=20 > So everybody should move to use that :-) It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. = So you couldn=E2=80=99t fit the output of SHA-384 in there. It does work = the other way around (SHA-256 and P-384), but I=E2=80=99m not sure = whether that is any more secure than SHA-256 with P-256. Yoav From nobody Mon Nov 2 21:37:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31301AD0C5 for ; Mon, 2 Nov 2015 21:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_ozoHZ5wZ0T for ; Mon, 2 Nov 2015 21:37:55 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53C1AD160 for ; Mon, 2 Nov 2015 21:37:52 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AC839A888132; Mon, 2 Nov 2015 21:37:51 -0800 (PST) Received: from 133.93.25.39 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 Nov 2015 21:37:51 -0800 (PST) Message-ID: In-Reply-To: <81A4F70F-D446-4328-AB7F-13E1362297F6@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> <4FD8FF1B-3006-457B-8520-18C7FE0608F6@gmail.com> <6284ffff9a7dfa007a9c3ef07f003166.squirrel@www.trepanning.net> <22072.14646.672637.788399@fireball.acr.fi> <81A4F70F-D446-4328-AB7F-13E1362297F6@gmail.com> Date: Mon, 2 Nov 2015 21:37:51 -0800 (PST) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:37:57 -0000 On Mon, November 2, 2015 8:58 pm, Yoav Nir wrote: > >> On 3 Nov 2015, at 1:33 PM, Tero Kivinen wrote: >> >> Yoav Nir writes: >>> There is 1 for “RSA Digital Signature” and you can encode any hash >>> function the you would like, but for ECDSA there is: >>> 9 - ECDSA with SHA-256 on the P-256 curve >>> 10 - ECDSA with SHA-384 on the P-384 curve >>> 11 - ECDSA with SHA-512 on the P-521 curve >> >> Also number 3 DSS Digital Signature uses a SHA-1 hash.... >> >>> So unless you go by RFC 7427, you can’t mix and match. >> >> So everybody should move to use that :-) Yes, they should! Note that the repository uses a definite article (and we all know which curves the authors were referring to). So you can't do #9 with the brainpoolp256 curve, which is sub-optimal. > It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So > you couldn’t fit the output of SHA-384 in there. It does work the other > way around (SHA-256 and P-384), but I’m not sure whether that is any > more secure than SHA-256 with P-256. That's why X9.62 specifies using the left-most length of prime bits when the digest is larger than the length of the prime. It does work. Technically you can use ecdsa-with-SHA384 and "the P-256 curve", why you would want to is a different story. Odd fact: the WAPI protocol (Chinese wireless encryption and authentication protocol) uses SHA-256 with a special Chinese government-specified curve based on a 192-bit prime and doesn't follow X9.62. It uses the entire 256 bit digest to calculate the signature on the 192-bit curve. The 256-bit digest does "fit" since the math is all mod p. The result (r,s) is properly formed but s will be different from a standard ECDSA signature. Dan. From nobody Tue Nov 3 18:20:17 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D081A8A4B for ; Tue, 3 Nov 2015 18:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7o5k_Xy0s5E for ; Tue, 3 Nov 2015 18:20:11 -0800 (PST) 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 C14B81A8A4E for ; Tue, 3 Nov 2015 18:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1446603609; x=2310517209; 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=4kqGz6IQzOmyPWjzAO7Ahdb2yikDYoaPphRAHknTK/U=; b=ovE/PPBvJKaeIXRgNhUFJPTvTJ9mOZHvSkaT16CPmY5gSsI8tTcYxULhK2aOiKf/ tyJRet6VQLNPPOmjVfnB6nWHaPF8fbSnrrS2TqMN3PMVcKqJ4aI813wXWIy3FjuB uOLXWI++STynFzDHTzOZzCptqMHnWWsW0FXf+LKege7bCFyeJ6NNxRqzd/zLCA4L QAZex9OpbFbh9HJubACiDRDR1LxgreYNtEpjFwCyGEKj8Pntcyy+47MpN/evGiSm sFGZu9cy+bBPstPJ+ys0JjmWJv368cJPgstsa+JJlE33evXIRYFnxeo0HaU+B23y YP4cqxSrIlcN87vf8XkXow==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id E3.BC.15870.95B69365; Tue, 3 Nov 2015 18:20:09 -0800 (PST) X-AuditID: 11973e13-f798c6d000003dfe-b5-56396b59bf83 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id F7.DC.29392.95B69365; Tue, 3 Nov 2015 18:20:09 -0800 (PST) Received: from [17.153.90.24] (unknown [17.153.90.24]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NX900EXOQHITW80@chive.apple.com> for ipsec@ietf.org; Tue, 03 Nov 2015 18:20:09 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.2 \(3106\)) From: Tommy Pauly In-reply-to: Date: Wed, 04 Nov 2015 11:20:08 +0900 Content-transfer-encoding: quoted-printable Message-id: References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> <641F9450-5BF6-43DE-A0A9-168F5022DB62@apple.com> To: IPsecME WG X-Mailer: Apple Mail (2.3106) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYpRuZbRlmcOqxuMX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceLHXPaCE0wVdy/eYGlg7GPqYuTkkBAwkTjW8ZMFwhaTuHBv PVsXIxeHkMBeRom1Z6+xwxRtu7uAESLRzSRx6PsCVgini0niyorfQBkODmEBCYnNexJBTGYB dYkpU3JBTF4BPYm1xytBxggLWElsO9YLtotNQEXi+LcNzCA2p4CBxPaP11lBbBYBVYn7Xz6B 1TALaEs8eXcBLM4rYCOxZSrIzSBb+5klpj1+DrZVREBeYuaNTIgzZSU6u+6CnSkh8JFV4vrH z8wTGIVnIVw0C+GiWUg2LGBkXsUolJuYmaObmWeql1hQkJOql5yfu4kRFMDT7YR3MJ5eZXWI UYCDUYmH9wajZZgQa2JZcWXuIUZpDhYlcd7NWkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jBULFrXqHput97HtRPHOcwyc8iH75p2tUf08x0RmgfHHlvDfrlrep3M1/9x5vaH/vcSiiW2q i6JCtvrN+PbOf4I0Z/u6R6ZTPSdYlkaG5zOoztx/p3vGucd8exRXL1jQqcR7AhgAn7K7rfvU 14n9nKzDWDYx4uwhpkjbjY7tN4JmKHzVaVH7ocRSnJFoqMVcVJwIAMoyKvVBAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FDMrxuZbRlmsPq2qMX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceLHXPaCE0wVdy/eYGlg7GPqYuTkkBAwkdh2dwEjhC0mceHe erYuRi4OIYFuJolD3xewQjhdTBJXVvwGquLgEBaQkNi8JxHEZBZQl5gyJRfE5BXQk1h7vBJk jLCAlcS2Y70sIDabgIrE8W8bmEFsTgEDie0fr7OC2CwCqhL3v3wCq2EW0JZ48u4CWJxXwEZi y1SQ00C29jNLTHv8HGyriIC8xMwbmRBnykp0dt1lnMAoMAvhiFkIR8xCMnQBI/MqRoGi1JzE SjO9xIKCnFS95PzcTYzggCuM2sHYsNzqEKMAB6MSD2/Df4swIdbEsuLK3EOMEhzMSiK8lX6W YUK8KYmVValF+fFFpTmpxYcYpTlYlMR5S7eahwkJpCeWpGanphakFsFkmTg4pRoYJ9e6i76N 2cqhJR/y2Djtvm685b1tTFd9gtp3sHuUFUVwOCxZc3azfjnnu+N8v6+adZTPavu1IDa+oWVe wLGYyx7LbfRCe8R9Jvmdr2KsmxV2MnWjc6TXFe/YkD2dExfH+s9unH/h1dyv06ueeN6YPXP9 x3cPMmSsPE5szlL/ctc80cKuZPczJZbijERDLeai4kQAYWQWyjQCAAA= Archived-At: Subject: [IPsec] Discussing TCP Encapsulation of IPSec in Yokohama X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 02:20:15 -0000 Hello all, We=E2=80=99ll be having an informal meeting here in Yokohama to discuss = TCP encapsulation for IPSec/IKEv2 (draft-pauly-ipsecme-tcp-encaps-00) = tomorrow, Thursday, Nov 5, at 12pm.=20 Anyone who=E2=80=99s interested in joining to discuss, please meet at = the registration desk at noon! Thanks, Tommy= From nobody Tue Nov 3 20:21:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4671A90AC for ; Tue, 3 Nov 2015 20:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 yNeGDHWnnoDr for ; Tue, 3 Nov 2015 20:21:27 -0800 (PST) Received: from hoffman.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 6BB431A9150 for ; Tue, 3 Nov 2015 20:21:25 -0800 (PST) Received: from [10.32.60.94] (dhcp-28-182.meeting.ietf94.jp [133.93.28.182]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id tA44LLDZ048224 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2015 21:21:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host dhcp-28-182.meeting.ietf94.jp [133.93.28.182] claimed to be [10.32.60.94] From: "Paul Hoffman" To: "Tommy Pauly" Date: Wed, 04 Nov 2015 13:21:20 +0900 Message-ID: In-Reply-To: References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> <641F9450-5BF6-43DE-A0A9-168F5022DB62@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Discussing TCP Encapsulation of IPSec in Yokohama X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:21:28 -0000 On 4 Nov 2015, at 11:20, Tommy Pauly wrote: > Hello all, > > We’ll be having an informal meeting here in Yokohama to discuss TCP > encapsulation for IPSec/IKEv2 (draft-pauly-ipsecme-tcp-encaps-00) > tomorrow, Thursday, Nov 5, at 12pm. > > Anyone who’s interested in joining to discuss, please meet at the > registration desk at noon! Change of venue: I have reserved room 513 Thursday from 1200 to 1300 for this discussion. That should make it easier for people to find each other. --Paul Hoffman From nobody Tue Nov 3 20:34:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB651A92E9 for ; Tue, 3 Nov 2015 20:34:56 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByLFc-h-Z0s6 for ; Tue, 3 Nov 2015 20:34:55 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 12E0C1A92DC for ; Tue, 3 Nov 2015 20:34:55 -0800 (PST) Received: by padhx2 with SMTP id hx2so32166434pad.1 for ; Tue, 03 Nov 2015 20:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=6W6dB3zp8oFh/aEQXM8y7U4t/OM9eEsg1lf782G6dQk=; b=zkvb9LtMtZTzbcYmZAv/julP7VszhAJuNtX/Al74m8Ef454YoETAsZbkhRHVpgaK0r vWQe/o8NuPmmhQPiMqW0qnay5BKeE5jpWB2kT5wYcRtjhG9ySV13oDM2qMmAj+k/MVeB gDdeEegDVY2Sb/jKSJxozUvu2XxnFIfaiVwPeQoTKhWWLx45d3dGDI8qUpJQ7YAnUXSw 82wFTD//en0oYUVw+cmdUaautut6uhiU/L9FoPXTsEaW9Crp/QtAQNoF021qQ/2Lxkrq spVQoY6bliMdVqW/LXG6TtUM1pI6e4T0dOdp0SkLGrEJ+BKYVCOfxt5skoXl2k2iB652 koCw== X-Received: by 10.66.248.198 with SMTP id yo6mr37539551pac.96.1446611694788; Tue, 03 Nov 2015 20:34:54 -0800 (PST) Received: from t20010c400000302408e8831114c881ca.v6.meeting.ietf94.jp (t20010c400000302408e8831114c881ca.v6.meeting.ietf94.jp. [2001:c40:0:3024:8e8:8311:14c8:81ca]) by smtp.gmail.com with ESMTPSA id rx10sm23854781pab.21.2015.11.03.20.34.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 20:34:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> Date: Wed, 4 Nov 2015 13:34:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <344F04A7-47BB-4523-819A-7B6453DFFE69@gmail.com> References: <69105372-33FC-480C-8D0F-03FF2F92B33B@gmail.com> To: IPsecME WG X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:34:56 -0000 Reminder. It=E2=80=99s tonight at 7:00 PM Japan time, 10:00 UTC. We won=E2=80=99t have Meetecho or audio streaming, but if a few remote = people want to participate, we might be able to do something with Skype. Yoav > On 2 Nov 2015, at 10:28 AM, Yoav Nir wrote: >=20 > Hi, all >=20 > Since we=E2=80=99ve had quite a bit of bikeshedding about this on the = list, we=E2=80=99d like to gather and has it out face to face. >=20 > So this Wednesday at 7:00 PM, right after the plenaries, we=E2=80=99ll = meet at room 421 to hash this out. >=20 > Everyone=E2=80=99s invited, obviously. >=20 > Yoav >=20 > P.S. Someone=E2=80=99s asked me off-list whether there is any IPsecME = document that says not to trust SHA-1 in signatures, both AUTH payload = and certificates, the way the TLS 1.3 document may end up saying for = TLS. I=E2=80=99m wondering if RFC4307bis might be the place for this, in = particular the signature in AUTH payload. Just something to think about = before we bikeshed.RFC4307bis Bikeshedding Session. >=20 > From nobody Wed Nov 4 08:39:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E181B32FC for ; Wed, 4 Nov 2015 08:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQlgj6s_qa_D for ; Wed, 4 Nov 2015 08:39:29 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 290001B32FB for ; Wed, 4 Nov 2015 08:39:29 -0800 (PST) Received: by pacdm15 with SMTP id dm15so33231469pac.3 for ; Wed, 04 Nov 2015 08:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=LcCcSzTlEEFdWDhsji5huOclLznSC7aNgCGxUropQlU=; b=deQd6/21zE3dY4tvwhF4SNRk8z4nZ5h3lqI0GH57+QHnDlVKMJ4ss1/fWFT33aumHp +g9MWHIImVeHuNnGQC5vm9gjdS+ktqvAndTAQNtEL6I+6D5xggi4OfnrQHAppWvckcII DHa1xOqf02iN9wALNKXztaJdx1V0l7wNJnD1zAl0qJO7npc5ZTGIN1RrVVaoUafrawnS y/6OPtdpfu1fQnvwUQ4/ATkTifP/INhufttAcqQDUhkVDfOj4eArfbpBW8p1iHTi0FWG uS1kn1fKffjBLjLNxFXEniUa8RrTDnp+ozdEXLai77YczoMilONayYiIP8BlrKcwMSi2 aeEQ== X-Received: by 10.68.204.168 with SMTP id kz8mr2909649pbc.96.1446655168512; Wed, 04 Nov 2015 08:39:28 -0800 (PST) Received: from [10.11.0.90] (y255183.ppp.asahi-net.or.jp. [118.243.255.183]) by smtp.gmail.com with ESMTPSA id x15sm2982524pbt.38.2015.11.04.08.39.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 08:39:27 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_26FF99A0-F94B-435C-8EF0-39A708A68F0B" Message-Id: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> Date: Thu, 5 Nov 2015 01:39:24 +0900 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 16:39:31 -0000 --Apple-Mail=_26FF99A0-F94B-435C-8EF0-39A708A68F0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all. I=E2=80=99ve uploaded the XML source of this document to github and = submitted the first pull request: https://github.com/ietf-ipsecme/drafts/pull/7/files = We had a side meeting about the algorithms specified in this draft and = came up with some changes as you can see in the PR. In attendance were = Paul H, David W, Paul W, Tero K, Tommy P, Daniel M and me. I=E2=80=99ve also added a dummy paragraph for each algorithm. After I = merge the pull request anyone (author or otherwise) can submit pull = request. Hopefully the pre-existence of these paragraphs will prevent = them from becoming conflicts. But I wouldn=E2=80=99t get my hopes up. Anyway, please review the pull request and let me know if it=E2=80=99s = problematic. If not, I will merge it early next week. Yoav --Apple-Mail=_26FF99A0-F94B-435C-8EF0-39A708A68F0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all.

I=E2=80=99ve uploaded the XML source of this document to = github and submitted the first pull request:
https://github.com/ietf-ipsecme/drafts/pull/7/files

We had a side meeting = about the algorithms specified in this draft and came up with some = changes as you can see in the PR. In attendance were Paul H, David W, = Paul W, Tero K, Tommy P, Daniel M and me.

I=E2=80=99ve also added a dummy = paragraph for each algorithm. After I merge the pull request anyone = (author or otherwise) can submit pull request. Hopefully the = pre-existence of these paragraphs will prevent them from becoming = conflicts. But I wouldn=E2=80=99t get my hopes up.

Anyway, please review = the pull request and let me know if it=E2=80=99s problematic. If not, I = will merge it early next week.

Yoav



= --Apple-Mail=_26FF99A0-F94B-435C-8EF0-39A708A68F0B-- From nobody Mon Nov 9 05:38:06 2015 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 5506D1B7CC7; Mon, 9 Nov 2015 05:38:04 -0800 (PST) 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.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151109133804.5365.2825.idtracker@ietfa.amsl.com> Date: Mon, 09 Nov 2015 05:38:04 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:38:04 -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 Working Group of the IETF. Title : Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-01.txt Pages : 8 Date : 2015-11-09 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-01 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 Mon Nov 9 05:48:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576821B7CFB for ; Mon, 9 Nov 2015 05:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c22vR9xXuL9M for ; Mon, 9 Nov 2015 05:48:54 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 2A0DF1B7CF8 for ; Mon, 9 Nov 2015 05:48:54 -0800 (PST) Received: by wmdw130 with SMTP id w130so30187250wmd.0 for ; Mon, 09 Nov 2015 05:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=zDjqbYhwI2tSlLtMaGqiszvjC/YVzO1ueBPhcT/YYFs=; b=u4dzfGr6lZKDzvjbhUEZ+CI/t09NBizyQju3L8ADzcfC8scmnq6qE1brz37HbBMC/1 jYVAsHtByqUdQNtXIFxgm5xF7MNbEi3iFzHkfMUfEgxCoH4UrOHAeNkoXHUxZ1BU4ir7 dYD24ZmaeGlYxSbFm56w4kUEuRADhZsA8SWP8CMEPEVtUwBCpY+BiCHFIivSR6PcHqTI RqB8xXE38QLaDGjSW6RL9SQxMHcDFD4a5XY9c6J69kb0gkFfSNwG4kQHDvNA3pm63Bme LxHaBJvWqDlRhz8g3GohQxoEv444O/eHWGk+lGRTEzIwwsACCGqlExLTgpkpvPrzpmx+ Ku6w== X-Received: by 10.28.143.8 with SMTP id r8mr27493093wmd.3.1447076932472; Mon, 09 Nov 2015 05:48:52 -0800 (PST) Received: from [172.24.248.35] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id p75sm14410292wmd.22.2015.11.09.05.48.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Nov 2015 05:48:51 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_957F344E-9A51-4CEB-A5E1-326AC54BF513" Message-Id: <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Date: Mon, 9 Nov 2015 15:48:49 +0200 References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> To: IPsecME WG In-Reply-To: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:48:56 -0000 --Apple-Mail=_957F344E-9A51-4CEB-A5E1-326AC54BF513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi So I=E2=80=99ve merged the changes and submitted version -01 of the = draft. The stub paragraphs explaining the choices of algorithms are waiting to = be filled. Please submit pull requests. = https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4= 307bis Yoav > On 4 Nov 2015, at 6:39 PM, Yoav Nir wrote: >=20 > Hi all. >=20 > I=E2=80=99ve uploaded the XML source of this document to github and = submitted the first pull request: > https://github.com/ietf-ipsecme/drafts/pull/7/files = >=20 > We had a side meeting about the algorithms specified in this draft and = came up with some changes as you can see in the PR. In attendance were = Paul H, David W, Paul W, Tero K, Tommy P, Daniel M and me. >=20 > I=E2=80=99ve also added a dummy paragraph for each algorithm. After I = merge the pull request anyone (author or otherwise) can submit pull = request. Hopefully the pre-existence of these paragraphs will prevent = them from becoming conflicts. But I wouldn=E2=80=99t get my hopes up. >=20 > Anyway, please review the pull request and let me know if it=E2=80=99s = problematic. If not, I will merge it early next week. >=20 > Yoav >=20 >=20 >=20 --Apple-Mail=_957F344E-9A51-4CEB-A5E1-326AC54BF513 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

So = I=E2=80=99ve merged the changes and submitted version -01 of the = draft.

The = stub paragraphs explaining the choices of algorithms are waiting to be = filled. Please submit pull requests.

https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-i= psecme-rfc4307bis

Yoav

On 4 Nov 2015, at 6:39 PM, Yoav = Nir <ynir.ietf@gmail.com> wrote:

Hi all.

I=E2=80=99ve uploaded = the XML source of this document to github and submitted the first pull = request:
https://github.com/ietf-ipsecme/drafts/pull/7/files

We had a side meeting = about the algorithms specified in this draft and came up with some = changes as you can see in the PR. In attendance were Paul H, David W, = Paul W, Tero K, Tommy P, Daniel M and me.

I=E2=80=99ve also added a dummy = paragraph for each algorithm. After I merge the pull request anyone = (author or otherwise) can submit pull request. Hopefully the = pre-existence of these paragraphs will prevent them from becoming = conflicts. But I wouldn=E2=80=99t get my hopes up.

Anyway, please review = the pull request and let me know if it=E2=80=99s problematic. If not, I = will merge it early next week.

Yoav




= --Apple-Mail=_957F344E-9A51-4CEB-A5E1-326AC54BF513-- From nobody Mon Nov 9 08:27:19 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030441B31C5 for ; Mon, 9 Nov 2015 08:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2BwXhpS80LK for ; Mon, 9 Nov 2015 08:27:15 -0800 (PST) Received: from hoffman.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 BD2011B31C4 for ; Mon, 9 Nov 2015 08:27:15 -0800 (PST) Received: from [10.32.60.128] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tA9GREP8040978 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Nov 2015 09:27:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.128] From: "Paul Hoffman" To: "IPsecME WG" Date: Mon, 09 Nov 2015 08:27:14 -0800 Message-ID: In-Reply-To: <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 16:27:17 -0000 On 9 Nov 2015, at 5:48, Yoav Nir wrote: > So I=E2=80=99ve merged the changes and submitted version -01 of the dra= ft. > > The stub paragraphs explaining the choices of algorithms are waiting = > to be filled. Please submit pull requests. > > https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-r= fc4307bis This is an invitation to the WG to contribute to to this draft. If you = are already familiar with GitHub, submit pull requests as Yoav said. If = you are not yet familiar with GitHub, feel free to send text to the = mailing list, and one of the authors will quickly enter those for you in = GitHub. That is, being able to use GitHub is *not* required for you to = contribute text. --Paul Hoffman From nobody Mon Nov 9 14:30:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6E1B8665 for ; Mon, 9 Nov 2015 14:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4p2MAK9LqlT for ; Mon, 9 Nov 2015 14:30:09 -0800 (PST) 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 1780D1B8668 for ; Mon, 9 Nov 2015 14:30:09 -0800 (PST) Received: by wmww144 with SMTP id w144so52169878wmw.0 for ; Mon, 09 Nov 2015 14:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+xQTz1BmZs3Fer6S+eUl7C4CK1tUpGBIn+OTeWYXNR4=; b=uBW8eN/sICjDkrrUloFi6PMsD2byHqGFtgGZiorj8ZsczHHO2Sqvhzp+shfnFZz/JN rfSVPZQfESyIW7sFL4Rs74q7lbkhzbF/fHhxxr8rqf/z9mxXsaJgqnwYlyZJ3ahhqhHz 5Lb2O3rYjkVxoIWIjDRhdL2eXKYAOxbkbppHKOXuiKU9KlPA9QF5pvidSQVXTfC7D4ep zwnuHxz4ke7qIwCN10205suttsESf+ZuHMI9oo20LRdUkAnIKF2jaxnS1+2sVFxhOOej Cko7XkwQRlSeIVbJ9A5h73Y2xwMabDp9+pFssEQlAcJzjb/3OZDeP5AvyeMFhNLQCW4n cTMQ== MIME-Version: 1.0 X-Received: by 10.194.10.68 with SMTP id g4mr222598wjb.151.1447108207673; Mon, 09 Nov 2015 14:30:07 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.110.9 with HTTP; Mon, 9 Nov 2015 14:30:07 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> Date: Mon, 9 Nov 2015 17:30:07 -0500 X-Google-Sender-Auth: WO4Il931Cwj9Huycsr5s6c0Com8 Message-ID: From: Daniel Migault To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b5d997fab8c300524232258 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 22:30:11 -0000 --047d7b5d997fab8c300524232258 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, You can view the latest changes here: https://github.com/mglt /drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme -rfc4307bis We added some text to recommend the status of each recommended algorithms. On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman wrote= : > On 9 Nov 2015, at 5:48, Yoav Nir wrote: > > So I=E2=80=99ve merged the changes and submitted version -01 of the draft= . >> >> The stub paragraphs explaining the choices of algorithms are waiting to >> be filled. Please submit pull requests. >> >> >> https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rf= c4307bis >> > > This is an invitation to the WG to contribute to to this draft. If you ar= e > already familiar with GitHub, submit pull requests as Yoav said. If you a= re > not yet familiar with GitHub, feel free to send text to the mailing list, > and one of the authors will quickly enter those for you in GitHub. That i= s, > being able to use GitHub is *not* required for you to contribute text. > > --Paul Hoffman > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b5d997fab8c300524232258 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

You can view the latest change= s here:

https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/dra= ft-ietf-ipsecme-rfc4= 307bis

We added some text to recommend the status of each reco= mmended algorithms.

On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman <paul.hoffma= n@vpnc.org> wrote:
On 9 Nov 2015, at 5:48, Yoav Nir wrote:

So I=E2=80=99ve merged the changes and submitted version -01 of the draft.<= br>
The stub paragraphs explaining the choices of algorithms are waiting to be = filled. Please submit pull requests.

https://github.com/i= etf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis

 This is an invitation to the WG to contribute to to this draft. If you are = already familiar with GitHub, submit pull requests as Yoav said. If you are= not yet familiar with GitHub, feel free to send text to the mailing list, = and one of the authors will quickly enter those for you in GitHub. That is,= being able to use GitHub is *not* required for you to contribute text.

--Paul Hoffman


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

--047d7b5d997fab8c300524232258-- From nobody Mon Nov 9 14:33:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AF01B8691 for ; Mon, 9 Nov 2015 14:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzY8C-Unrwx1 for ; Mon, 9 Nov 2015 14:33:55 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 4DD061B866B for ; Mon, 9 Nov 2015 14:33:55 -0800 (PST) Received: by wmww144 with SMTP id w144so52266884wmw.0 for ; Mon, 09 Nov 2015 14:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nUq1HwpRbM5UUKsLRHdWnWtfKuvsfU9bn1V1fO7yWwE=; b=uwIW9tGeQRHT25IaVUcol0bN1DNzNX/8ecKnLTG1q7KJ+ZXBdcIS3RwFl5m8eHbIAz LUrSMFFxqzM9XK9qlnpcv+g7h3eS8NeyQx5GeKpsV6m2DwnLvh753616XKUpJdYrO6ci ExwnVae/PEaJJ+O9skheaGTgX5Yzlodh4QFNwxwKuOs97UQrVMmewegHQTYgIEiYqyMk 6bU5BnJ3k5uYnCfcxXuu8+3NeV1/mQtbhJf/1ugDSOYS3YB3x3JHlt/TLqXYH11V/uN7 1gTIIM9UaB9dn0/zHscbbNGKy+ocUmxa/619Ljvhls2p7lRNn4yIRUw37Vp53rk9Lnb2 afyg== X-Received: by 10.28.170.19 with SMTP id t19mr775492wme.65.1447108433911; Mon, 09 Nov 2015 14:33:53 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id c1sm223504wjf.19.2015.11.09.14.33.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Nov 2015 14:33:53 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E1E9067F-52CE-4A9E-8E1F-A8F3EC324A44" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Tue, 10 Nov 2015 00:33:51 +0200 Message-Id: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> To: Daniel Migault X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 22:33:57 -0000 --Apple-Mail=_E1E9067F-52CE-4A9E-8E1F-A8F3EC324A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Or for a diff-style view, see the pull request: https://github.com/ietf-ipsecme/drafts/pull/8/files Yoav > On 10 Nov 2015, at 12:30 AM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > You can view the latest changes here: >=20 > = https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a4= 67/draft-ietf-ipsecme-rfc4307bis >=20 > We added some text to recommend the status of each recommended = algorithms. >=20 > On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman > wrote: > On 9 Nov 2015, at 5:48, Yoav Nir wrote: >=20 > So I=E2=80=99ve merged the changes and submitted version -01 of the = draft. >=20 > The stub paragraphs explaining the choices of algorithms are waiting = to be filled. Please submit pull requests. >=20 > = https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4= 307bis = >=20 > This is an invitation to the WG to contribute to to this draft. If you = are already familiar with GitHub, submit pull requests as Yoav said. If = you are not yet familiar with GitHub, feel free to send text to the = mailing list, and one of the authors will quickly enter those for you in = GitHub. That is, being able to use GitHub is *not* required for you to = contribute text. >=20 > --Paul Hoffman >=20 >=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 --Apple-Mail=_E1E9067F-52CE-4A9E-8E1F-A8F3EC324A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Or for a diff-style view, see the pull request:
https://github.com/ietf-ipsecme/drafts/pull/8/files

Yoav

On 10 Nov 2015, at 12:30 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

You can view the latest changes here:

https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a46= 7/draft-ietf-ipsecme-rfc4307bis

We= added some text to recommend the status of each recommended = algorithms.

On Mon, Nov 9, 2015 at 11:27 AM, = Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 9 = Nov 2015, at 5:48, Yoav Nir wrote:

So I=E2=80=99ve merged the changes and submitted version -01 of the = draft.

The stub paragraphs explaining the choices of algorithms are waiting to = be filled. Please submit pull requests.

https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-i= psecme-rfc4307bis

 This is an invitation to the WG to contribute to to this draft. If you = are already familiar with GitHub, submit pull requests as Yoav said. If = you are not yet familiar with GitHub, feel free to send text to the = mailing list, and one of the authors will quickly enter those for you in = GitHub. That is, being able to use GitHub is *not* required for you to = contribute text.

--Paul Hoffman


_______________________________________________
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

= --Apple-Mail=_E1E9067F-52CE-4A9E-8E1F-A8F3EC324A44-- From nobody Tue Nov 10 08:38:18 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435121A002D for ; Tue, 10 Nov 2015 08:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tptykgzGwwy for ; Tue, 10 Nov 2015 08:38:13 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 C284D1A0024 for ; Tue, 10 Nov 2015 08:38:13 -0800 (PST) Received: by pabfh17 with SMTP id fh17so1694356pab.0 for ; Tue, 10 Nov 2015 08:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=KqOQvak9e1YdwmWwSjhhjSigFUP+7/pYUlxW8TN8/t4=; b=XHwO/1otq7kNCwzdE9l77XfmNjLrECxwBNTlTvJ9GFLC9mdDi0VEZtOgUfUVBJfGyz HGG0yP/mWl2ip7IByXlbgeUyYNbPN7wiQXxvX7Oarm7MxIhy6QgFJEInsX5/RsDy8ETp PHya5oNQWG6dxTHgl0zzb2x/qT86rEawkrirlsqW/k7oswBGmm4iC8DxRNl3409HQxYw HXUPpzP84QXC81ZVBR/BObVHHCp1nwDETGUku5sKY0u7bl5/p/X05k1j6AqlIXCO+81W La86jYlHqJOKyfWWa054A7I+T0V0jC9cR2LU6kD3N1ym+tbEKjErgnB9IpcOZdHA35F7 Qegw== X-Received: by 10.66.63.37 with SMTP id d5mr7082448pas.103.1447173493319; Tue, 10 Nov 2015 08:38:13 -0800 (PST) Received: from [192.168.1.129] ([2.54.145.121]) by smtp.googlemail.com with ESMTPSA id bn1sm5005006pad.17.2015.11.10.08.38.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Nov 2015 08:38:12 -0800 (PST) From: Yaron Sheffer To: Yoav Nir , Daniel Migault References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> Message-ID: <56421D6F.7080506@gmail.com> Date: Tue, 10 Nov 2015 18:38:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 16:38:16 -0000 A few comments, sorry for not using GitHub. I think the following text is kinda funny: "IKEv1 is out of scope of this document. IKEv1 is deprecated and the recommendations of this document MUST NOT be considered for IKEv1." We cannot tell people normatively what they can consider and what they cannot. Let's skip the capitalized MUST NOT. The rationale for GCM describes why it's in the table, but seems to argue for a MUST (rather than the SHOULD that's in the table). I guess there's a reason why we don't have MUST, let's spell it out. "As the overhead of AUTH_HMAC_SHA2_512 is negligible": suggest to change to "as the *additional* overhead". I believe we should cite RFC 6194 when recommending against SHA-1. "As it is not being deployed" - I suggest the softer "as it is not widely deployed" - we don't really know that nobody had ever deployed it. "and now it is known to be weak at least for a nation state" - suggest to change to "and now it is known to be weak against a nation-state attacker". Thanks, Yaron On 11/10/2015 12:33 AM, Yoav Nir wrote: > Or for a diff-style view, see the pull request: > https://github.com/ietf-ipsecme/drafts/pull/8/files > > Yoav > >> On 10 Nov 2015, at 12:30 AM, Daniel Migault >> > wrote: >> >> Hi, >> >> You can view the latest changes here: >> >> https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme-rfc4307bis >> >> We added some text to recommend the status of each recommended algorithms. >> >> On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman > > wrote: >> >> On 9 Nov 2015, at 5:48, Yoav Nir wrote: >> >> So Ive merged the changes and submitted version -01 of the draft. >> >> The stub paragraphs explaining the choices of algorithms are >> waiting to be filled. Please submit pull requests. >> >> https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis >> >> >> This is an invitation to the WG to contribute to to this draft. If >> you are already familiar with GitHub, submit pull requests as Yoav >> said. If you are not yet familiar with GitHub, feel free to send >> text to the mailing list, and one of the authors will quickly >> enter those for you in GitHub. That is, being able to use GitHub >> is *not* required for you to contribute text. >> >> --Paul Hoffman >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Nov 10 11:11:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5D1B3D37 for ; Tue, 10 Nov 2015 11:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 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, GB_I_INVITATION=-2, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0VyQl4bNJDR for ; Tue, 10 Nov 2015 11:11:42 -0800 (PST) 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 DF8E41B3D32 for ; Tue, 10 Nov 2015 11:11:41 -0800 (PST) Received: by wmvv187 with SMTP id v187so23680549wmv.1 for ; Tue, 10 Nov 2015 11:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HZcWmi5xDwu9V4Uvsd7yuHvlOPzjMN99hdPGWkIOVkU=; b=j9IsCswBq6Sv6Bj5JKWEqjAH5lH1TV3b+j2kJtlYOglAXuLucJh6vXv6wCb+DEr4MC rrTbZF9bJeZUy12pSQXDHQygKTFB/CuJdJjGOZXUS4JVsGuChUYkgn/m0hGwBJfhTg/T 5wPLLXyveE4/uy+Q5Yar3bjvfEzLOoN4CxjItpMoFpG9uTq6zqE1le52KLRtcQ+qtbC9 WvdqLDuIyFIoW2316R6zrQUma1eWGZQspNGW0pA/nGqPDcVeQPH3Xpam3Aqzrlv8DcFo Ov6zfSMEbeE/cTTKKTGMV2PQ0uQCTYr1zAqBTadftGvB7ssDPkFtMQr0xHA378PuvuQ+ PbbA== X-Received: by 10.28.217.6 with SMTP id q6mr7035220wmg.5.1447182700461; Tue, 10 Nov 2015 11:11:40 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ej10sm4141903wjd.32.2015.11.10.11.11.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Nov 2015 11:11:39 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <56421D6F.7080506@gmail.com> Date: Tue, 10 Nov 2015 21:11:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C75B957-142C-426F-ABF7-81129E2EE15B@gmail.com> References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Hoffman Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 19:11:44 -0000 > On 10 Nov 2015, at 6:38 PM, Yaron Sheffer = wrote: >=20 > A few comments, sorry for not using GitHub. >=20 > I think the following text is kinda funny: "IKEv1 is out of scope of = this document. IKEv1 is deprecated and the recommendations of this = document MUST NOT be considered for IKEv1." We cannot tell people = normatively what they can consider and what they cannot. Let's skip the = capitalized MUST NOT. Sounds reasonable, or even just saying that IKEv1 is out of scope (and = therefore we don=92t need to say another word about it) >=20 > The rationale for GCM describes why it's in the table, but seems to = argue for a MUST (rather than the SHOULD that's in the table). I guess = there's a reason why we don't have MUST, let's spell it out. Yeah. GCM is faster than CBC+HMAC and can be used for more data. That=92s = important for IPSec, much less for IKE. More importantly, GCM for IPSec = was defined in RFC 4106 in 2005 and is widely implemented. GCM for IKE = was defined three years later in RFC 5282, and because the need for = encryption performance and key longevity was much less got implemented a = lot less. (My company=92s product does not have it, for example). The = focus of this document is interoperability without security mistakes, so = GCM for IKE could be no more than a SHOULD. > "As the overhead of AUTH_HMAC_SHA2_512 is negligible": suggest to = change to "as the *additional* overhead". >=20 > I believe we should cite RFC 6194 when recommending against SHA-1. Recommending against? It=92s at MUST- for both MAC and PRF (as HMAC), = and we=92re currently saying nothing about hashes in signatures. > "As it is not being deployed" - I suggest the softer "as it is not = widely deployed" - we don't really know that nobody had ever deployed = it. Agree. I, for one, implemented it, although I have no statistics telling = me how many CP customers are actually configuring it. Probably none, = because it=92s (a) not the default, and (b) slower than GHash on all = platforms, and (c) slower than HMAC-SHA1 on older platforms. > "and now it is known to be weak at least for a nation state" - suggest = to change to "and now it is known to be weak against a nation-state = attacker". >=20 > Thanks, > Yaron >=20 > On 11/10/2015 12:33 AM, Yoav Nir wrote: >> Or for a diff-style view, see the pull request: >> https://github.com/ietf-ipsecme/drafts/pull/8/files >>=20 >> Yoav >>=20 >>> On 10 Nov 2015, at 12:30 AM, Daniel Migault >>> > = wrote: >>>=20 >>> Hi, >>>=20 >>> You can view the latest changes here: >>>=20 >>> = https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a4= 67/draft-ietf-ipsecme-rfc4307bis >>>=20 >>> We added some text to recommend the status of each recommended = algorithms. >>>=20 >>> On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman >> > wrote: >>>=20 >>> On 9 Nov 2015, at 5:48, Yoav Nir wrote: >>>=20 >>> So I=92ve merged the changes and submitted version -01 of the = draft. >>>=20 >>> The stub paragraphs explaining the choices of algorithms are >>> waiting to be filled. Please submit pull requests. >>>=20 >>> = https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4= 307bis >>>=20 >>>=20 >>> This is an invitation to the WG to contribute to to this draft. = If >>> you are already familiar with GitHub, submit pull requests as = Yoav >>> said. If you are not yet familiar with GitHub, feel free to send >>> text to the mailing list, and one of the authors will quickly >>> enter those for you in GitHub. That is, being able to use GitHub >>> is *not* required for you to contribute text. >>>=20 >>> --Paul Hoffman >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 From nobody Tue Nov 10 13:01:48 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C81B4027 for ; Tue, 10 Nov 2015 13:01:47 -0800 (PST) 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 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 kzH3kImj_Q2K for ; Tue, 10 Nov 2015 13:01:44 -0800 (PST) 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 5E14C1B4024 for ; Tue, 10 Nov 2015 13:01:44 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tAAL1dkX028284 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Nov 2015 23:01:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tAAL1cqN019955; Tue, 10 Nov 2015 23:01:38 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22082.23345.969526.729086@fireball.acr.fi> Date: Tue, 10 Nov 2015 23:01:37 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <56421D6F.7080506@gmail.com> References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Hoffman , Yoav Nir Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 21:01:47 -0000 Yaron Sheffer writes: > The rationale for GCM describes why it's in the table, but seems to > argue for a MUST (rather than the SHOULD that's in the table). I guess > there's a reason why we don't have MUST, let's spell it out. The reason for that is that it is not needed as IKEv2 SA is never used to transmit huge amounts of data, thus the speed benefits you might get from there is not needed. Also support for the combined modes do require support for RFC5282, and there are implementations which have not done that (as there is no benefits or need for them to implement it). -- kivinen@iki.fi From nobody Wed Nov 11 22:59:23 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6DA1B2A5E for ; Wed, 11 Nov 2015 22:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOkRpXnHSmdf for ; Wed, 11 Nov 2015 22:59:20 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2391B2A5D for ; Wed, 11 Nov 2015 22:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1768; q=dns/txt; s=iport; t=1447311561; x=1448521161; h=from:to:subject:date:message-id:mime-version; bh=qS0WGcHVMfAWD7LDTYcNorQWxxKLpXq5y3lszQ9/IuI=; b=Ak7P9S+U00Z7w1duAq5mbvM91Ru1O3te7byYYxXCSDSR8TveDxRE+eMF LajKyRM2mTJBTduxqIBrA9h0rTPgRoQrYp3whQF8vAGi7TLgPb81AAUzw 2hiVsc9V7YPf7eTqcUWeUTZu8h6vnFU97/hzTAoPy69TLEgEDrxEf5Z19 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DBBgCXN0RW/4cNJK1dgm5NgUi+NQENgWWHQzgUAQEBAQEBAX8LQQEBAQEBAQEBAQEEAgKDWBB3FAELAXQnBIhBoyugXQEBCAEBAQEfhlSONwWNVIh0AY0mjyyNGAEfAQFChASCIA5AEIEsCChOgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,280,1444694400"; d="scan'208,217";a="206755187" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 12 Nov 2015 06:59:20 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAC6xJLI032334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Nov 2015 06:59:19 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 00:59:19 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Thu, 12 Nov 2015 00:59:19 -0600 From: "Hema Tripathi (hetripat)" To: "ipsec@ietf.org" Thread-Topic: Clarification regarding USE_TRANSPORT_MODE notification Thread-Index: AQHRHRemeA/wCF4M30iwxdifmTVpsA== Date: Thu, 12 Nov 2015 06:59:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.142.41.50] Content-Type: multipart/alternative; boundary="_000_D26A370D14E80hetripatciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 06:59:22 -0000 --_000_D26A370D14E80hetripatciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt regarding USE_TRANSPORT_MODE in IKEv2. Does this apply to co= mplete SA offer(s) or to each proposal in the SA? In case of multiple propo= sals, should they be negotiated on the basis of the mode configured for tha= t proposal? Or should all SA offers adhere to same mode? - Regards, Hema --_000_D26A370D14E80hetripatciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <61542BF34AB6484C91FC5F199BA0CEBD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi,


I have a doubt regarding US= E_TRANSPORT_MODE in IKEv2. Does this apply to complete SA offer(s) or to ea= ch proposal in the SA? In case of multiple proposals, should they be negoti= ated on the basis of the mode configured for that proposal? Or should all SA offers adhere to same mode?


—

Regards,

Hema

--_000_D26A370D14E80hetripatciscocom_-- From nobody Wed Nov 11 23:17:52 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEED31A1B67 for ; Wed, 11 Nov 2015 23:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euy1pdbsIyA2 for ; Wed, 11 Nov 2015 23:17:49 -0800 (PST) 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 2C9031A1B6B for ; Wed, 11 Nov 2015 23:17:49 -0800 (PST) Received: by wmec201 with SMTP id c201so77917086wme.1 for ; Wed, 11 Nov 2015 23:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=oqQGZooshw5CySGH4xuniyW+TEk/kcDyzyuaWT1AUH8=; b=yCzLQUveXQm+LMxrBc2/nAB6kT+9plI7rAl7JLkvhhf67CTqeA614eLG9cWJT3MWdb W/FZEru/TF3y3fjvcAH8UnYSx9wVnNoKEKWVcuL04QQPv3+6hbW8e3STY1lnYI1nh3aO Gq1Zzizmu++rDktptCcsSqIxFy8dVq0EZ5rMwi4XUPMdZpWkmKB7o3GyKraC0nkVNl5E BEfCALjiXqyw427MJSxx+Bo1qyo1Qo3k1+6R8xEGEfTmvd4kXrQgW6XnYbq/zEOCRuhL usLBQylmYwhkh/8afkBsaD/+P5XYCWfNzHaC+Aq/WYlxQ2SYVjtD8CprH6Dh6rpaYsh8 tpmA== X-Received: by 10.194.142.142 with SMTP id rw14mr14719526wjb.100.1447312667674; Wed, 11 Nov 2015 23:17:47 -0800 (PST) Received: from yoavs-mbp.mshome.net ([176.13.16.49]) by smtp.gmail.com with ESMTPSA id 71sm13416727wmm.24.2015.11.11.23.17.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Nov 2015 23:17:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E223CE2-DE21-4E4E-BA63-D816DCE5C5CE" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: Date: Thu, 12 Nov 2015 09:17:41 +0200 Message-Id: <3EBC51D8-B4FF-456B-9605-9950EEDE8AD6@gmail.com> References: To: "Hema Tripathi (hetripat)" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 07:17:51 -0000 --Apple-Mail=_2E223CE2-DE21-4E4E-BA63-D816DCE5C5CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Hema USE_TRANSPORT_MODE is a notification, so it is outside the structures in = the SA payload. As a consequence, the protocol does not allow you to propose AES-GCM in = transport mode or ChaCha20/Poly1305 in tunnel mode.=20 Note also that USE_TRANSPORT_MODE does not force transport mode. It only = shows support. The responder can then choose to include it (agreeing to = use transport mode) or not (forcing you back to tunnel). And yes, notifications were not supposed to be used for negotiations. HTH, Yoav > On 12 Nov 2015, at 8:59 AM, Hema Tripathi (hetripat) = wrote: >=20 > Hi, >=20 > I have a doubt regarding USE_TRANSPORT_MODE in IKEv2. Does this apply = to complete SA offer(s) or to each proposal in the SA? In case of = multiple proposals, should they be negotiated on the basis of the mode = configured for that proposal? Or should all SA offers adhere to same = mode? >=20 > =E2=80=94 > Regards, > Hema > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_2E223CE2-DE21-4E4E-BA63-D816DCE5C5CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Hema

USE_TRANSPORT_MODE is a notification, so it is outside the = structures in the SA payload.

As a consequence, the protocol does not allow you to propose = AES-GCM in transport mode or ChaCha20/Poly1305 in tunnel = mode. 

Note= also that USE_TRANSPORT_MODE does not force transport mode. It only = shows support. The responder can then choose to include it (agreeing to = use transport mode) or not (forcing you back to tunnel).

And yes, notifications = were not supposed to be used for negotiations.

HTH,

Yoav

On = 12 Nov 2015, at 8:59 AM, Hema Tripathi (hetripat) <hetripat@cisco.com> = wrote:

Hi,

I = have a doubt regarding USE_TRANSPORT_MODE in IKEv2. Does this apply to = complete SA offer(s) or to each proposal in the SA? In case of multiple = proposals, should they be negotiated on the basis of the mode configured for that proposal? Or should all SA offers adhere to same = mode?

=E2=80=94
Regards,
Hema
_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_2E223CE2-DE21-4E4E-BA63-D816DCE5C5CE-- From nobody Wed Nov 11 23:26:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA44F1A6F8A for ; Wed, 11 Nov 2015 23:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T53h5FgYBV1z for ; Wed, 11 Nov 2015 23:26:33 -0800 (PST) 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 438DC1A1EF4 for ; Wed, 11 Nov 2015 23:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8583; q=dns/txt; s=iport; t=1447313193; x=1448522793; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lSxsgjbPfOHozyLHCRtWVxLw1xp+GZ6heXlC1H11qW0=; b=fcftx3vqFpofNlyz0Fchkn3kk/zdSUnGur2//qvpLH8c6S4B8LMAxjyq a7UpifgLhrtjNc4L9QyNewRfsMxK0BdKTWYTDFqTT/VZ+w1KSAilj7lm9 jAg4CJ649zpbQEtcXYU+JwuftgTJdor4X6rWnvGCv3XmMN0+9Rm+/st8G I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQCkPkRW/5xdJa1egm5NU28GvjUBD?= =?us-ascii?q?YFlFwEJhW8CgTE4FAEBAQEBAQGBCoQ0AQEBBAEBAWsJAhACAQgOAwMBAigHIQY?= =?us-ascii?q?LFAkIAgQOBYgZAxINvw8NhGMBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6CU?= =?us-ascii?q?4IoDYQxBY1UhRODYQGLMYF1jyyFRodSAR8BAUKEBHKENoEHAQEB?= X-IronPort-AV: E=Sophos; i="5.20,280,1444694400"; d="scan'208,217"; a="46135353" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 12 Nov 2015 07:26:32 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tAC7QWuO008732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2015 07:26:32 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 01:26:31 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Thu, 12 Nov 2015 01:26:31 -0600 From: "Hema Tripathi (hetripat)" To: Yoav Nir Thread-Topic: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification Thread-Index: AQHRHRemeA/wCF4M30iwxdifmTVpsJ6YXtWAgABfLoA= Date: Thu, 12 Nov 2015 07:26:31 +0000 Message-ID: References: <3EBC51D8-B4FF-456B-9605-9950EEDE8AD6@gmail.com> In-Reply-To: <3EBC51D8-B4FF-456B-9605-9950EEDE8AD6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.142.41.50] Content-Type: multipart/alternative; boundary="_000_D26A3BC614E8Ahetripatciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 07:26:36 -0000 --_000_D26A3BC614E8Ahetripatciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Yoav. If responder chooses to decline it, then does it force the fallback on tunn= el mode? I am asking this because sometime back I had a doubt regarding the= following lines in RFC 5996. " If responder declines the request, the Child SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA." It seemed to me that this was implementation's choice to establish the SA i= n tunnel mode or send "NO_PROPOSAL_CHOSEN" in this case. -- Regards, Hema From: Yoav Nir > Date: Thursday, 12 November 2015 12:47 pm To: Hema Tripathi > Cc: "ipsec@ietf.org" > Subject: Re: [IPsec] Clarification regarding USE_TRANSPORT_MODE notificatio= n Hi, Hema USE_TRANSPORT_MODE is a notification, so it is outside the structures in th= e SA payload. As a consequence, the protocol does not allow you to propose AES-GCM in tra= nsport mode or ChaCha20/Poly1305 in tunnel mode. Note also that USE_TRANSPORT_MODE does not force transport mode. It only sh= ows support. The responder can then choose to include it (agreeing to use t= ransport mode) or not (forcing you back to tunnel). And yes, notifications were not supposed to be used for negotiations. HTH, Yoav On 12 Nov 2015, at 8:59 AM, Hema Tripathi (hetripat) > wrote: Hi, I have a doubt regarding USE_TRANSPORT_MODE in IKEv2. Does this apply to co= mplete SA offer(s) or to each proposal in the SA? In case of multiple propo= sals, should they be negotiated on the basis of the mode configured for tha= t proposal? Or should all SA offers adhere to same mode? - Regards, Hema _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_D26A3BC614E8Ahetripatciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <24718DB10D7A4749BDEFC1DB90FAA48E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Yoav.

If responder chooses to decline it, then does it force the fallback on tunn= el mode? I am asking this because sometime back I had a doubt regarding the= following lines in RFC 5996. 

 “ If  responder declines the request, the Child= SA will be established in

   tunnel mode.&n= bsp; If this is unacceptable to the initiator, the initiator

   MUST delete th= e SA.”


It seemed= to me that this was implementation’s choice to establish the SA in t= unnel mode or send “NO_PROPOSAL_<= /span>CHOSEN” in this case. 


--

Regards,<= /p>

Hema



From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thursday, 12 November 2015 12= :47 pm
To: Hema Tripathi <hetripat@cisco.com>
Cc: "ipsec@ietf.org" <ips= ec@ietf.org>
Subject: Re: [IPsec] Clarification = regarding USE_TRANSPORT_MODE notification

Hi, Hema

USE_TRANSPORT_MODE is a notification, so it is outside the = structures in the SA payload.

As a consequence, the protocol does not allow you to propos= e AES-GCM in transport mode or ChaCha20/Poly1305 in tunnel mode. 

Note also that USE_TRANSPORT_MODE does not force transport = mode. It only shows support. The responder can then choose to include it (a= greeing to use transport mode) or not (forcing you back to tunnel).

And yes, notifications were not supposed to be used for neg= otiations.

HTH,

Yoav

On 12 Nov 2015, at 8:59 AM, Hema Tripathi (hetripat) <hetripat@cisco.com> w= rote:

Hi,

I have a doubt= regarding USE_TRANSPORT_MODE in IKEv2. Does this apply to complete SA offe= r(s) or to each proposal in the SA? In case of multiple proposals, should t= hey be negotiated on the basis of the mode configured for that proposal? Or should all SA offers adhere to same = mode?

—
Regards,
Hema
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

--_000_D26A3BC614E8Ahetripatciscocom_-- From nobody Thu Nov 12 02:14:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C0A1B2E1D for ; Thu, 12 Nov 2015 02:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 4T0TpoEfqaID for ; Thu, 12 Nov 2015 02:14:10 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 C88451B2E2C for ; Thu, 12 Nov 2015 02:14:09 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tACADx6F009442 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2015 11:14:00 +0100 X-Hashcash: 1:22:151112:ipsec@ietf.org::LsSIER84Z9KrIx4l:FQm1 From: Simon Josefsson To: ipsec@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Thu, 12 Nov 2015 11:13:58 +0100 Message-ID: <87bnaztti1.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-safecurves? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 10:14:11 -0000 --=-=-= Content-Type: text/plain There have been no additional comment on the list, and we have had one positive review from an implementer [1]. Is there any reason to wait further with WG last calling this document? Its dependency on draft-irtf-cfrg-curves is in the RFC editors queue already. Thanks, /Simon [1] https://mailarchive.ietf.org/arch/msg/ipsec/vS1sy2ROhA6twEe7QwX1ISXtLVM --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWRGZmAAoJEIYLf7sy+BGdRbwIAKJ148+Ivh6Ja+ysZ9mZqIIr /2jQR1VZWInc0wxo4j9Q9K3bpTcrU5fqM9O+o5bNkNCL6Uer8WJwtaGdBxVPzwmy MuvDzKhwYZU2fUmBvIFB4tew8kh66B0Usot6vTd9tfEMtObhy7hyY3oFNK8j4n/V qhhaVsl5d9Sj7Ri0jMVsYhsn8S5BK9oTloNCs0Y3ampYl9nRwz4S7y5wgFmgnjWI zWC3j8jZvhv6NJJI5sixehkt28R5763nT5knQOl9N06fJnah6EgUH+znk27/UmpT vsEHwz+iU3oX2eVOZUPfXDZN6F8AhLgolRUzfcnWHVru3x05yX0eA6I2N5p5b1I= =MPog -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 03:45:41 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD91A1BB0 for ; Thu, 12 Nov 2015 03:45:40 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNZCh0XzL7NA for ; Thu, 12 Nov 2015 03:45:38 -0800 (PST) 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 756691A1B92 for ; Thu, 12 Nov 2015 03:45:38 -0800 (PST) Received: by wmec201 with SMTP id c201so28662774wme.0 for ; Thu, 12 Nov 2015 03:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QeYrRVaBaUmb7Q7nurp2ZqXaIqYANXc1OZMwdxKdrrw=; b=beq4StqNU2Q7KGk7ommnsfCsHQItjhTZkLeOJVpVlN13mTThpXVxSHEKbz2eS7gRm9 VLtK8xT4686YdK3YpDF8JK9dppFnQY0dz7w5cTszexnfAjWNy6sVGKkk+M5vgBXxeSFh c/Ix1h8oMNSS6eRNH36Z4/rGjV7EPTIPl47NTP9+Yxl5bvEGX8NHhnuDRCuhKSNPyAnN rGWR8uLlRohtd2BHpVAABjnw5NuxMD5tRllsSyXfyr0AdU07KDoKYH7VjSF7LK99rhAK +phZzM63e7uLhYlMp4rV1vSlnwgdwc5MbzHjqYnDXE3N1FR6YNV+QXDFMQAKHjm47rCB Qa7A== X-Received: by 10.28.45.72 with SMTP id t69mr27660619wmt.32.1447328737143; Thu, 12 Nov 2015 03:45:37 -0800 (PST) Received: from [172.24.249.179] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id h7sm14034259wjz.7.2015.11.12.03.45.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Nov 2015 03:45:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <87bnaztti1.fsf@latte.josefsson.org> Date: Thu, 12 Nov 2015 13:45:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24AFF548-28A6-422E-95D0-9C4AEBDC958B@gmail.com> References: <87bnaztti1.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-safecurves? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 11:45:40 -0000 > On 12 Nov 2015, at 12:13 PM, Simon Josefsson = wrote: >=20 > There have been no additional comment on the list, and we have had one > positive review from an implementer [1]. Is there any reason to wait > further with WG last calling this document? Its dependency on > draft-irtf-cfrg-curves is in the RFC editors queue already. >=20 > Thanks, > /Simon >=20 > [1] = https://mailarchive.ietf.org/arch/msg/ipsec/vS1sy2ROhA6twEe7QwX1ISXtLVM OK, so here=E2=80=99s two comments: 1. See Ilari=E2=80=99s pr for RFC4492bis [2]. Do we want similar name = changes? 2. We make no mention of EdDSA signatures. I know they should just work = with RFC 7427, but do we want to mention them and give the OIDs? Yoav [2] https://github.com/tlswg/rfc4492bis/pull/16 From nobody Thu Nov 12 03:59:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4144B1A6F92 for ; Thu, 12 Nov 2015 03:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 sGuTQPgBujFJ for ; Thu, 12 Nov 2015 03:59:53 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 4A9F01A6F8F for ; Thu, 12 Nov 2015 03:59:52 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tACBxa8Z021939 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Nov 2015 12:59:37 +0100 From: Simon Josefsson To: Yoav Nir References: <87bnaztti1.fsf@latte.josefsson.org> <24AFF548-28A6-422E-95D0-9C4AEBDC958B@gmail.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151112:ynir.ietf@gmail.com::DCyhbL9J0GCYEJ5J:1I8/ X-Hashcash: 1:22:151112:ipsec@ietf.org::I1GRCiPjVzRIZ+tJ:DSep Date: Thu, 12 Nov 2015 12:59:35 +0100 In-Reply-To: <24AFF548-28A6-422E-95D0-9C4AEBDC958B@gmail.com> (Yoav Nir's message of "Thu, 12 Nov 2015 13:45:35 +0200") Message-ID: <877flntom0.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-safecurves? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 11:59:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir writes: >> On 12 Nov 2015, at 12:13 PM, Simon Josefsson wrote: >>=20 >> There have been no additional comment on the list, and we have had one >> positive review from an implementer [1]. Is there any reason to wait >> further with WG last calling this document? Its dependency on >> draft-irtf-cfrg-curves is in the RFC editors queue already. >>=20 >> Thanks, >> /Simon >>=20 >> [1] https://mailarchive.ietf.org/arch/msg/ipsec/vS1sy2ROhA6twEe7QwX1ISXt= LVM > > OK, so here=E2=80=99s two comments: Thank you! > 1. See Ilari=E2=80=99s pr for RFC4492bis [2]. Do we want similar name > changes? We could use a similar change when we talk about key agreement explicitly. When talking about the curves the traditional names are fine. > 2. We make no mention of EdDSA signatures. I know they should just > work with RFC 7427, but do we want to mention them and give the OIDs? Support for EdDSA might be a completely different draft. I'm not convinced RFC 7427 plus an OID is sufficient to get EdDSA to work in an interoperable manner. Is there interest from the WG in pursuing EdDSA signing in IPSEC? If so we could add it to this draft or write a new one. /Simon > Yoav > > [2] https://github.com/tlswg/rfc4492bis/pull/16 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWRH8nAAoJEIYLf7sy+BGdkGYH/3iZJa51fZkaHs01ozrF8crb bztm4UHyeYDfwvLpJvMeadLRIBsqFvCyuQ7qHS4P6DI8vjX/TDZpAi7La9tyh+Od //Xpn5onAXSPzeVmmPkxr49KcLHl2GEiX0D1f87JFEcMG777HbWhiMu4uO/oUh/G FG3+zqL2ru1ADbFFu1JP58cJN57rn7m2fKPsriEd7hio+c3z1ReMh8bzqGScW/vu zWiZ/9CXWd2R/vhs4veXCNXkifVObaHFWM0b8uP52pVLLhrauU7V52EpOFr5yOp1 RT00WC7/Uam3PLBXifGTDtk1nwOP3spybB7JkSv9bfTy+dBTjJp99XzW5DTq1co= =6k9C -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 08:05:06 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84A1A1A4D for ; Mon, 16 Nov 2015 08:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 f726WHNpeonE for ; Mon, 16 Nov 2015 08:05:02 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 186A11A1A0C for ; Mon, 16 Nov 2015 08:05:02 -0800 (PST) Received: by wmww144 with SMTP id w144so116767705wmw.1 for ; Mon, 16 Nov 2015 08:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gM38csexfTlhzbgi5u2yhYihk3d/q3JlOMQHQeT3IWA=; b=Ve3d6JxnmnDYLkcS2Rhu+G3voneFEI6kPzRfGUjm5d7BKie6v5NT+4r0ytcmKIc+wg sTdou39OHomXsFcjOJu1/88+SwnRjJMZjPJusj/cLVZZ6jAYDF4O5UvvWh+OVQxNhL9u U6tz5U3oixtxSB7Tco+vTQtniU6GgNKaQA2BYKkpOaQ6X/6zUjoe8/y7RU3i1duvfWAb Eiw5HMmkhlkqe1ZAB8Y6QVJ7rr+rwEh7EQ/iDAJgASwLmFFQTAOYcy38ohtUM7YeXA62 PgLhwdwwG0Q/j2BMIJRV5dUuz3EVNBmtQgH8XWA/1Y6vfsj/GhnUeBm7XRMlyTLfD6qq Q2Cg== MIME-Version: 1.0 X-Received: by 10.195.18.6 with SMTP id gi6mr36243190wjd.83.1447689900663; Mon, 16 Nov 2015 08:05:00 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Mon, 16 Nov 2015 08:05:00 -0800 (PST) In-Reply-To: <22082.23345.969526.729086@fireball.acr.fi> References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> Date: Mon, 16 Nov 2015 11:05:00 -0500 X-Google-Sender-Auth: o-kmQZM-Ph19Ecw_olzREKYykvI Message-ID: From: Daniel Migault To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11c28b6e46488a0524aa9201 Archived-At: Cc: IPsecME WG , Paul Hoffman , Yoav Nir Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 16:05:04 -0000 --001a11c28b6e46488a0524aa9201 Content-Type: text/plain; charset=UTF-8 Hi, Thank you Yaron for your comments. Please find the new update ot the draft: https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002 Comment 1: IKEv1 is out of scope of this document. IKEv1 is deprecated and the recommendations of this documentmust not be considered for IKEv1. I change MUST NOT in must not. I left the whole sentence as I beleive, it provides the reason why IKEv1 is not in scope and state clearly that applying considerations in this document to IKEv1 is a bad idea. Comment 2: I added some clarifying text on why not MUST. To me the obvious reason is that an algorithm not mentioned in RFC4307 should not have a status greater than SHOULD -- unless otherwise of course ;-). I though we had this explanation somewhere, but maybe it is missing and should be added in the intro for example. I also provided dome explanation why ESP and IKEv2 are in a different race which resulted in having AES-GCM not widely deployed for IKEv2 Comment 3: "As it is not being deployed" as been replaced by "as it is not widely deployed" "and now it is known to be weak at least for a nation state" has been changed to "and now it is known to be weak against a nation-state attacker". Acknowledgement section has also been updated. BR, Daniel On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen wrote: > Yaron Sheffer writes: > > The rationale for GCM describes why it's in the table, but seems to > > argue for a MUST (rather than the SHOULD that's in the table). I guess > > there's a reason why we don't have MUST, let's spell it out. > > The reason for that is that it is not needed as IKEv2 SA is never used > to transmit huge amounts of data, thus the speed benefits you might > get from there is not needed. Also support for the combined modes do > require support for RFC5282, and there are implementations which have > not done that (as there is no benefits or need for them to implement > it). > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a11c28b6e46488a0524aa9201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you Yaron= for your comments. Please find the new update ot the draft:

https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c31= 55d49bca0002

Comment 1:
IKEv1 is out of scope of this documen= t. IKEv1 is deprecated and the recommendations of this documentmust not be = considered for IKEv1.

I change MUST NOT in must not. I left th= e whole sentence as I beleive, it provides the reason why IKEv1 is not in s= cope and state clearly that applying considerations in this document to IKE= v1 is a bad idea.

Comment 2:
I added some clarifying text o= n why not MUST. To me the obvious reason is that an algorithm not mentioned= in RFC4307 should not have a status greater than SHOULD -- unless otherwis= e of course ;-). I though we had this explanation somewhere, but maybe it i= s missing and should be added in the intro for example.
=C2=A0
I also provided dome explanation why ESP and IKEv2 are in a differen= t race which resulted in having AES-GCM not widely deployed for IKEv2
Comment 3:
"As it is not being deployed" as been replaced by= "as it is not=20 widely deployed"

"and now it is known to be weak at least for a nation state" has = been changed to "and now it is known to be weak against a nation-state= =20 attacker".

Acknowledgement section has also been updated.

B= R,
Daniel


On T= ue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <kivinen@iki.fi> wrot= e:
Yaron Sheffer writes:=
> The rationale for GCM describes why it's in the table, but seems t= o
> argue for a MUST (rather than the SHOULD that's in the table). I g= uess
> there's a reason why we don't have MUST, let's spell it ou= t.

The reason for that is that it is not needed as IKEv2 SA is never us= ed
to transmit huge amounts of data, thus the speed benefits you might
get from there is not needed. Also support for the combined modes do
require support for RFC5282, and there are implementations which have
not done that (as there is no benefits or need for them to implement
it).
--
kivinen@iki.fi

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

--001a11c28b6e46488a0524aa9201-- From nobody Mon Nov 16 09:41:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32111A92AC for ; Mon, 16 Nov 2015 09:41:37 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeeNrqCUGn0h for ; Mon, 16 Nov 2015 09:41:36 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 09E751A916A for ; Mon, 16 Nov 2015 09:41:36 -0800 (PST) Received: by pacdm15 with SMTP id dm15so181402778pac.3 for ; Mon, 16 Nov 2015 09:41:35 -0800 (PST) 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-type:content-transfer-encoding; bh=5cOZWlKiSBRBuToyLwp7fIxxmYPz851PN1t3UH9jcMw=; b=PLvYp/AoBtI0tND3Pnf6OVLXER8pmAhxeBdJG+1eb7UYhep6B6YyNmLZ+OaeIB+tYH AIhRx8sRIWVkOv1Hzo7IhqMuLx0yV73tctDCby+O+B4jAXXBwFbaF8IMW11KuV5Fg+rz 4jzhhGPzWfz3uovP7JcA24K7JDhw3jqFaYIGpzqcCQfCskYSCmxMwZoD2I4NMXoyFOaM qXhKSyZieLWPt4FFYRrfHs89siuJRSiFN1JVXcNawkOQYCe+6soEsXsC8QoFmSATob7Q z0Hq+G36dQqU66EkQI8dfzuZp7GVXZIK5pHPQCzFpP+8p+JnX0+hHKWjzPWIhrg9cm5y C1EA== X-Received: by 10.66.146.130 with SMTP id tc2mr55513191pab.26.1447695695644; Mon, 16 Nov 2015 09:41:35 -0800 (PST) Received: from [172.18.133.61] (cowboy.intuit.com. [65.204.229.11]) by smtp.googlemail.com with ESMTPSA id fn4sm28864085pab.46.2015.11.16.09.41.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Nov 2015 09:41:34 -0800 (PST) To: Daniel Migault , Tero Kivinen References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> From: Yaron Sheffer Message-ID: <564A1549.1010001@gmail.com> Date: Mon, 16 Nov 2015 19:41:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG , Paul Hoffman , Yoav Nir Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 17:41:37 -0000 Looks good. One small correction: many IKEv2 have not implemented => many IKEv2 implementations do not include Thanks, Yaron On 11/16/2015 06:05 PM, Daniel Migault wrote: > Hi, > > Thank you Yaron for your comments. Please find the new update ot the draft: > > https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002 > > Comment 1: > IKEv1 is out of scope of this document. IKEv1 is deprecated and the > recommendations of this documentmust not be considered for IKEv1. > > I change MUST NOT in must not. I left the whole sentence as I beleive, > it provides the reason why IKEv1 is not in scope and state clearly that > applying considerations in this document to IKEv1 is a bad idea. > > Comment 2: > I added some clarifying text on why not MUST. To me the obvious reason > is that an algorithm not mentioned in RFC4307 should not have a status > greater than SHOULD -- unless otherwise of course ;-). I though we had > this explanation somewhere, but maybe it is missing and should be added > in the intro for example. > > I also provided dome explanation why ESP and IKEv2 are in a different > race which resulted in having AES-GCM not widely deployed for IKEv2 > > Comment 3: > "As it is not being deployed" as been replaced by "as it is not widely > deployed" > > "and now it is known to be weak at least for a nation state" has been > changed to "and now it is known to be weak against a nation-state attacker". > > Acknowledgement section has also been updated. > > BR, > Daniel > > > On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen > wrote: > > Yaron Sheffer writes: > > The rationale for GCM describes why it's in the table, but seems to > > argue for a MUST (rather than the SHOULD that's in the table). I guess > > there's a reason why we don't have MUST, let's spell it out. > > The reason for that is that it is not needed as IKEv2 SA is never used > to transmit huge amounts of data, thus the speed benefits you might > get from there is not needed. Also support for the combined modes do > require support for RFC5282, and there are implementations which have > not done that (as there is no benefits or need for them to implement > it). > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Wed Nov 18 13:04:46 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300831B2EF2 for ; Wed, 18 Nov 2015 13:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 IbgcI72QHAPD for ; Wed, 18 Nov 2015 13:04:42 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 A5FEC1B2C16 for ; Wed, 18 Nov 2015 13:04:41 -0800 (PST) Received: by wmww144 with SMTP id w144so89920519wmw.0 for ; Wed, 18 Nov 2015 13:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2OD23jskFRTQU4Tk5fBbFCKlMiMoW32jIKEn2eR54/U=; b=wYJaaurZCZnLlcIkagHQfn+RjPcmPgJRKDUeK0UXpzdmVtgCJECIJBsNIirQ4TNefk 3ei9JjUy92YejJdKn1InDf0adiZ3WHmuLq8ruCgc5yor6eezF1hpBbrGINAkds4+k1LR RortvyVtenparc0SmE5/GuopIFOydzRPLW4srSiBpOiyuIKQV8sin3yf1dhOoW3mIzlI /pdlEO/g/TiQ1INJwRuW/HurKvzstZUnClq6GigRmGZpk1qZcjlrNv56NhCcmZlzDn0E iTKDJ2EvLvLLUfNLZnwFgWRZd5HODLvodVn9AIDHKxS6mob0Il32nAlS3DE1egVSuJFr b2uA== MIME-Version: 1.0 X-Received: by 10.28.23.211 with SMTP id 202mr6142465wmx.81.1447880680232; Wed, 18 Nov 2015 13:04:40 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Wed, 18 Nov 2015 13:04:40 -0800 (PST) In-Reply-To: <564A1549.1010001@gmail.com> References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Wed, 18 Nov 2015 16:04:40 -0500 X-Google-Sender-Auth: eEqQZE4VHTvsEU8KEXh2DxGHDlM Message-ID: From: Daniel Migault To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a1147181a9f73150524d6fd41 Archived-At: Cc: IPsecME WG , Paul Hoffman , Tero Kivinen , Yoav Nir Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 21:04:44 -0000 --001a1147181a9f73150524d6fd41 Content-Type: text/plain; charset=UTF-8 Hi Yaron, I just committed your correction. You are right this is much better. BR, Daniel On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer wrote: > Looks good. One small correction: > > many IKEv2 have not implemented => many IKEv2 implementations do not > include > > Thanks, > Yaron > > > On 11/16/2015 06:05 PM, Daniel Migault wrote: > >> Hi, >> >> Thank you Yaron for your comments. Please find the new update ot the >> draft: >> >> >> https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002 >> >> Comment 1: >> IKEv1 is out of scope of this document. IKEv1 is deprecated and the >> recommendations of this documentmust not be considered for IKEv1. >> >> I change MUST NOT in must not. I left the whole sentence as I beleive, >> it provides the reason why IKEv1 is not in scope and state clearly that >> applying considerations in this document to IKEv1 is a bad idea. >> >> Comment 2: >> I added some clarifying text on why not MUST. To me the obvious reason >> is that an algorithm not mentioned in RFC4307 should not have a status >> greater than SHOULD -- unless otherwise of course ;-). I though we had >> this explanation somewhere, but maybe it is missing and should be added >> in the intro for example. >> >> I also provided dome explanation why ESP and IKEv2 are in a different >> race which resulted in having AES-GCM not widely deployed for IKEv2 >> >> Comment 3: >> "As it is not being deployed" as been replaced by "as it is not widely >> deployed" >> >> "and now it is known to be weak at least for a nation state" has been >> changed to "and now it is known to be weak against a nation-state >> attacker". >> >> Acknowledgement section has also been updated. >> >> BR, >> Daniel >> >> >> On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen > > wrote: >> >> Yaron Sheffer writes: >> > The rationale for GCM describes why it's in the table, but seems to >> > argue for a MUST (rather than the SHOULD that's in the table). I >> guess >> > there's a reason why we don't have MUST, let's spell it out. >> >> The reason for that is that it is not needed as IKEv2 SA is never used >> to transmit huge amounts of data, thus the speed benefits you might >> get from there is not needed. Also support for the combined modes do >> require support for RFC5282, and there are implementations which have >> not done that (as there is no benefits or need for them to implement >> it). >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> 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 > --001a1147181a9f73150524d6fd41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yaron,=C2=A0

I just committed your c= orrection. You are right this is much better.

BR,= =C2=A0
Daniel

On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer <yar= onf.ietf@gmail.com> wrote:
= Looks good. One small correction:

many IKEv2 have not implemented =3D> many IKEv2 implementations do not i= nclude

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


On 11/16/2015 06:05 PM, Daniel Migault wrote:
Hi,

Thank you Yaron for your comments. Please find the new update ot the draft:=

https://github.com/mgl= t/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002

Comment 1:
IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this documentmust not be considered for IKEv1.

I change MUST NOT in must not. I left the whole sentence as I beleive,
it provides the reason why IKEv1 is not in scope and state clearly that
applying considerations in this document to IKEv1 is a bad idea.

Comment 2:
I added some clarifying text on why not MUST. To me the obvious reason
is that an algorithm not mentioned in RFC4307 should not have a status
greater than SHOULD -- unless otherwise of course ;-). I though we had
this explanation somewhere, but maybe it is missing and should be added
in the intro for example.

I also provided dome explanation why ESP and IKEv2 are in a different
race which resulted in having AES-GCM not widely deployed for IKEv2

Comment 3:
"As it is not being deployed" as been replaced by "as it is = not widely
deployed"

"and now it is known to be weak at least for a nation state" has = been
changed to "and now it is known to be weak against a nation-state atta= cker".

Acknowledgement section has also been updated.

BR,
Daniel


On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <kivinen@iki.fi
<mailto:kivinen@iki.= fi>> wrote:

=C2=A0 =C2=A0 Yaron Sheffer writes:
=C2=A0 =C2=A0 > The rationale for GCM describes why it's in the tabl= e, but seems to
=C2=A0 =C2=A0 > argue for a MUST (rather than the SHOULD that's in t= he table). I guess
=C2=A0 =C2=A0 > there's a reason why we don't have MUST, let'= ;s spell it out.

=C2=A0 =C2=A0 The reason for that is that it is not needed as IKEv2 SA is n= ever used
=C2=A0 =C2=A0 to transmit huge amounts of data, thus the speed benefits you= might
=C2=A0 =C2=A0 get from there is not needed. Also support for the combined m= odes do
=C2=A0 =C2=A0 require support for RFC5282, and there are implementations wh= ich have
=C2=A0 =C2=A0 not done that (as there is no benefits or need for them to im= plement
=C2=A0 =C2=A0 it).
=C2=A0 =C2=A0 --
 =C2=A0 =C2=A0 kivinen@i= ki.fi <mailto:ki= vinen@iki.fi>

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 IPsec mailing list
=C2=A0 =C2=A0 IPsec@iet= f.org <mailto:IP= sec@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ips= ec



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

--001a1147181a9f73150524d6fd41-- From nobody Fri Nov 20 08:28:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905591B3711 for ; Fri, 20 Nov 2015 08:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 nWYR-IEvIQzJ for ; Fri, 20 Nov 2015 08:28:23 -0800 (PST) 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 78C791B370C for ; Fri, 20 Nov 2015 08:28:22 -0800 (PST) Received: by wmvv187 with SMTP id v187so79495833wmv.1 for ; Fri, 20 Nov 2015 08:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=e2UBKLjUszRrZwr/xWlmR1IUH+E88qM65w5VArOiMjU=; b=PC1y2dSNzvE3FBX6aJEhpjKXmFhry3bHuJNyFlIqWkn+Qm9tBHKnCxAqXsEh/M5XAA m+IJajprtTgLBLyz+X7SdUXWNlcv0K+KoE2pK3zIj4MQ9z9avB0Rt6Miv6GDQdMfgQp/ FKftTkzqA6DFb7aKgxPxvt+n03bM9L8/yT7BJGIg6mYLh2llsTk+8TfD2S7x480FN4OH qceG8aMYJCDXQ2TTytF0ZMkD2WgtVyJX+wPn2t5gXsZrm2PcvAQvM2ktYzDd/6X1LCwT ZHeMTBQwSg9w4cH4G1e+iGMBYjSYrIT7E1CuUY2NnzRplGXaqr7XMp8JUvhPRnpwpbAH krTA== MIME-Version: 1.0 X-Received: by 10.28.32.65 with SMTP id g62mr798580wmg.81.1448036901111; Fri, 20 Nov 2015 08:28:21 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Fri, 20 Nov 2015 08:28:21 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Fri, 20 Nov 2015 11:28:21 -0500 X-Google-Sender-Auth: Vp6zLOZz8BFzH2qS6zbb-WZzq_s Message-ID: From: Daniel Migault To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a113c83461cd0270524fb5d04 Archived-At: Cc: IPsecME WG , Paul Hoffman , Tero Kivinen , Yoav Nir Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 16:28:26 -0000 --001a113c83461cd0270524fb5d04 Content-Type: text/plain; charset=UTF-8 Hi, Please find an new update: https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD instead of a MAY. I was suprised PRF was already SHOULD. In each case, explanation text has been added. Change 2: Titles of the subsections have also been updated to better fit IANA designation. Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 / Type 2 / Type 4 to Type 1/ Type 2/ Type 3 / Type 4. Feel free to comment. BR, Daniel On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault wrote: > Hi Yaron, > > I just committed your correction. You are right this is much better. > > BR, > Daniel > > On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer > wrote: > >> Looks good. One small correction: >> >> many IKEv2 have not implemented => many IKEv2 implementations do not >> include >> >> Thanks, >> Yaron >> >> >> On 11/16/2015 06:05 PM, Daniel Migault wrote: >> >>> Hi, >>> >>> Thank you Yaron for your comments. Please find the new update ot the >>> draft: >>> >>> >>> https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002 >>> >>> Comment 1: >>> IKEv1 is out of scope of this document. IKEv1 is deprecated and the >>> recommendations of this documentmust not be considered for IKEv1. >>> >>> I change MUST NOT in must not. I left the whole sentence as I beleive, >>> it provides the reason why IKEv1 is not in scope and state clearly that >>> applying considerations in this document to IKEv1 is a bad idea. >>> >>> Comment 2: >>> I added some clarifying text on why not MUST. To me the obvious reason >>> is that an algorithm not mentioned in RFC4307 should not have a status >>> greater than SHOULD -- unless otherwise of course ;-). I though we had >>> this explanation somewhere, but maybe it is missing and should be added >>> in the intro for example. >>> >>> I also provided dome explanation why ESP and IKEv2 are in a different >>> race which resulted in having AES-GCM not widely deployed for IKEv2 >>> >>> Comment 3: >>> "As it is not being deployed" as been replaced by "as it is not widely >>> deployed" >>> >>> "and now it is known to be weak at least for a nation state" has been >>> changed to "and now it is known to be weak against a nation-state >>> attacker". >>> >>> Acknowledgement section has also been updated. >>> >>> BR, >>> Daniel >>> >>> >>> On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen >> > wrote: >>> >>> Yaron Sheffer writes: >>> > The rationale for GCM describes why it's in the table, but seems to >>> > argue for a MUST (rather than the SHOULD that's in the table). I >>> guess >>> > there's a reason why we don't have MUST, let's spell it out. >>> >>> The reason for that is that it is not needed as IKEv2 SA is never >>> used >>> to transmit huge amounts of data, thus the speed benefits you might >>> get from there is not needed. Also support for the combined modes do >>> require support for RFC5282, and there are implementations which have >>> not done that (as there is no benefits or need for them to implement >>> it). >>> -- >>> kivinen@iki.fi >>> >>> _______________________________________________ >>> 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 >> > > --001a113c83461cd0270524fb5d04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Hi, 

Please find an new update: https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d=
6758e8d4642500af1c2f

Change 1: AUTH_AES_XCBC_96 and P=
RF_AES128_CBC are set to SHOULD instead of a MAY. I was suprised PRF was al=
ready SHOULD. In each case, explanation text has been added.

Change 2: Titles of the subsections have also been updated to better fit IA=
NA designation.
Change 3: Sections have been re-ordered so fr=
om Typpe 1 / Type 3 / Type 2 / Type 4 to Type 1/ Type 2/ Type 3 / Type 4.
Feel free to comment.

BR,
Daniel



On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migaul= t <daniel.migault@ericsson.com> wrote:
Hi Yaron,=C2=A0

= I just committed your correction. You are right this is much better.
<= div>
BR,=C2=A0
Daniel

On Mon, N= ov 16, 2015 at 12:41 PM, Yaron Sheffer <yaronf.ietf@gmail.com><= /span> wrote:
Looks good. One small corre= ction:

many IKEv2 have not implemented =3D> many IKEv2 implementations do not i= nclude

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


On 11/16/2015 06:05 PM, Daniel Migault wrote:
Hi,

Thank you Yaron for your comments. Please find the new update ot the draft:=

https://github.com/mgl= t/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002

Comment 1:
IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this documentmust not be considered for IKEv1.

I change MUST NOT in must not. I left the whole sentence as I beleive,
it provides the reason why IKEv1 is not in scope and state clearly that
applying considerations in this document to IKEv1 is a bad idea.

Comment 2:
I added some clarifying text on why not MUST. To me the obvious reason
is that an algorithm not mentioned in RFC4307 should not have a status
greater than SHOULD -- unless otherwise of course ;-). I though we had
this explanation somewhere, but maybe it is missing and should be added
in the intro for example.

I also provided dome explanation why ESP and IKEv2 are in a different
race which resulted in having AES-GCM not widely deployed for IKEv2

Comment 3:
"As it is not being deployed" as been replaced by "as it is = not widely
deployed"

"and now it is known to be weak at least for a nation state" has = been
changed to "and now it is known to be weak against a nation-state atta= cker".

Acknowledgement section has also been updated.

BR,
Daniel


On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <kivinen@iki.fi
<mailto:kivinen@iki.= fi>> wrote:

=C2=A0 =C2=A0 Yaron Sheffer writes:
=C2=A0 =C2=A0 > The rationale for GCM describes why it's in the tabl= e, but seems to
=C2=A0 =C2=A0 > argue for a MUST (rather than the SHOULD that's in t= he table). I guess
=C2=A0 =C2=A0 > there's a reason why we don't have MUST, let'= ;s spell it out.

=C2=A0 =C2=A0 The reason for that is that it is not needed as IKEv2 SA is n= ever used
=C2=A0 =C2=A0 to transmit huge amounts of data, thus the speed benefits you= might
=C2=A0 =C2=A0 get from there is not needed. Also support for the combined m= odes do
=C2=A0 =C2=A0 require support for RFC5282, and there are implementations wh= ich have
=C2=A0 =C2=A0 not done that (as there is no benefits or need for them to im= plement
=C2=A0 =C2=A0 it).
=C2=A0 =C2=A0 --
 =C2=A0 =C2=A0 kivinen@i= ki.fi <mailto:ki= vinen@iki.fi>

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 IPsec mailing list
=C2=A0 =C2=A0 IPsec@iet= f.org <mailto:IP= sec@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ips= ec



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


--001a113c83461cd0270524fb5d04-- From nobody Fri Nov 20 09:23:26 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4D11B3991 for ; Fri, 20 Nov 2015 09:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxhU1Scw2F2b for ; Fri, 20 Nov 2015 09:23:21 -0800 (PST) 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 043BF1B3997 for ; Fri, 20 Nov 2015 09:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1448040191; x=2311953791; 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=3o21I2RGlUSPryVfPAm/9zYAuezHES16+m9WGSjGkV4=; b=Bb6ablFTVSIXqvFFTr/G5bXqVt9ypUY7LVaVRI71qS7aVJ3B7nOffh28GELOWpsf 0VsI0sWV1gBbPWnvG6ngfsg9pQ3tr1eHEP+Pr0hZDBhS7PGzKzbdt/HH8pJlqWGw MQr9P89iv43CNinA/51JiyAbZeBH37PGjpEp1tbL1JjD6t/TECtjqbv1dml3VqVv 8wm6nSFOoySGY/rtCci7NWNM7Ui95nEUflQcXuVoi9+VPnP/5qUNrn55L5Ku9brI LfVj/b3/dboiaWH5Ejid8VanW2fgu80u8k1N2pntNHyYzeAd+ZLU3fWPgYKpossA hfUPcy4y+8ot0ktLT5rVuA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 27.C7.20021.FF65F465; Fri, 20 Nov 2015 09:23:11 -0800 (PST) X-AuditID: 11973e13-f79196d000004e35-bd-564f56ff8795 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 96.9B.29392.FF65F465; Fri, 20 Nov 2015 09:23:11 -0800 (PST) Received: from da0602a-dhcp187.apple.com (da0602a-dhcp187.apple.com [17.226.23.187]) by orrisroot.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NY400AE8IYMPR10@orrisroot.apple.com> for ipsec@ietf.org; Fri, 20 Nov 2015 09:23:11 -0800 (PST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_1698AC2B-1D62-4EB0-9B4A-F24B242FEEB4" MIME-version: 1.0 (Mac OS X Mail 9.2 \(3106\)) From: Tommy Pauly In-reply-to: Date: Fri, 20 Nov 2015 09:23:25 -0800 Message-id: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> To: Daniel Migault X-Mailer: Apple Mail (2.3106) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYpfs/zD/M4MY8AYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/rsTewFZ6oqTh86y9rA+DS9i5GTQ0LARGLloSUsELaYxIV7 69m6GLk4hAT2Mko87fnMAlN0rWcyVGI+k8TKU3sZIZwtQM6UCUxdjBwcwgISEpv3JII0MAsk SXw/MQUszCugJ7H2eCVEhYJEf6s5SAWbgIrE8W8bmEFsToFgiU/vm1hASlgEVCVu7VMBGc4s sJ5RonX1bTaQGl4BG4mLBz6ygthCArdYJI5ukwKxRQQMJF5O2MkGcaasRGfXXUYIewubxL++ gAmMwrOQHDQL4SCIsLbEsoWvmSFsTYn93ctZMMU1JDq/TWRdwMi2ilEoNzEzRzczz1QvsaAg J1UvOT93EyMoEqbbCe9gPL3K6hCjAAejEg9vg7hfmBBrYllxZe4hRmkOFiVxXls7oJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGoOvvN/6r8rvuvOdPxVrjvSrJapl9sV7sMxUaHy7MX7uW SXmXvBbfGkfXxz82t5cc7dCPUeCcmXugzoFJ/2+OoETzedkvkt+sO579/ZbuZ/35/7Jl9Rt8 z3Y9WGJx/lZYO8evUAUjZQ5ZBpmvvVp/HZlVtSqc9KM5RNR/MD7YcPBWT5rkvtdKLMUZiYZa zEXFiQBEWwI3ZQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUi2FCcpfs/zD/M4PhMHov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/rsTewFZ6oqTh86y9rA+DS9i5GTQ0LAROJaz2Q2CFtM4sK9 9UA2F4eQwHwmiZWn9jJCOFuAnCkTmLoYOTiEBSQkNu9JBGlgFkiS+H5iCliYV0BPYu3xSogK BYn+VnOQCjYBFYnj3zYwg9icAsESn943sYCUsAioStzapwIynFlgPaNE6+rbYCfwCthIXDzw kRXEFhK4xSJxdJsUiC0iYCDxcsJOqDNlJTq77jJOYBSYheSIWQhHQIS1JZYtfM0MYWtK7O9e zoIpriHR+W0i6wJGtlWMAkWpOYmVZnqJBQU5qXrJ+bmbGMGhWxi1g7FhudUhRgEORiUe3gZx vzAh1sSy4srcQ4wSHMxKIrwH3gGFeFMSK6tSi/Lji0pzUosPMU5kBHpyIrOUaHI+MLLySuIN TUwMTIyNzYyNzU3MaSmsJM7rbQp0kUB6YklqdmpqQWoRzFFMHJxSDYwaPyxmzleobhZc9P3j 8ilByVNLzrwoDVdd86JxpX61zNO9L1i+/7uWmJGsetf+w57/h+sEMo9PU33p9Dw+L9jy20LW f88nyLRWdH8wFnRd3fHV4vEFvi8G4X/etnao+NU82Zm5uompTWjZAS4BZ37tvBfyHfp92zv4 U4It9jo233Op1/brzFZiKc5INNRiLipOBABe2/nG0AIAAA== Archived-At: Cc: IPsecME WG , Paul Hoffman , Tero Kivinen , Yoav Nir Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 17:23:24 -0000 --Apple-Mail=_1698AC2B-1D62-4EB0-9B4A-F24B242FEEB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Daniel, One minor typo: "PRF_AES128_CBC has been downgraded from SHOULD in = RFC4307=E2=80=9D should be "PRF_AES128_CBC has been downgraded from = SHOULD+ in RFC4307" On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, = PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for the = purposes of Internet of Things devices. I tend to think that it would be = more straightforward to have a separate document that explains the = preferred algorithms for IoT devices (an IKEv2 profile for IoT, for = example). However, if we do want to keep them in this document, I think = it would help to have a section in the introduction to the document = explaining the use case for the IoT devices and why they are now = included in the bis document, whereas they were not relevant yet in RFC = 4307. It may also be helpful to qualify the SHOULDs as pertaining more, = perhaps, to servers; traditional VPN clients would generally not be = interacting with IoT devices directly, and thus would have little reason = to implement these algorithms. Thanks, Tommy > On Nov 20, 2015, at 8:28 AM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > Please find an new update:=20 > = https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af= 1c2f = >=20 > Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD = instead of a MAY. I was suprised PRF was already SHOULD. In each case, = explanation text has been added. >=20 > Change 2: Titles of the subsections have also been updated to better = fit IANA designation. > Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 / = Type 2 / Type 4 to Type 1/ Type 2/ Type 3 / Type 4. >=20 > Feel free to comment. >=20 > BR,=20 > Daniel >=20 >=20 >=20 >=20 > On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault = > = wrote: > Hi Yaron,=20 >=20 > I just committed your correction. You are right this is much better. >=20 > BR,=20 > Daniel >=20 > On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer > wrote: > Looks good. One small correction: >=20 > many IKEv2 have not implemented =3D> many IKEv2 implementations do not = include >=20 > Thanks, > Yaron >=20 >=20 > On 11/16/2015 06:05 PM, Daniel Migault wrote: > Hi, >=20 > Thank you Yaron for your comments. Please find the new update ot the = draft: >=20 > = https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca= 0002 = >=20 > Comment 1: > IKEv1 is out of scope of this document. IKEv1 is deprecated and the > recommendations of this documentmust not be considered for IKEv1. >=20 > I change MUST NOT in must not. I left the whole sentence as I beleive, > it provides the reason why IKEv1 is not in scope and state clearly = that > applying considerations in this document to IKEv1 is a bad idea. >=20 > Comment 2: > I added some clarifying text on why not MUST. To me the obvious reason > is that an algorithm not mentioned in RFC4307 should not have a status > greater than SHOULD -- unless otherwise of course ;-). I though we had > this explanation somewhere, but maybe it is missing and should be = added > in the intro for example. >=20 > I also provided dome explanation why ESP and IKEv2 are in a different > race which resulted in having AES-GCM not widely deployed for IKEv2 >=20 > Comment 3: > "As it is not being deployed" as been replaced by "as it is not widely > deployed" >=20 > "and now it is known to be weak at least for a nation state" has been > changed to "and now it is known to be weak against a nation-state = attacker". >=20 > Acknowledgement section has also been updated. >=20 > BR, > Daniel >=20 >=20 > On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen > >> wrote: >=20 > Yaron Sheffer writes: > > The rationale for GCM describes why it's in the table, but seems = to > > argue for a MUST (rather than the SHOULD that's in the table). I = guess > > there's a reason why we don't have MUST, let's spell it out. >=20 > The reason for that is that it is not needed as IKEv2 SA is never = used > to transmit huge amounts of data, thus the speed benefits you = might > get from there is not needed. Also support for the combined modes = do > require support for RFC5282, and there are implementations which = have > not done that (as there is no benefits or need for them to = implement > it). > -- > kivinen@iki.fi > >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_1698AC2B-1D62-4EB0-9B4A-F24B242FEEB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Daniel,

One minor typo: "PRF_AES128_CBC has = been downgraded from SHOULD in RFC4307=E2=80=9D should be = "PRF_AES128_CBC has been downgraded from SHOULD+ in RFC4307"

On a broader note, many = of the SHOULD algorithms (ENCR_AES_CCM_8, = PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for = the purposes of Internet of Things devices. I tend to think that it = would be more straightforward to have a separate document that explains = the preferred algorithms for IoT devices (an IKEv2 profile for IoT, for = example). However, if we do want to keep them in this document, I think = it would help to have a section in the introduction to the document = explaining the use case for the IoT devices and why they are now = included in the bis document, whereas they were not relevant yet = in RFC 4307. It may also be helpful to qualify the SHOULDs as = pertaining more, perhaps, to servers; traditional VPN clients would = generally not be interacting with IoT devices directly, and thus would = have little reason to implement these algorithms.
Thanks,
Tommy

On Nov 20, 2015, at 8:28 AM, Daniel Migault = <daniel.migault@ericsson.com> wrote:

Hi, 

Please find an new update: 
https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e=
8d4642500af1c2f

Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to =
SHOULD instead of a MAY. I was suprised PRF was already SHOULD. In each =
case, explanation text has been added.

Change 2: Titles of the subsections have also been updated to better fit =
IANA designation.
Change 3: Sections =
have been re-ordered so from Typpe 1 / Type 3 / Type 2 / Type 4 to Type =
1/ Type 2/ Type 3 / Type 4.

Feel free to comment.

BR, 
Daniel




On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault = <daniel.migault@ericsson.com> wrote:
Hi Yaron, 

I just committed your correction. You are right this is much = better.

BR, 
Daniel

On Mon, Nov 16, 2015 at 12:41 PM, = Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Looks good. One small = correction:

many IKEv2 have not implemented =3D> many IKEv2 implementations do = not include

Thanks,
        Yaron


On 11/16/2015 06:05 PM, Daniel Migault wrote:
Hi,

Thank you Yaron for your comments. Please find the new update ot the = draft:

https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7= c3155d49bca0002

Comment 1:
IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this documentmust not be considered for IKEv1.

I change MUST NOT in must not. I left the whole sentence as I = beleive,
it provides the reason why IKEv1 is not in scope and state clearly = that
applying considerations in this document to IKEv1 is a bad idea.

Comment 2:
I added some clarifying text on why not MUST. To me the obvious = reason
is that an algorithm not mentioned in RFC4307 should not have a = status
greater than SHOULD -- unless otherwise of course ;-). I though we = had
this explanation somewhere, but maybe it is missing and should be = added
in the intro for example.

I also provided dome explanation why ESP and IKEv2 are in a different
race which resulted in having AES-GCM not widely deployed for IKEv2

Comment 3:
"As it is not being deployed" as been replaced by "as it is not = widely
deployed"

"and now it is known to be weak at least for a nation state" has been
changed to "and now it is known to be weak against a nation-state = attacker".

Acknowledgement section has also been updated.

BR,
Daniel


On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <kivinen@iki.fi
<mailto:kivinen@iki.fi>> wrote:

    Yaron Sheffer writes:
    > The rationale for GCM describes why it's in the = table, but seems to
    > argue for a MUST (rather than the SHOULD that's in = the table). I guess
    > there's a reason why we don't have MUST, let's spell = it out.

    The reason for that is that it is not needed as IKEv2 SA = is never used
    to transmit huge amounts of data, thus the speed benefits = you might
    get from there is not needed. Also support for the = combined modes do
    require support for RFC5282, and there are implementations = which have
    not done that (as there is no benefits or need for them to = implement
    it).
    --
     kivinen@iki.fi <mailto:kivinen@iki.fi>

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



_______________________________________________
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

= --Apple-Mail=_1698AC2B-1D62-4EB0-9B4A-F24B242FEEB4-- From nobody Fri Nov 20 13:49:46 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8931B3E8D for ; Fri, 20 Nov 2015 13:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFNPs9glBDjM for ; Fri, 20 Nov 2015 13:49:44 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0979D1B3EA6 for ; Fri, 20 Nov 2015 13:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1448056183; x=2311969783; 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=xnvasjfleRr/qFsW7GjmtEoguLTeAEHJ7dtXzr70b+Y=; b=ErJZl/F/LOQmXS/RNRAkb08iiDj66D5dfzoCGYHBhvP07d5pgxZO0oX0MlQEmHNq RoUdrGfqaHQF+GYTWsQll32WibKJYurd37vvHHicVMM5LHRJHgBd5XuojHofSBh+ hXdjl33Tr0pqVqFAGqrZAYuqg10VxzUa80xCslPazvSCuhCAM39W5CF0hvshRObJ 97AxvXJ6OjJijnyURXiUf97ghbvYUr97VkedeOJUcIJYOZ3R/sSX5u1gkh8bxf7B 7rY2/Hxt+m4Sa7Zu9SQHbJPPB27W9+JBg7uY3z1SN68qUU26K8yiqbsJRwWeoG8M tDL/RSatvJGQd4t+byVkFw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 96.4D.27014.7759F465; Fri, 20 Nov 2015 13:49:43 -0800 (PST) X-AuditID: 11973e16-f793c6d000006986-5d-564f95776f44 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 60.2A.05180.7759F465; Fri, 20 Nov 2015 13:49:43 -0800 (PST) Received: from da0602a-dhcp122.apple.com (da0602a-dhcp122.apple.com [17.226.23.122]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NY400GK0VAUTZ30@cilantro.apple.com> for ipsec@ietf.org; Fri, 20 Nov 2015 13:49:43 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Message-id: <42BCC9F3-3AA7-4C06-A70B-030FE430D0B8@apple.com> Date: Fri, 20 Nov 2015 13:49:42 -0800 To: IPsecME WG MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FAYrFs+1T/MYN4bNYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/a324wFrRwV7x8fZW1gPMPWxcjJISFgIrHy/2ooW0ziwr31 QDYXh5DAXkaJwx9PMcMUTZn7ix0iMYdJov/vUUYIZwOTxMUdX1m7GDk4hAUkJDbvSQRpYBNQ kTj+bQMzSJhZQF1iypRckDCzgLbEk3cXWEFsYQEDiYYXi5hAbF4BG4ldi36ygNgsAqoSy25s ZANpFRGQl5h5IxOiRE/i34Wb7BDnyErs27AA7E4Jgb+sEu1Nu9gmMArOQtg2C8m2WUjaFzAy r2IUyk3MzNHNzDPXSywoyEnVS87P3cQICsnpdmI7GB+usjrEKMDBqMTDm1DkHybEmlhWXJl7 iFGag0VJnNfOzi9MSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PzI7mr2/bqSn5M5/i2t7su NGA9u6yNsZquKIf/3Z+56rfW8C4719qSJRqjGn3w6l1rtdyEdPYrm/9krpv8Q+nYr6sN7WwC yXfNmf1lE+LvGr62P6PQNzXXPJ79Z9liplYtnW3C6R+M7ljNDLFJ7o54O0251zp0XW/aG3Hm 2Y27lGImCmfOVGIpzkg01GIuKk4EAJDokRoqAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAspFs+1T/MYNZ5FYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/a324wFrRwV7x8fZW1gPMPWxcjJISFgIjFl7i92CFtM4sK9 9UBxLg4hgTlMEv1/jzJCOBuYJC7u+MraxcjBISwgIbF5TyJIA5uAisTxbxuYQcLMAuoSU6bk goSZBbQlnry7wApiCwsYSDS8WMQEYvMK2EjsWvSTBcRmEVCVWHZjIxtIq4iAvMTMG5kQJXoS /y7chDpHVmLfhgVsExj5ZiEsmIVkwSwkHQsYmVcxChSl5iRWGuslFhTkpOol5+duYgSHUGHw DsY/y6wOMQpwMCrx8HIU+IcJsSaWFVfmHmKU4GBWEuE98M4vTIg3JbGyKrUoP76oNCe1+BBj MtCZE5mlRJPzgeGdVxJvaGJiYGJsbGZsbG5iTpqwkjivtynQCoH0xJLU7NTUgtQimC1MHJxS DYxxmk6/Ls+p2/hcWCtnYqMGh1P+wrvWN7XfnWMWenHbtj/Te+vB9/pclfNYXdPiKt/9WNMz Q2Lz9ZTzBzNevTotdr9LZnrV7edM/Am3vPQyz7yQmdyktS37ycHrz/ZLpQct0jn8q/fkFNmo fp3jr5n7tMpVwqfM7/0qyXjkk0dY8/TldxxafuUrsRRnJBpqMRcVJwIAeVy4mWUCAAA= Archived-At: Subject: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 21:49:45 -0000 Hello, Based on the feedback received at our informal meeting in Yokohama, = I=E2=80=99ve updated the draft for TCP Encapsulation of IKEv2 and ESP: https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 The revisions include: - More explanation in the introduction about the motivation, and other = work that this draft is trying to standardize (3GPP recommendations, = proprietary IKEv1 IPSec over TCP versions, and SSL VPNs). - Comments about maximum IKE and ESP message size within the TCP stream, = which is effective the MTU of the tunnel. - Specify that if the TCP connection is brought down and re-established, = the first message on the stream must be an IKE message. - Detailed considerations about interactions with middleboxes (thanks = Graham Bartlett for input on this). In the meeting in Yokohama, there was general agreement that this was = relevant work that we=E2=80=99d like to keep looking into. Please read = the document, and provide any feedback you have! Thanks, Tommy= From nobody Fri Nov 20 15:07:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6121B3FC4 for ; Fri, 20 Nov 2015 15:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 Tm6ZdrQPb28c for ; Fri, 20 Nov 2015 15:07:22 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 529E81B3FC2 for ; Fri, 20 Nov 2015 15:07:21 -0800 (PST) Received: by wmvv187 with SMTP id v187so91862646wmv.1 for ; Fri, 20 Nov 2015 15:07:20 -0800 (PST) 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-type:content-transfer-encoding; bh=CN0zPrtahduyZ8/xBrtDsdSYp1E2hmtsQ4ganCo1ow8=; b=Tkh/Neva/h9l873gurffop/Ht63rFHV5N0CyoYkM9lf/JOHbyMwrodQ8jWDU9m8gQ9 +2KHYqSdyD2X/FvPZ9NBzpSFW5thghjqbOcg4JZiLSd4NzxrADy1f0r1gmgMufG4Kgc+ l4fCzcFClQEkGrKjVYV6EWts48iMjSPc9U2eSl0MJstfK8pNpMShakZxwDABjzpqplJE /tHjf2EYhdr+jqTxzMM9TXOqpLYNWktmuAjil21IEHWXH9L6gqfYYfKMBobP0AjddNEh WAl5HsP6rpkkbcbA+4PAGgEAln4KR3x60qHzzheLpzAeTqc+CyWHRIjv0PdDFZW4NXgJ IuFQ== X-Received: by 10.28.140.136 with SMTP id o130mr2511120wmd.78.1448060839940; Fri, 20 Nov 2015 15:07:19 -0800 (PST) Received: from [10.0.0.4] (bzq-79-181-57-97.red.bezeqint.net. [79.181.57.97]) by smtp.googlemail.com with ESMTPSA id q77sm1445483wmd.22.2015.11.20.15.07.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 15:07:18 -0800 (PST) To: Tommy Pauly , IPsecME WG References: <42BCC9F3-3AA7-4C06-A70B-030FE430D0B8@apple.com> From: Yaron Sheffer Message-ID: <564FA7A1.9060603@gmail.com> Date: Sat, 21 Nov 2015 01:07:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <42BCC9F3-3AA7-4C06-A70B-030FE430D0B8@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 23:07:24 -0000 Hi Tommy, I also think this is very relevant work. Here are some comments to -01: I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited under "prior work", both because it is documented and also because I believe it is implemented by a vendor. In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers will use UDP encapsulation even when there is no NAT on the path, for example because networks or middleboxes do not support IP protocols other than TCP and UDP." "Although a stream" - this paragraph is not worded very well (streams don't send anything) and is hard to understand. In addition, there are lots of networks that use jumbo frames and so hardcoding the value 1500 into the spec may not be a good idea. I can think of HA cases where several gateways will handle ESP SAs that are all associated with the same IKE SA. So I'm wondering why we are insisting of all Child SAs being in the same TCP connection, and as a result requiring that an IKE message should be the preamble of any new connection. Although it might seem obvious, I think Sec. 3 should say explicitly that if the connection is closed midway through a message, the recipient MUST silently drop the partial message. You may want to add to the last paragraph of the Security Considerations: This document explicitly does not define a profile for TLS when used in this manner, or any relation between identities at the IPsec level and those on the TLS level ("channel binding"). Thanks, Yaron On 11/20/2015 11:49 PM, Tommy Pauly wrote: > Hello, > > Based on the feedback received at our informal meeting in Yokohama, Ive updated the draft for TCP Encapsulation of IKEv2 and ESP: > > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 > > The revisions include: > - More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs). > - Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel. > - Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message. > - Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this). > > In the meeting in Yokohama, there was general agreement that this was relevant work that wed like to keep looking into. Please read the document, and provide any feedback you have! > > Thanks, > Tommy > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Nov 20 15:11:06 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A88E1B3FCD for ; Fri, 20 Nov 2015 15:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 xD9xeAayVypa for ; Fri, 20 Nov 2015 15:11:02 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 78ACF1B3FCB for ; Fri, 20 Nov 2015 15:11:02 -0800 (PST) Received: by wmvv187 with SMTP id v187so91940292wmv.1 for ; Fri, 20 Nov 2015 15:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=9Xw08zXAKpcS/ib+mICo/8p/94bOosXKXsWp5zrPHqQ=; b=k3rUlNKTCJioiwo77mltBcuc0vr7wV2HjZPpj2DNQMto+61RbkDSif8Cvy6USbM+VW LXt9YB1wDjfpqP1ng11fGZRS5+CGXhRDSU8nmwI1hzRIHFYGl5Vo/wpp9Atgrua/2TOx diIN+ZDtOgOtnA9jOlXwPmWDwjSjPZXrxrKJKBJyNjDhJp6teVtvL5Vl3OWnHIm017QC OMXr3MMniOtqnuWjzqlEilsxHUSOKdY5rX4kWCkX7+/jx2wS8TrVRFD03v3avrls6WyJ Oe0dD68Cfz4k4DlBpnljnGfuyv+bwSxsvBiiMCk+CIekMOXduxjoh9o2/HMhjA8K+2+W +Nng== X-Received: by 10.194.249.69 with SMTP id ys5mr16216130wjc.97.1448061061130; Fri, 20 Nov 2015 15:11:01 -0800 (PST) Received: from [10.0.0.4] (bzq-79-181-57-97.red.bezeqint.net. [79.181.57.97]) by smtp.googlemail.com with ESMTPSA id f11sm380277wmd.7.2015.11.20.15.10.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Nov 2015 15:11:00 -0800 (PST) From: Yaron Sheffer To: Tommy Pauly , IPsecME WG References: <42BCC9F3-3AA7-4C06-A70B-030FE430D0B8@apple.com> Message-ID: <564FA882.30006@gmail.com> Date: Sat, 21 Nov 2015 01:10:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <42BCC9F3-3AA7-4C06-A70B-030FE430D0B8@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 23:11:04 -0000 Hi Tommy, I also think this is very relevant work. Here are some comments to -01: I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited under "prior work", both because it is documented and also because I believe it is implemented by a vendor. In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers will use UDP encapsulation even when there is no NAT on the path, for example because networks or middleboxes do not support IP protocols other than TCP and UDP." "Although a stream" - this paragraph is not worded very well (streams don't send anything) and is hard to understand. There are lots of networks that use jumbo frames and so hardcoding the value 1500 into the spec may not be a good idea. I can think of HA cases where several gateways are handling ESP SAs that are all associated with the same IKE SA. So I'm wondering why we are insisting on all Child SAs being in the same connection, and as a result requiring that an IKE message be the preamble to any new connection. Although it might seem obvious, I think Sec. 3 should say explicitly that if the connection is closed midway through a message, the recipient must silently drop the partial message. You may want to add to the last paragraph of the Security Considerations: This document explicitly does not define a profile for TLS when used in this manner, or any relation between identities at the IPsec level and those at the TLS level ("channel binding"). Thanks, Yaron On 11/20/2015 11:49 PM, Tommy Pauly wrote: > Hello, > > Based on the feedback received at our informal meeting in Yokohama, Ive updated the draft for TCP Encapsulation of IKEv2 and ESP: > > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 > > The revisions include: > - More explanation in the introduction about the motivation, and other work that this draft is trying to standardize (3GPP recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs). > - Comments about maximum IKE and ESP message size within the TCP stream, which is effective the MTU of the tunnel. > - Specify that if the TCP connection is brought down and re-established, the first message on the stream must be an IKE message. > - Detailed considerations about interactions with middleboxes (thanks Graham Bartlett for input on this). > > In the meeting in Yokohama, there was general agreement that this was relevant work that wed like to keep looking into. Please read the document, and provide any feedback you have! > > Thanks, > Tommy > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Nov 20 23:35:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1DE1B41B3 for ; Fri, 20 Nov 2015 23:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 rxnl0GUj7iQI for ; Fri, 20 Nov 2015 23:35:43 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 F05E01B41B0 for ; Fri, 20 Nov 2015 23:35:42 -0800 (PST) Received: by wmec201 with SMTP id c201so46875378wme.1 for ; Fri, 20 Nov 2015 23:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlOaZe9qcocYyvVmQhmLfbK7eqkCymcudVVLsui2UEg=; b=L6dofM+wagUmKcdBXHLCAZQ/2ngzvHX9mhtNPjduA6vwbUzMA3Q5TZlHCrEhIcL2gZ 6XuCsq9gXIEesBwtKJ5k6LboXVgDxGByGKR4xK7JDI0TuGPAPgrsC+oEexglpOVyweXy 763rM3EbtyE8a9aXWH902lM61X3UUBsCPTP/sewLTIOcgd5ULn06cwiJGL3jyxPVunti XBV33PNwE7+E09HdF62Xfx1KPd3hZwBy6HfSueSarHwPRTZaM01AZJiNfw7TOdW2g6JN m4pap0xrwFLW5Jf1K1TYRoW0Y1PJS6ZJRqZ4V5/WiTEEhO4/BUXlfGE/Z6IeiIrZP0fI pqDQ== X-Received: by 10.28.223.212 with SMTP id w203mr4512159wmg.88.1448091341555; Fri, 20 Nov 2015 23:35:41 -0800 (PST) Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id bg10sm2851493wjb.46.2015.11.20.23.35.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Nov 2015 23:35:40 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <564FA882.30006@gmail.com> Date: Sat, 21 Nov 2015 09:35:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C082B98-CD90-40B8-A71C-C9B8FE1D45EE@gmail.com> References: <42BCC9F3-3AA7-4C06-A70B-030FE430D0B8@apple.com> <564FA882.30006@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IPsecME WG , Tommy Pauly Subject: Re: [IPsec] New revision of TCP Encapsulation draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 07:35:44 -0000 > On 21 Nov 2015, at 1:10 AM, Yaron Sheffer = wrote: >=20 > Hi Tommy, >=20 > I also think this is very relevant work. Here are some comments to = -01: >=20 > I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be = cited under "prior work=94 That=92s draft-ietf-ipsecme-ike-tcp-01. It was a working group document = for a while. Yoav From mchristian@fortinet.com Fri Nov 20 17:20:42 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DAB1B35A6 for ; Fri, 20 Nov 2015 17:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nu8x4e-j2njE for ; Fri, 20 Nov 2015 17:20:40 -0800 (PST) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3351B359E for ; Fri, 20 Nov 2015 17:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=fortinet.com; s=20131225; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version:x-feas-system-wl; bh=msM1JsHJoFnVzSqsv2M2FZ+jFHNntHUCktB+uLYBM2c=; b=OPOAGkiIzbiclAMWhkxMiLim8FAMwcn4E5f61UjdAnGQbMSBXLEvllt7/NjIVMwyNG/tdUwHW38yVXVGfQDfrxkIXEGdWoEJOi4WOtcwJPtQTHtgsi8DB4+EqgvkpGDg0o3/Z0tE2poBkLfxhUg757XZ7vNMKIVk1dIk/r5BhNxu7ong/n7sC1xvuua2kRJVsQ35oZctVDBvtZ/PQOD1F/B9ECaaQa60Vy15Zs7HL8zNTM3aKLomf/Gd2AWU5cgMNJqzKRhLwIAv4MysCDY/O4CwzWrL+AueOUnur6pQphyQuibKi6fxKgITR/XdhiVn20Bm71BqYngYygU/J8xovw== Received: from mail.fortinet.com ([192.168.221.213]) by smtp.fortinet.com with ESMTP id tAL1Kdgp016976-tAL1Kdgr016976 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Nov 2015 17:20:39 -0800 Received: from FGT-EXCH-MBX230.fortinet-us.com ([fe80::1428:24e1:ec8e:1e6a]) by FGT-EXCH-CAS213.fortinet-us.com ([192.168.221.213]) with mapi id 14.03.0248.002; Fri, 20 Nov 2015 17:20:39 -0800 From: Michael Christian To: "ipsec@ietf.org" Thread-Topic: RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2) Thread-Index: AdEj+rY9FyEJsksbQmK6rBDRbhdJoQ== Date: Sat, 21 Nov 2015 01:20:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.56.135.177] Content-Type: multipart/alternative; boundary="_000_C8B573F530694F4E96909DC6C4B8276C3C9E382DFGTEXCHMBX230fo_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.213 Archived-At: X-Mailman-Approved-At: Sat, 21 Nov 2015 09:49:41 -0800 Subject: [IPsec] RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 01:21:37 -0000 --_000_C8B573F530694F4E96909DC6C4B8276C3C9E382DFGTEXCHMBX230fo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I'm investigating a possible RFC 7296 compliance issue and I was hoping y= ou may be able to shed some light on the RFC for me. In section 2.9 Page 43 regarding multiple traffic selectors: Can two TSi proposals be sent by the initiator every time IKEv2 is negoti= ated due to a data packet? Or Is the proposal of an unknown traffic selec= tor type required before the initiator can respond with more specific and= range TSi's? I appreciate any clarification you may be able to provide. Thank you, Mike Christian Technical Account Manager Fortinet - The New Generation of Secure Gateways 899 Kifer Road | Sunnyvale, CA 94086 | USA *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_C8B573F530694F4E96909DC6C4B8276C3C9E382DFGTEXCHMBX230fo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Hello,

I’m investigating a possible RFC 7296 compli= ance issue and I was hoping you may be able to shed some light on the RFC= for me.

 

In section 2.9 Page 43 regarding multiple traffic = selectors:

 

Can two TSi proposals be sent by the initiator eve= ry time IKEv2 is negotiated due to a data packet? Or Is the proposal of a= n unknown traffic selector type required before the initiator can respond= with more specific and range TSi’s?  

 

I appreciate any clarification you may be able to = provide.

 

Thank you,

Mike Christian

 

Technical Account Manager

Fortinet - The New Generation of Secure Gateways

899 Kifer Road | Sunnyvale, CA 94086 | USA

 


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_C8B573F530694F4E96909DC6C4B8276C3C9E382DFGTEXCHMBX230fo_-- From nobody Mon Nov 23 03:42:48 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA84D1B31C2 for ; Mon, 23 Nov 2015 03:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=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 0DDmVSG0Jfla for ; Mon, 23 Nov 2015 03:42:46 -0800 (PST) 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 D13AD1B31C0 for ; Mon, 23 Nov 2015 03:42:44 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tANBgZLk012943 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Nov 2015 13:42:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tANBgZJL003408; Mon, 23 Nov 2015 13:42:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22098.64427.387229.470580@fireball.acr.fi> Date: Mon, 23 Nov 2015 13:42:35 +0200 From: Tero Kivinen To: Michael Christian In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 11:42:48 -0000 Michael Christian writes: > Hello, >=20 > I=E2=80=99m investigating a possible RFC 7296 compliance issue and I = was hoping you > may be able to shed some light on the RFC for me. >=20 > In section 2.9 Page 43 regarding multiple traffic selectors: >=20 > Can two TSi proposals be sent by the initiator every time IKEv2 is ne= gotiated > due to a data packet=3F I do not really understand what you are trying to ask. Any TSi payload can have multiple traffic selectors. Those traffic selectors are from the policy rule, and the first of them can be from the data packet, if SA was created because of the data packet, i.e. the text says: To enable the responder to choose the appropriate range in this case= , if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first Traffic Selector in each of TS= i and TSr a very specific Traffic Selector including the addresses in the packet triggering the request. =20 So yes, when you ask for SA to be created based on the traffic, you SHOULD always include two TSi traffic selectors, one which matches the data from the packet, and another which is taken from the policy. > Or Is the proposal of an unknown traffic selector type required > before the initiator can respond with more specific and range TSi=E2=80= =99s=3F Initiator will never respond with TSi. Initiator sends the TSi ranges, and it of course should never send unknown traffic selector types, as it should only send those traffic selectors it knows. The responder might receive unknown traffic selector types, because initiator might support more things than responder do, and in that case the responder will simply ignore those and process TS payload just like those unknown traffic selector types were not there at all, i.e. narrow the request using the known traffic selector types. As responder will only reply with traffic selectors sent by the initiator the initiator can never get back an TS reply containing unknown traffic selector types. --=20 kivinen@iki.fi From nobody Mon Nov 23 03:47:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6E1B31E4 for ; Mon, 23 Nov 2015 03:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 dAOclfG-w8Dx for ; Mon, 23 Nov 2015 03:47:50 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 2ED721B31E3 for ; Mon, 23 Nov 2015 03:47:50 -0800 (PST) Received: by lbbkw15 with SMTP id kw15so94188572lbb.0 for ; Mon, 23 Nov 2015 03:47:48 -0800 (PST) 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 :content-type; bh=0f+/IRkrlNyT7sUWdJeY6ftCs3/rsv/K9xzTW9M+mIY=; b=m68jEP3bWFviTowwqlwlojcl0Amp9H8PDWJ/iVjJ4Er1Faja61UNgTP/wJDrvKeE4o RrTtGcgpg0iDCtpQI+Rlu+m+KIGpEtjDytAVBRR7wPcFDy0OgFVqK2yA7+iWUCOxPoog 6zYR/dRGl79pTw0+nY2mda76PsqLB81x12bfPShAUuzoc4YK9+p3C2UFcL4g8dTIaSwG IzWl5gPnHQBi625jJTjxpBQC4cfRAS5Jrihy4D8g5I1lH+ZZ81D4YhnNZtcbpTzfHHg3 2ZXarpf07+LyRlxzXZU9m101Cxzd5zsgxoz1pWz3h21Ix2GHge2w+o0Jfcas/bQlSdCE 0lJQ== X-Received: by 10.112.199.71 with SMTP id ji7mr4973204lbc.61.1448279268106; Mon, 23 Nov 2015 03:47:48 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id l67sm1798607lfl.26.2015.11.23.03.47.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 03:47:47 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Michael Christian" , References: Date: Mon, 23 Nov 2015 14:47:48 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0412_01D125FD.EC168EF0" 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] RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 11:47:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0412_01D125FD.EC168EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mike, I'm not sure I completely understand your question. RFC7296 requires that exactly one TSi payload and exactly one TSr = payload are present in IKE_AUTH or=20 CREATE_CHILD_SA exchanges (if the latter doesn't rekey IKE SA). However, = both TSi and TSr may contain multiple Traffic Selector substructures.By convention, if SA is being = negotiated due to data packet, then=20 the very first Traffic Selectors in TSi and TSr contain specific network = information from that packet (Traffic Selector in TSi - source IP address/pprotocol/port, Traffic Selector in TSr - = destination IP address/pprotocol/port). The other Traffic Selectors (if any) in TSi/TSr contain specification of = additional (wider) traffic that the Initiator thinks is appropriate to send later over the SA being created. The = Responder could agree on this or it could narrow=20 this Traffic Selectors in its response. Sometimes Initiators include = wildcard traffic selectors in Request allowing=20 Responders to narrow them according to its policy. Hope this helps. Feel free to ask more if you have any concerns. Regards, Valery Smyslov. ----- Original Message -----=20 From: Michael Christian=20 To: ipsec@ietf.org=20 Sent: Saturday, November 21, 2015 4:20 AM Subject: [IPsec] RFC 7296 - Internet Key Exchange Protocol Version 2 = (IKEv2) Hello, I'm investigating a possible RFC 7296 compliance issue and I was = hoping you may be able to shed some light on the RFC for me.=20 =20 In section 2.9 Page 43 regarding multiple traffic selectors: =20 Can two TSi proposals be sent by the initiator every time IKEv2 is = negotiated due to a data packet? Or Is the proposal of an unknown = traffic selector type required before the initiator can respond with = more specific and range TSi's? =20 =20 I appreciate any clarification you may be able to provide.=20 =20 Thank you, Mike Christian =20 Technical Account Manager Fortinet - The New Generation of Secure Gateways 899 Kifer Road | Sunnyvale, CA 94086 | USA =20 -------------------------------------------------------------------------= ----- *** Please note that this message and any attachments may contain = confidential and proprietary material and information and are intended = only for the use of the intended recipient(s). If you are not the = intended recipient, you are hereby notified that any review, use, = disclosure, dissemination, distribution or copying of this message and = any attachments is strictly prohibited. If you have received this email = in error, please immediately notify the sender and destroy this e-mail = and any attachments and all copies, whether electronic or printed. = Please also note that any views, opinions, conclusions or commitments = expressed in this message are those of the individual sender and do not = necessarily reflect the views of Fortinet, Inc., its affiliates, and = emails are not binding on Fortinet and only a writing manually signed by = Fortinet's General Counsel can be a binding commitment of Fortinet to = Fortinet's customers or partners. Thank you. ***=20 -------------------------------------------------------------------------= ----- -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0412_01D125FD.EC168EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mike,
 
I'm not sure I completely understand your=20 question.
 
RFC7296 requires that exactly one TSi payload and = exactly one=20 TSr payload are present in IKE_AUTH or
CREATE_CHILD_SA exchanges (if the latter doesn't = rekey IKE=20 SA). However, both TSi and TSr may contain
multiple Traffic Selector substructures.By = convention, if SA=20 is being negotiated due to data packet, then
the very first Traffic Selectors in TSi and TSr = contain=20 specific network information from that packet (Traffic = Selector
in TSi - source IP address/pprotocol/port, = Traffic=20 Selector in TSr - destination IP address/pprotocol/port).
The other Traffic Selectors (if any) in TSi/TSr = contain=20 specification of additional (wider) traffic that the = Initiator
thinks is appropriate to send later over the SA = being created.=20 The Responder could agree on this or it could narrow
this Traffic Selectors in its = response.=20 Sometimes Initiators include wildcard traffic = selectors in=20 Request allowing
Responders to narrow them according to its=20 policy.
 
Hope this helps. Feel free to ask more if you have = any=20 concerns.
 
Regards,
Valery Smyslov.
 
----- Original Message -----
From:=20 Michael=20 Christian
Sent: Saturday, November 21, = 2015 4:20=20 AM
Subject: [IPsec] RFC 7296 - = Internet Key=20 Exchange Protocol Version 2 (IKEv2)

Hello,

I=92m investigating a possible RFC 7296 = compliance issue and=20 I was hoping you may be able to shed some light on the RFC for me.=20

 

In section 2.9 Page 43 regarding multiple traffic = selectors:

 

Can two TSi proposals be sent by the initiator = every time=20 IKEv2 is negotiated due to a data packet? Or Is the proposal of an = unknown=20 traffic selector type required before the initiator can respond with = more=20 specific and range TSi=92s?  

 

I appreciate any clarification you may be able to = provide.=20

 

Thank you,

Mike Christian

 

Technical Account Manager

Fortinet - The New Generation of Secure=20 Gateways

899 Kifer Road | Sunnyvale, CA 94086 | = USA

 


*** Please note that this message and any attachments may contain = confidential=20 and proprietary material and information and are intended only for the = use of=20 the intended recipient(s). If you are not the intended recipient, you = are=20 hereby notified that any review, use, disclosure, dissemination, = distribution=20 or copying of this message and any attachments is strictly prohibited. = If you=20 have received this email in error, please immediately notify the = sender and=20 destroy this e-mail and any attachments and all copies, whether = electronic or=20 printed. Please also note that any views, opinions, conclusions or = commitments=20 expressed in this message are those of the individual sender and do = not=20 necessarily reflect the views of Fortinet, Inc., its affiliates, and = emails=20 are not binding on Fortinet and only a writing manually signed by = Fortinet's=20 General Counsel can be a binding commitment of Fortinet to Fortinet's=20 customers or partners. Thank you. ***

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0412_01D125FD.EC168EF0-- From nobody Mon Nov 23 08:20:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D894A1A8A05 for ; Mon, 23 Nov 2015 08:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.745 X-Spam-Level: *** X-Spam-Status: No, score=3.745 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_ALL=0.8, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] autolearn=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 roZdvElKHesA for ; Mon, 23 Nov 2015 08:20:30 -0800 (PST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (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 618AF1A89FF for ; Mon, 23 Nov 2015 08:20:30 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (8.15.2/8.15.2) with ESMTP id tANGKQ9p015863; Mon, 23 Nov 2015 11:20:26 -0500 Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id tANGKPVE015859; Mon, 23 Nov 2015 11:20:26 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 23 Nov 2015 11:20:25 -0500 (EST) From: Paul Wouters To: Tommy Pauly In-Reply-To: Message-ID: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> User-Agent: Alpine 2.20 (LFD 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 WG Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 16:20:33 -0000 On Fri, 20 Nov 2015, Tommy Pauly wrote: > On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES128_CBC, AUTH_AES-XCBC) are > justified as being present for the purposes of Internet of Things devices. I tend to think that it would be > more straightforward to have a separate document that explains the preferred algorithms for IoT devices (an > IKEv2 profile for IoT, for example). However, if we do want to keep them in this document, I think it would > help to have a section in the introduction to the document explaining the use case for the IoT devices and > why they are now included in the bis document, whereas they were not relevant yet in RFC 4307. It may also > be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; traditional VPN clients would > generally not be interacting with IoT devices directly, and thus would have little reason to implement > these algorithms. I would suggest if we want to do that, to just use a [*] notation where the [*] gets explained as "For interoperability with IoT clients only" I would not want to leave it out because that will cause us to get servers that won't support IoT devices. Paul From nobody Thu Nov 26 14:58:16 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B151B2B75 for ; Thu, 26 Nov 2015 14:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 7vVfpwaDiXEM for ; Thu, 26 Nov 2015 14:58:12 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 A0CE11B2B71 for ; Thu, 26 Nov 2015 14:58:11 -0800 (PST) Received: by wmvv187 with SMTP id v187so48517027wmv.1 for ; Thu, 26 Nov 2015 14:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5TdxNb/N5cM0VWd37R4rEIhSAqwKWejOhECg6OTg8x8=; b=QwRBU7sKmCQ7LeP5D+syZfBpb0GKiq8fYWE+ZigwpXNSEJhTcIF6FMtA3NytUP5FJY oVmGYWBJlYdPPTD/fPYfwxmTESeZ4yBsfUFHU5+78Z4bg7K5c7PBByMNu+zZpub62hkG XFHywj4qSa6cMSj8sGB8MIwPlwLzRvwLUB+lTZ4LIFvT19WnThQpD4xE8qb0YNpYidfv AHMkLY+A4pxIyLu/bot8wnTLhLbEaAQojImskSefRaphU6O/XbMOk6e9Bh+jDKgwZ8Dv 9Tlohl0DAzKh2Xq1D6KhTd7gplViRFJ0OJHLja7RExi9NN2dOR4DOI5BJl8+7SRM1M8e wDYA== MIME-Version: 1.0 X-Received: by 10.194.76.41 with SMTP id h9mr13253002wjw.57.1448578690286; Thu, 26 Nov 2015 14:58:10 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Thu, 26 Nov 2015 14:58:10 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Thu, 26 Nov 2015 17:58:10 -0500 X-Google-Sender-Auth: 0KISYmZ91twTWHB0fa3Dwr6fa5E Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7bb03e58438edc05257982a6 Archived-At: Cc: IPsecME WG , Tommy Pauly Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 22:58:14 -0000 --047d7bb03e58438edc05257982a6 Content-Type: text/plain; charset=UTF-8 Hi Paul and Tommy, Please find the new update of the draft: 1) text in the introduction has been added to specify the IoT use case, and the motivations for having IoT considerations in this document. 2) IoT has been indicated in the tables with a comment specifying that the requirement is for IoT interoperability. I was not able to have two lines in the postamble. It seems is not accepted as a children for 3) RFCs have been added in the reference section to enable xml2rfc to run properly. The update is available here: https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652 Feel free to comment update the text. BR, Daniel On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters wrote: > On Fri, 20 Nov 2015, Tommy Pauly wrote: > > On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, >> PRF_AES128_CBC, AUTH_AES-XCBC) are >> justified as being present for the purposes of Internet of Things >> devices. I tend to think that it would be >> more straightforward to have a separate document that explains the >> preferred algorithms for IoT devices (an >> IKEv2 profile for IoT, for example). However, if we do want to keep them >> in this document, I think it would >> help to have a section in the introduction to the document explaining the >> use case for the IoT devices and >> why they are now included in the bis document, whereas they were not >> relevant yet in RFC 4307. It may also >> be helpful to qualify the SHOULDs as pertaining more, perhaps, to >> servers; traditional VPN clients would >> generally not be interacting with IoT devices directly, and thus would >> have little reason to implement >> these algorithms. >> > > I would suggest if we want to do that, to just use a [*] notation where > the [*] gets explained as "For interoperability with IoT clients only" > > I would not want to leave it out because that will cause us to get > servers that won't support IoT devices. > > Paul > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7bb03e58438edc05257982a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul and Tommy,

Please find the= new update of the draft:
1) text in the introduction has been added to = specify the IoT use case, and the motivations for having IoT considerations= in this document.
2) IoT has been indi= cated in the tables with a comment specifying that the requirement is for I= oT interoperability. I was not able to have two lines in the postamble. It = seems <artwork> is not accepted as a children for <postamble>
3) RFCs have been added in the reference= section to enable xml2rfc to run properly.

The update is available here:
https://github.co= m/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652

Feel free to comment update the text.
BR,
= Daniel


On Mon, Nov 23, 2015 at 11:20 AM, Paul = Wouters <paul@nohats.ca> wrote:
On Fri, 20 Nov 2015, Tommy Pauly wro= te:

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES12= 8_CBC,=C2=A0AUTH_AES-XCBC) are
justified as being present for the purposes of Internet of Things devices. = I tend to think that it would be
more straightforward to have a separate document that explains the preferre= d algorithms for IoT devices (an
IKEv2 profile for IoT, for example). However, if we do want to keep them in= this document, I think it would
help to have a section in the introduction to the document explaining the u= se case for the IoT devices and
why they are now included in the bis document, whereas they were not releva= nt yet in=C2=A0RFC 4307. It may also
be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; = traditional VPN clients would
generally not be interacting with IoT devices directly, and thus would have= little reason to implement
these algorithms.

 I would suggest if we want to do that, to just use a [*] notation where
the [*] gets explained as "For interoperability with IoT clients only&= quot;

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.

Paul


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

--047d7bb03e58438edc05257982a6-- From nobody Sun Nov 29 12:56:36 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DE61B3AD6 for ; Sun, 29 Nov 2015 12:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0scWkr49yObQ for ; Sun, 29 Nov 2015 12:56:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6FD1B3AD3 for ; Sun, 29 Nov 2015 12:56:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3AC28200A5 for ; Sun, 29 Nov 2015 16:01:34 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A0E3363753; Sun, 29 Nov 2015 15:56:31 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 89405636C4 for ; Sun, 29 Nov 2015 15:56:31 -0500 (EST) From: Michael Richardson To: IPsecme WG X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 20:56:35 -0000 --=-=-= Content-Type: text/plain It is my belief/memory that IKEv2 implementations should NOT limit SA (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifetime. Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. Yet, I'm sure that this was consensus at some point. Maybe I've mis-remembered? What document did I miss? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVltmf4CLcPvd0N1lAQKPkwf/QOP7mbg3Fis3q7/ib5iynJCTPN1WITNt NdavKy0vHUuzx8PRRH726JeCLal/mPUnjsRHTXL42epz+vYLtvcbGHHWzP935YYH cnr0mSNpTmsHR5Lx2xZwJNWQeNeTGXKmoq6FMwW8sJJ/YhaKZhsNj3nY1W4WTmCj uqwW3447gtWiVxStAHZv/EmCJXXf5JiTzVa7hxDbQhlsEecwWZqeLK3cvkFFCBA8 j4Ot02Q0w7cOksde2l8ALiVTVNZSeMv+ce0TeNyhEDUPP50ArIZcf7kQgkjExIUh hiBnT05iJdB83OFAqiv5yeKoru2lNoe8RBWCoZ6pbqMCVMpXwTjRvg== =k9Kt -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 30 07:52:28 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB91B2F51 for ; Mon, 30 Nov 2015 07:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz58vVtXiQg4 for ; Mon, 30 Nov 2015 07:52:26 -0800 (PST) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7EE1B2F44 for ; Mon, 30 Nov 2015 07:52:26 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=fBFhJBiooiYwduOYmXq2pWK4T19fu6YAUbqcXuKjWfAVGL1rpCQPwZXW AOQsNa++qYqG2CZF4MjIvtZauO9fP19WQ2EjBGKvtHbyLsPB9x24VCpb4 iq2J55I6Aw777wgty0bdnKyMK7M6wShpMs18FDSR2lIO1iO27kB/3J0oI 8=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1448898746; x=1480434746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VWaEBVBFhDd2DshVRR288SOFIzrUZPREyBwvspF/zOU=; b=L9kOcr9dJv3b9ergVM+3Cw1mfGWnzAm40UXfMmppUTpLHv0hKa/fGBev LgHIpXj3tUwqq/luQzvPyPfjdqOxaehUA8a3oAlwudFzEcTZf23ptMuUX 9gMcfKy5xmeZ3EJleSYihXs0JzH5a+bEFlaBue321nXeV8X2TRcqAItrt g=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.20,364,1444712400"; d="scan'208";a="734632561" From: To: Thread-Topic: [IPsec] certificate lifetimes vs SA lifetimes Thread-Index: AQHRKuhyuc9ljkr7Z0m0q6+f373My561HPUA Date: Mon, 30 Nov 2015 15:52:21 +0000 Message-ID: References: <22069.1448830591@sandelman.ca> In-Reply-To: <22069.1448830591@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <267CE8BFF246F44EB65D0148798CF2F8@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 15:52:27 -0000 > On Nov 29, 2015, at 3:56 PM, Michael Richardson w= rote: >=20 >=20 > It is my belief/memory that IKEv2 implementations should NOT limit SA > (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifeti= me. >=20 > Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. > Yet, I'm sure that this was consensus at some point. Maybe I've mis-reme= mbered? > What document did I miss? I don't remember one way or the other. It seems perfectly logical to limit= SA lifetime. This certainly seems to be what customers expect (based on s= ome feedback I've seen). It's definitely a nuisance and I would be happy t= o have it optional ("MAY"), but prohibiting it doesn't make sense to me. paul From nobody Mon Nov 30 08:03:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF941A0194 for ; Mon, 30 Nov 2015 08:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YAIXSxlz6mA for ; Mon, 30 Nov 2015 08:03:36 -0800 (PST) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1847D1A034F for ; Mon, 30 Nov 2015 08:03:32 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=mpqMJKwlZ3O7GfYmE/kV3+ON2//rP3vLNQbrf45M2HX7jjFDmSgwIYi9 YvYraecNgfBF2WEJezT64l7HvCepZnj5+NTRdE+dOXXB5I2owcR6EEHQ/ MBDqRnPg8pK3vcJxwtwrMgmL3LzeCNPtexJLF/NuIOy19pDoOUdoxYhhb 4=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1448899414; x=1480435414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pg+8R8HSC8vpljEAzGDvFqzX0M1I6NUBqSYL+IwW2KU=; b=YUoC6JMm6taow7w8AlKgnogLIIfbOhtVZrZ1yslniwuUCfnZif3RTmpZ /VaMWxbiCLoipSulOSEgqXjtSpkG44zNVJHU63dzAoN1nzU6QZ97215as PTRHQOmggU6674d69WH0SVZg2e2zYnmG941ctwM0WVkHFbIob8k5gvW9x c=; X-LoopCount0: from 10.170.28.41 X-IronPort-AV: E=Sophos;i="5.20,364,1444712400"; d="scan'208";a="739032341" From: To: Thread-Topic: [IPsec] certificate lifetimes vs SA lifetimes Thread-Index: AQHRKuhyuc9ljkr7Z0m0q6+f373My561HPUAgAABWoA= Date: Mon, 30 Nov 2015 15:57:13 +0000 Message-ID: <2CB5B591-F042-48D0-8599-6355CFC9A6A6@dell.com> References: <22069.1448830591@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <534B22DD2EE1114DB288369B1ED285E4@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:03:37 -0000 > On Nov 30, 2015, at 10:52 AM, wrote: >=20 >=20 >> On Nov 29, 2015, at 3:56 PM, Michael Richardson = wrote: >>=20 >>=20 >> It is my belief/memory that IKEv2 implementations should NOT limit SA >> (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifet= ime. >>=20 >> Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. >> Yet, I'm sure that this was consensus at some point. Maybe I've mis-rem= embered? >> What document did I miss? >=20 > I don't remember one way or the other. It seems perfectly logical to lim= it SA lifetime. This certainly seems to be what customers expect (based on= some feedback I've seen). It's definitely a nuisance and I would be happy= to have it optional ("MAY"), but prohibiting it doesn't make sense to me. Sorry, I dropped a few words that muddle the meaning. I meant to say "it's= definitely a nuisance to implement limiting, ..." From nobody Mon Nov 30 09:20:42 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9422B1B29E3 for ; Mon, 30 Nov 2015 09:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3-y3cPQdf97 for ; Mon, 30 Nov 2015 09:20:39 -0800 (PST) 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 9E6DE1B29E6 for ; Mon, 30 Nov 2015 09:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1448904039; x=2312817639; 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=7mvKXKCIRiTw8FgGv0gpaK1EFCfZ/NktRCFBJ8ouCEI=; b=yXE0bRpYNNbC+VVXu6qnSB/WcV+Dj5zp9drKoLvYEzZHMnufFP2sl6BNYyQbdUX+ q5g7dqtKKCYxsuwIDUhNLHh5hqh/IVEDbY9bDfOCA1lN7rKULho+6klNpWdHCVJc zJDWWs+eS8di+HKQ34AiyaGq3u3voU/N1Y29A/UAUI6Fpm93hOeRJUM2dv533i+I 2QMEE3aR826143vThGXmBXMSEMmGB1tEMRXdlgxEG5BDHOgc80lXywq65JUoN1Fj Bxe23xRMro0iISUnifPA4fjGgrHJTLMmalLeUik/riCxUiP0G+d5wVDr2d8qjL7B LkDLDs37eIgtOBKVcMyx3w==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id DE.E7.13397.7658C565; Mon, 30 Nov 2015 09:20:39 -0800 (PST) X-AuditID: 11973e13-f798b6d000003455-1f-565c856763c3 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id BC.2B.29392.7658C565; Mon, 30 Nov 2015 09:20:39 -0800 (PST) Received: from da0602a-dhcp187.apple.com (da0602a-dhcp187.apple.com [17.226.23.187]) by orrisroot.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NYN00DDD1IES800@orrisroot.apple.com> for ipsec@ietf.org; Mon, 30 Nov 2015 09:20:38 -0800 (PST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_94EA00DD-BADE-49A4-B2B1-FB9175C2B6F2" MIME-version: 1.0 (Mac OS X Mail 10.0 \(3153\)) From: Tommy Pauly In-reply-to: Date: Mon, 30 Nov 2015 09:20:38 -0800 Message-id: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> To: Daniel Migault X-Mailer: Apple Mail (2.3153) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYpZveGhNmcHUhj8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fliFWNBn0vFnB9ZDYxdVl2MnBwSAiYSk650sEDYYhIX7q1n 62Lk4hAS2Mso8WbJdBaYopPTT7NCJOYzScxctIsFwtnCJNH//DOQw8EhLCAhsXlPIojJLJAk MXWTOEgvr4C+xLKFf9ggKhQk+lvNQcJsAioSx79tYAaxOQWCJXYdOMAGYrMIqEpcX/8fzGYW sJPoeLSYFWKMjUT/kgWMEFu72CSmX50NViQiYCDxcsJONog7ZSXe/pzHBFIkIbCBTWLO8ZPs ExiFZyGcNAvJSbPAdmgD2a+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUSg3MTNHNzPPVC+xoCAn VS85P3cTIygWptsJ72A8vcrqEKMAB6MSD6+EWXSYEGtiWXFl7iFGaQ4WJXHexSUxYUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYhU5KHZg0u9KNU7bieAhbn4vY5ZN3Mq1FzM8LZq0Tj1t3 YNe3AMPk1Y+NPvZs82i0vCx8ahLDt31KsjOZXsscOJ31V2bm+vVrdoZen1Nw2Xa+9oKYetl7 54QiZv77/liteOb0D+sOWwVLOn+w8KgUPl37d3PQ6v7n1hOZUjtEjuszmJ7h9X04Q4mlOCPR UIu5qDgRAEVEMdBmAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUi2FCcpZveGhNm8OA4h8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0fliFWNBn0vFnB9ZDYxdVl2MnBwSAiYSJ6efZoWwxSQu3FvP 1sXIxSEkMJ9JYuaiXSwQzhYmif7nn4EcDg5hAQmJzXsSQUxmgSSJqZvEQXp5BfQlli38wwZR oSDR32oOEmYTUJE4/m0DM4jNKRAssevAATYQm0VAVeL6+v9gNrOAnUTHo8WsEGNsJPqXLGCE 2NrFJjH96mywIhEBA4mXE3ayQdwpK/H25zymCYwCsxCumIXkillgY7WB7NfMELamxP7u5SyY 4hoSnd8msi5gZFvFKFCUmpNYaaaXWFCQk6qXnJ+7iREcuoVROxgbllsdYhTgYFTi4ZUwiw4T Yk0sK67MPcQowcGsJMK7OzcmTIg3JbGyKrUoP76oNCe1+BDjREagLycyS4km5wMjK68k3tDE xMDE2NjM2NjcxJyWwkrivJWr/MOEBNITS1KzU1MLUotgjmLi4JRqYDS/VjRPqETMf3k7MO14 RBzOrlJqPm2fd/vjjt2vJkj+avg4b6uSwm2fU9Hnpe1WfapTn5qpmbEk/FHpgbw3R5T+Xfhh J1ahzJq2ZO+Ep0ynCrqTJk/+qCZ4P1lhn1Tq3rvBN1n9HL5GtW79PdH4rIKRlfe1vgfLFJm2 Gv2NNZ7Zbe+d+ypDUYmlOCPRUIu5qDgRACCGy3rQAgAA Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 17:20:41 -0000 --Apple-Mail=_94EA00DD-BADE-49A4-B2B1-FB9175C2B6F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Daniel, Thanks for making these changes! I think this makes the document much = clearer. With regards to the Introduction, it may be beneficial at this point to = have subsections of the introduction to make it easier to parse. Right = now there seem to be several topics that don=E2=80=99t necessarily flow = into one another: explaining mandatory-to-implement algorithms, = explaining which version of IKE is relevant, explaining deprecation of = algorithms, and the IoT section. Thanks, tommy > On Nov 26, 2015, at 2:58 PM, Daniel Migault = wrote: >=20 > Hi Paul and Tommy,=20 >=20 > Please find the new update of the draft: > 1) text in the introduction has been added to specify the IoT use = case, and the motivations for having IoT considerations in this = document. > 2) IoT has been indicated in the tables with a comment specifying that = the requirement is for IoT interoperability. I was not able to have two = lines in the postamble. It seems is not accepted as a children = for > 3) RFCs have been added in the reference section to enable xml2rfc to = run properly. >=20 > The update is available here: > = https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d2644= 3652 = >=20 > Feel free to comment update the text. >=20 > BR,=20 > Daniel >=20 >=20 > On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters > wrote: > On Fri, 20 Nov 2015, Tommy Pauly wrote: >=20 > On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, = PRF_AES128_CBC, AUTH_AES-XCBC) are > justified as being present for the purposes of Internet of Things = devices. I tend to think that it would be > more straightforward to have a separate document that explains the = preferred algorithms for IoT devices (an > IKEv2 profile for IoT, for example). However, if we do want to keep = them in this document, I think it would > help to have a section in the introduction to the document explaining = the use case for the IoT devices and > why they are now included in the bis document, whereas they were not = relevant yet in RFC 4307. It may also > be helpful to qualify the SHOULDs as pertaining more, perhaps, to = servers; traditional VPN clients would > generally not be interacting with IoT devices directly, and thus would = have little reason to implement > these algorithms. >=20 > I would suggest if we want to do that, to just use a [*] notation = where > the [*] gets explained as "For interoperability with IoT clients only" >=20 > I would not want to leave it out because that will cause us to get > servers that won't support IoT devices. >=20 > Paul >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 --Apple-Mail=_94EA00DD-BADE-49A4-B2B1-FB9175C2B6F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Daniel,

Thanks for making these changes! I = think this makes the document much clearer.

With regards to the Introduction, it = may be beneficial at this point to have subsections of the introduction = to make it easier to parse. Right now there seem to be several topics = that don=E2=80=99t necessarily flow into one another: explaining = mandatory-to-implement algorithms, explaining which version of IKE is = relevant, explaining deprecation of algorithms, and the IoT = section.

Thanks,
tommy

On = Nov 26, 2015, at 2:58 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi Paul and Tommy,

Please find the new update of the = draft:
1) text in the introduction has been added to = specify the IoT use case, and the motivations for having IoT = considerations in this document.
2) IoT has been indicated in the tables with a = comment specifying that the requirement is for IoT interoperability. I = was not able to have two lines in the postamble. It seems = <artwork> is not accepted as a children for <postamble>
3) RFCs have been added in = the reference section to enable xml2rfc to run properly.
The update is available = here:
https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3= 311938d26443652

Feel free to comment update the text.

BR,
Daniel


On Mon, = Nov 23, 2015 at 11:20 AM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 20 Nov = 2015, Tommy Pauly wrote:

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, = PRF_AES128_CBC, AUTH_AES-XCBC) are
justified as being present for the purposes of Internet of Things = devices. I tend to think that it would be
more straightforward to have a separate document that explains the = preferred algorithms for IoT devices (an
IKEv2 profile for IoT, for example). However, if we do want to keep them = in this document, I think it would
help to have a section in the introduction to the document explaining = the use case for the IoT devices and
why they are now included in the bis document, whereas they were not = relevant yet in RFC 4307. It may also
be helpful to qualify the SHOULDs as pertaining more, perhaps, to = servers; traditional VPN clients would
generally not be interacting with IoT devices directly, and thus would = have little reason to implement
these algorithms.

 I would suggest if we want to do that, to just use a [*] notation = where
the [*] gets explained as "For interoperability with IoT clients = only"

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.

Paul


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


= --Apple-Mail=_94EA00DD-BADE-49A4-B2B1-FB9175C2B6F2-- From nobody Mon Nov 30 10:22:19 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486451B2F8A for ; Mon, 30 Nov 2015 10:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 rjNdCWRjgNKm for ; Mon, 30 Nov 2015 10:22:16 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 0138E1B2F86 for ; Mon, 30 Nov 2015 10:22:16 -0800 (PST) Received: by wmww144 with SMTP id w144so141579227wmw.1 for ; Mon, 30 Nov 2015 10:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PUvbcGyGWEJX+g8jhD92bXfo8WL/LbNw7jQFvIY6c5s=; b=OvLXllThKo5t4+eKmKb0HaEajD/NKGVFIWJS0wlAxg9qcJMOT7aE5uTW+Va0SYmV5w t6hqlOxg1xo5gWbXPFbxEq32Bd8wq16SfbQ28Yrb06wq0Caoo0h20qErPjBmGJ5EJ7SW tXlOmedwZ5AreoGNQ8OSyYgDsGy8/v7jbcp97LY8dhe8UYI5H2SsUg9j3asyiuP25htq 7Tp0oANXFwW9gdc3+INv6dt3Xy4QgVl/LfeDfx+d/N0wJC2KDx3Vm7kbsxfd7q1Cp2nV SoR4cEYVQEFHS8lsow9O9TuJxq+94rXsU4DrYSSE1uX+diNkE+7AEcNH4OhKJ2+3w0wV GyZA== MIME-Version: 1.0 X-Received: by 10.28.111.151 with SMTP id c23mr30781666wmi.28.1448907734538; Mon, 30 Nov 2015 10:22:14 -0800 (PST) Sender: mglt.ietf@gmail.com Received: by 10.194.9.106 with HTTP; Mon, 30 Nov 2015 10:22:14 -0800 (PST) In-Reply-To: References: <0748F101-7104-4F07-B440-31A9CF63BE32@gmail.com> <9EBE3C6E-C7F2-4327-B4E2-3363BD96ECC1@gmail.com> <56421D6F.7080506@gmail.com> <22082.23345.969526.729086@fireball.acr.fi> <564A1549.1010001@gmail.com> Date: Mon, 30 Nov 2015 13:22:14 -0500 X-Google-Sender-Auth: 9T3hcUZ7Q-3l2mKdCwKAsGEipBc Message-ID: From: Daniel Migault To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a1147bf20d462fd0525c61e94 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] RFC 4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:22:18 -0000 --001a1147bf20d462fd0525c61e94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tommy, Thanks for the proposition Tommy, I thnik that will clearer to have dedicated subsections in the intro. Here are the subsection I would propose. I am waiting for the WG feed back before updating the draft, so please let m eknow whether: A) You like the idea of subsection in the intro B) You DO NOT like the idea of subsections C) If you like the following: c1) The need for mandatory-to-implement algorithms c2) The scope of the document (IKEv2 + implementer) c3) Updating algorithm status (deprecation of algorithms and the IoT section) D) If you have other propositions. I will update the draft this week according to the responses. BR, Daniel On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly wrote: > Hi Daniel, > > Thanks for making these changes! I think this makes the document much > clearer. > > With regards to the Introduction, it may be beneficial at this point to > have subsections of the introduction to make it easier to parse. Right no= w > there seem to be several topics that don=E2=80=99t necessarily flow into = one > another: explaining mandatory-to-implement algorithms, explaining which > version of IKE is relevant, explaining deprecation of algorithms, and the > IoT section. > > Thanks, > tommy > > On Nov 26, 2015, at 2:58 PM, Daniel Migault > wrote: > > Hi Paul and Tommy, > > Please find the new update of the draft: > 1) text in the introduction has been added to specify the IoT use case, > and the motivations for having IoT considerations in this document. > 2) IoT has been indicated in the tables with a comment specifying that th= e > requirement is for IoT interoperability. I was not able to have two lines > in the postamble. It seems is not accepted as a children for > > 3) RFCs have been added in the reference section to enable xml2rfc to run > properly. > > The update is available here: > > https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d264= 43652 > > Feel free to comment update the text. > > BR, > Daniel > > > On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters wrote: > >> On Fri, 20 Nov 2015, Tommy Pauly wrote: >> >> On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, >>> PRF_AES128_CBC, AUTH_AES-XCBC) are >>> justified as being present for the purposes of Internet of Things >>> devices. I tend to think that it would be >>> more straightforward to have a separate document that explains the >>> preferred algorithms for IoT devices (an >>> IKEv2 profile for IoT, for example). However, if we do want to keep the= m >>> in this document, I think it would >>> help to have a section in the introduction to the document explaining >>> the use case for the IoT devices and >>> why they are now included in the bis document, whereas they were not >>> relevant yet in RFC 4307. It may also >>> be helpful to qualify the SHOULDs as pertaining more, perhaps, to >>> servers; traditional VPN clients would >>> generally not be interacting with IoT devices directly, and thus would >>> have little reason to implement >>> these algorithms. >>> >> >> I would suggest if we want to do that, to just use a [*] notation where >> the [*] gets explained as "For interoperability with IoT clients only" >> >> I would not want to leave it out because that will cause us to get >> servers that won't support IoT devices. >> >> Paul >> >> >> _______________________________________________ >> 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 > > --001a1147bf20d462fd0525c61e94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tommy,

Thanks for the prop= osition Tommy, I thnik that will clearer to have dedicated subsections in t= he intro. Here are the subsection I would propose. I am waiting for the WG = feed back before updating the draft, so please let m eknow whether:

= A) You like the idea of subsection in the intro
B) You DO NOT like= the idea of subsections

C) If you like the following:=C2= =A0 =C2=A0
=C2=A0=C2=A0=C2=A0 c1) The need for mandator= y-to-implement algorithms
=C2=A0=C2=A0=C2=A0 c2) The scope of the docume= nt (IKEv2 + implementer)
=C2=A0=C2=A0=C2=A0 c3) Updating algorithm stat= us (deprecation of algorithms and=20 the IoT section)

D) If you have other propositions.
<= br>
I will update the draft this week according to the responses.=
=C2=A0
BR,
Daniel


On Mon, No= v 30, 2015 at 12:20 PM, Tommy Pauly <tpauly@apple.com> wrote:=
Hi Daniel,

Thanks for making these changes! I thi= nk this makes the document much clearer.

With rega= rds to the Introduction, it may be beneficial at this point to have subsect= ions of the introduction to make it easier to parse. Right now there seem t= o be several topics that don=E2=80=99t necessarily flow into one another: e= xplaining mandatory-to-implement algorithms, explaining which version of IK= E is relevant, explaining deprecation of algorithms, and the IoT section.

Thanks,
tommy

On Nov 26, 2015, at 2:58 PM, Danie= l Migault <daniel.migault@ericsson.com> wrote:

Hi Paul and Tommy,

Please find the new update of= the draft:
1) text in the introduction has been added to specify the Io= T use case, and the motivations for having IoT considerations in this docum= ent.
2) IoT has been indicated in the t= ables with a comment specifying that the requirement is for IoT interoperab= ility. I was not able to have two lines in the postamble. It seems <artw= ork> is not accepted as a children for <postamble>
3) RFCs have been added in the reference section to en= able xml2rfc to run properly.

The u= pdate is available here:
https://githu= b.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652
Feel free to comment update the text.
BR,
Daniel


On Mon, Nov 23, 2015 at 11:20 AM, P= aul Wouters <paul@nohats.ca> wrote:
On Fri, 20 Nov 2015, Tommy Pauly wrote:
On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES12= 8_CBC,=C2=A0AUTH_AES-XCBC) are
justified as being present for the purposes of Internet of Things devices. = I tend to think that it would be
more straightforward to have a separate document that explains the preferre= d algorithms for IoT devices (an
IKEv2 profile for IoT, for example). However, if we do want to keep them in= this document, I think it would
help to have a section in the introduction to the document explaining the u= se case for the IoT devices and
why they are now included in the bis document, whereas they were not releva= nt yet in=C2=A0RFC 4307. It may also
be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; = traditional VPN clients would
generally not be interacting with IoT devices directly, and thus would have= little reason to implement
these algorithms.

 I would suggest if we want to do that, to just use a [*] notation where
the [*] gets explained as "For interoperability with IoT clients only&= quot;

I would not want to leave it out because that will cause us to get
servers that won't support IoT devices.
Paul


_______________________________________________
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


--001a1147bf20d462fd0525c61e94-- From nobody Mon Nov 30 19:15:40 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C21B388E for ; Mon, 30 Nov 2015 19:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8SbgoLTBJGf for ; Mon, 30 Nov 2015 19:15:31 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4701B388F for ; Mon, 30 Nov 2015 19:15:27 -0800 (PST) Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0367.namprd09.prod.outlook.com (10.160.247.21) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 03:15:22 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 03:15:21 +0000 From: "Waltermire, David A." To: "IPsec@ietf.org" Thread-Topic: Review of draft-ietf-ipsecme-ddos-protection-02 Thread-Index: AdEr4+tdhV9JhV9OQz+OdTVdFG4usw== Date: Tue, 1 Dec 2015 03:15:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.227.39] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0367; 5:ogiIcd4zZIO5KCjAJx0M6KBycy36Ikhl4kdlG18LIYLcMmYEbR3kfvybgYuFRxKKMRQ0X5udsYarvQqZ6A/R76muYu326HyYf4Z/W0eYN8NkiTlsHcr2EnMNer1muQRYXiDKrIP0hrUBmJv/FUYr0A==; 24:LFnzfN2s4LS3xwDD3CG3i2+t2smV+CcA3dF5ZAkuha9dkmSUwq5Q/CD88Y4/nmZ56Q42rMgotGjHcQR1kUuv4O42socK8CjvoqnuAYjzESY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0367; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR09MB0367; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0367; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(110136002)(86362001)(6116002)(40100003)(102836003)(101416001)(5004730100002)(66066001)(5002640100001)(81156007)(87936001)(19580395003)(5008740100001)(229853001)(5001960100002)(586003)(77096005)(2351001)(189998001)(99286002)(15975445007)(3846002)(790700001)(106356001)(1220700001)(92566002)(5003600100002)(74316001)(122556002)(105586002)(230783001)(107886002)(19300405004)(2501003)(54356999)(33656002)(76576001)(16236675004)(97736004)(450100001)(19625215002)(50986999)(1096002)(10400500002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0367; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0365FB3FEEA870743DDFDD21F00F0DM2PR09MB0365namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 03:15:21.6124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0367 Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:15:39 -0000 --_000_DM2PR09MB0365FB3FEEA870743DDFDD21F00F0DM2PR09MB0365namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find my comments on draft-ietf-ipsecme-ddos-protection-02 below. Ove= rall I found the content of the draft to be very good. Here is a quick summary of my comments: - There are still some placeholder sections in the draft that need to be wr= itten (i.e. sections 3.1, 3.2, 11). - I don't recall seeing many comments on the list, if any, on sections 6 th= rough 10. In general I'd like to see more review and comments on these sect= ions in the draft before the draft goes to WGLC. - Also related to sections 6 - 10, there appear to be a number of requireme= nts that are not capitalized according to RFC 2119 in these sections. Anyon= e willing to volunteer to review the draft and make recommendations for RCF= 2119 wording changes? - I also found quite a few NITS relating to spelling, grammar, and punctuat= ion. Given the number of nits, it would be good to produce a clean draft fo= r additional review, so we don't duplicate review effort. Yoav and Valery, do you have a sense of when you can turn around an update = to this draft with these comments addressed? Regards, Dave Comments/Questions: ---------------------------- General: There seem to be places in the draft where RFC2119 wording should be used = (i.e. sections 6 - 10). It would be good to see more review and comments on= this section to make sure we are 1) providing appropriate guidance and 2) = using the appropriate normative language. For example in section 6: s/DDoS attack, it is suggested that no Cookie or puzzles be used/DDoS attac= k, it is RECOMMENDED that no Cookie or puzzles be used/ Section 3: Is it possible if "the same value is sent to all Initiators", that the atta= cker could coordinate solving the puzzle across a number of attack hosts to= achieve some efficiency? If so, it might be good to recommend that a new c= hallenge be sent to each host for each SA. Sections 3.1 and 3.2 need to be completed or removed. Some of this looks li= ke it may be included in Section 8. It also looks to be fully described in = sections 10.1 and 10.2. Some work is needed to sort this out. Section 5: I am not a fan of using the phrase "but the current thinking", since this m= ay be read many years from now. This paragraph should be reworked to make i= t more temporally relevant. Perhaps you can tie the thinking directly to th= e degree of IPv6 NAT usage directly and avoid the temporal qualifier? Section 6: The phrase "the amount of failed IKE_AUTH exchanges to never exceed the thr= eshold of attack detection" doesn't make sense and needs to be reworded. In the phrase "only defensive measure is the monitoring", it is not clear w= hat is being monitored. I am assuming this is about monitoring half-open SA= s. This should be clarified. Section 8.2.1: Shouldn't the puzzle used in the IKE_SA_INIT be different than the puzzle u= sed in the IKE_AUTH exchange to prevent the initiator from sending back a c= ached response or am I misunderstanding something? Same comment for section= 8.2.1.2. Section 11: The security consideration section needs to be completed. Perhaps this coul= d be made a summary of the threats and related countermeasures described in= the document? Nits: ------ In section 1: s/half-open IKE SA (Security Association)/half-open Internet Key Exchange (= IKE) Security Association (SA)/ s/Exchange, but if/Exchange. If/ s/against an Internet Key Exchange (IKE) Responder/against an IKE Responder= / s/such as bot-nets can/such as in the case of a bot-net, can/ s/allowed for one peer address/allowed per peer address/ s/Initiator, by/Initiator by/ s/attacker's CPU to/attacker's CPU, to/ In section 2: s/re-uses a D-H/re-uses a Diffie-Hellman (D-H)/ s/a responder SPI./a responder Security Parameter Index (SPI)./ s/them - it's enough/them; it's enough/ s/So if a half-open/For example, if a half-open/ The example text states that "a half-open SA takes 1 KB". The "takes 1 KB" = doesn't look like it is relevant to the example. Consider removing this tex= t as follows: s/a half-open SA takes 1 KB and it's kept for 1 minute/a half-open SA is ke= pt for 1 minute/ s/Make each of those more expensive by introducing a puzzle, and you're/By = introducing a puzzle, each half-open SA becomes more expensive, making it m= ore/ s/database in no longer/database is no longer/ s/because each one of them allows/because each one allows/ Section 3: s/BitCoins ([bitcoins])/BitCoins [bitcoins]/ The sentence containing the following text is difficult to parse even with = the following change. Consider rewording. s/rate-limiting in Section 5/rate-limiting method described in Section 5/ s/of a PRF algorithm/of a Pseudo-Random Function (PRF) algorithm/ In table 1, it is not clear what the unit of time is. This should be listed= in the table header and the descriptive text below. Section 4: s/derive the Diffie-Hellman shared/derive the D-H shared/ (Note: The use of= D-H is not used very consistently in the draft. If the intent is to spell = it out, this should be done consistently.) s/prefixes from which are considered suspect/prefixes that are considered s= uspect/ Section 5: While the text "if a certain purveyor of beverages resembling coffee provid= es" is humorous, it may be better to choose a more mundane example. s/that a sufficiently resourceful (in the sense that they have a lot of res= ources) adversary/that an adversary with sufficient CPU resources/ The last sentence in this section starting with "Regardless" is difficult t= o parse. Consider rephrasing. Section 6: s/section 2.16 or RFC 7296/section 2.16 of RFC 7296/ s/Typical figures might/Typical measures might/ Section 8.1: s/optionally contain COOKIE notification/optionally contain a COOKIE notifi= cation/ s/in Section 6, IKE responder/in Section 6, the IKE responder/ The following wording is confusing. Consider rephrasing: then it either requests the initiator to return a cookie or, if the volume is so high, that puzzles need to be used for defense, it requests the initiator to solve a puzzle. s/puzzle even being under attack/puzzle while being under attack/ s/to have chances to/to have a chance to/ s/Only those requests, that contain COOKIE notification, must/Only the requ= ests that contain COOKIE notification must/ Section 8.1.1.3: s/to those of them, which were created spending more initiator's/to the req= uests which were created by spending more of the initiator's/ The following occurs twice in this section: s/initiator spent a little resources/initiator spent little resources/ s/contais fewer bits, than were/contains fewer bits than were/ s/less resources, than expected/less resources than expected/ s/the following considerations./the following considerations:/ Section 8.1.2: s/If initiator receives puzzle/If the initiator receives a puzzle,/ s/will ignore PUZZLE notification as unrecognized/will ignore the PUZZLE no= tification as an unrecognized/ s/MAY ignore puzzle/MAY ignore the PUZZLE notification/ s/puzzle of requested difficulty/the puzzle of the requested difficulty/ s/message contains PUZZLE notification/message contains a PUZZLE notificati= on/ s/contain cookie, then/contain a cookie, then/ (should cookie be capitalize= d here?) s/malformed, because it/malformed because it/ (note this paragraph contains= multiple "buts". It would be good to rephrase this run-on sentence.) s/wrong and IKE SA cannot/wrong and the IKE SA cannot/ s/If initiator supports puzzles/If the initiator supports puzzles/ s/payload called Puzzle Solution/payload called a Puzzle Solution/ Section 8.1.2.1: s/IKE initiator is to find/the IKE initiator is to find/ Note: There is not a section 8.1.2.2. Perhaps this text should be folded in= to the parent section? Section 8.1.3: s/least contain COOKIE notification/least contain a COOKIE notification/ s/to those of them, which were created/to requests that were created by/ Multiple matches of the following in this section: s/spent a little resources/spent little resources/ s/that puzzle was given/that the puzzle was given/ s/doesn't contain PS payload/doesn't contain a PS payload/ Section 8.1.4: s/would be its chances ro be served/its chances are to be served/ s/the responder takes decision/the responder makes the decision/ s/request are implementation dependant/request is implementation dependent/ s/number of alailable memory/number of available memory/ s/that number of the/that number of/ Section 8.2: s/to exhaust responder's CPU/to exhaust a responder's CPU/ s/keys after unsuccessful verification of IKE_AUTH/keys after an unsuccessf= ul verification of the IKE_AUTH/ s/responder includes puzzle/responder includes a puzzle/ s/initiator includes puzzle/initiator includes a puzzle/ s/selected so, that the/selected so that the/ s/the puzzle, than the responder/the puzzle than the responder/ s/IKE SA states, that receive/IKE SA states that receive/ s/messages, but cannot decrypt them due to the/messages that cannot be decr= ypted due to/ Section 8.2.1.1: s/should be chosen so,/should be chosen so/ s/solve the puzzle, than/solve the puzzle than/ s/compute Diffie-Hellman shared secret and the keys,/compute the D-H shared= secret and the keys/ Section 8.2.2: "Section 2.5.3 of RFC7383" should include a reference. Section 8.2.2.1: Note: There is not a section 8.2.2.2. Perhaps this text should be folded in= to the parent section? s/the same, the difference is in constructing of/the same; the difference i= s in the construction of/ s/| SPIr) has sufficient/| SPIr) has a sufficient/ Section 8.2.3: s/initiator to solve puzzle/initiator to solve a puzzle/ s/message containing solution for the puzzle is received/message containing= a solution for the puzzle is received,/ s/operations - computing/operations i.e. computing/ s/due to packets loss and/due to packet loss and/ Section 9: s/usually no much traffic/usually not much traffic/ s/rekey or delete/rekey, or delete/ s/Child SA lifetimes there/Child SA lifetimes, there/ s/must be no more than a few such exchanges/are typically no more than a fe= w such exchanges/ s/can initiate new exchange/can initiate a new exchange/ s/many exchanges, that could/many exchanges that could/ s/becomes more real threat/becomes more of a real threat/ s/that allow it to escape/allowing it to escape/ s/IKE sessions. However/ IKE sessions; however,/ s/exchanges, that would potentially/exchanges that could/ s/that reason if is NOT/that reason it is NOT/ s/increase IKEv2 window size/increase the IKEv2 window size/ s/making possible to process/making it possible to process/ s/should not be too long not to cause IKE SA/SHOULD NOT be too long to avoi= d causing the IKE SA/ s/delete IKE SA with/delete the IKE SA with/ Section 10.1: s/used by IKE responder/used by the IKE responder/ Section 10.2: s/called Puzzle Solution/called the Puzzle Solution/ --_000_DM2PR09MB0365FB3FEEA870743DDFDD21F00F0DM2PR09MB0365namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find my comments on draft-ietf-ipsecme-ddos-p= rotection-02 below. Overall I found the content of the draft to be very goo= d.

 

Here is a quick summary of my comments:

- There are still some placeholder sections in the d= raft that need to be written (i.e. sections 3.1, 3.2, 11).

- I don’t recall seeing many comments on the l= ist, if any, on sections 6 through 10. In general I’d like to see mor= e review and comments on these sections in the draft before the draft goes = to WGLC.

- Also related to sections 6 – 10, there appea= r to be a number of requirements that are not capitalized according to RFC = 2119 in these sections. Anyone willing to volunteer to review the draft and= make recommendations for RCF2119 wording changes?

- I also found quite a few NITS relating to spelling= , grammar, and punctuation. Given the number of nits, it would be good to p= roduce a clean draft for additional review, so we don’t duplicate rev= iew effort.

 

Yoav and Valery, do you have a sense of when you can= turn around an update to this draft with these comments addressed?

 

Regards,

Dave

 

Comments/Questions:

----------------------------

 

General:

 

There seem to be places in the draft where RFC2119 &= nbsp;wording should be used (i.e. sections 6 - 10). It would be good to see= more review and comments on this section to make sure we are 1) providing = appropriate guidance and 2) using the appropriate normative language. For example in section 6:

 

s/DDoS attack, it is suggested that no Cookie or puz= zles be used/DDoS attack, it is RECOMMENDED that no Cookie or puzzles be us= ed/

 

Section 3:

 

Is it possible if “the same value is sent to a= ll Initiators”, that the attacker could coordinate solving the puzzle= across a number of attack hosts to achieve some efficiency? If so, it migh= t be good to recommend that a new challenge be sent to each host for each SA.

 

Sections 3.1 and 3.2 need to be completed or removed= . Some of this looks like it may be included in Section 8. It also looks to= be fully described in sections 10.1 and 10.2. Some work is needed to sort = this out.

 

Section 5:

 

I am not a fan of using the phrase “but the cu= rrent thinking”, since this may be read many years from now. This par= agraph should be reworked to make it more temporally relevant. Perhaps you = can tie the thinking directly to the degree of IPv6 NAT usage directly and avoid the temporal qualifier?

 

Section 6:

 

The phrase “the amount of failed IKE_AUTH exch= anges to never exceed the threshold of attack detection” doesn’= t make sense and needs to be reworded.

 

In the phrase “only defensive measure is the m= onitoring”, it is not clear what is being monitored. I am assuming th= is is about monitoring half-open SAs. This should be clarified.<= /p>

 

Section 8.2.1:

 

Shouldn’t the puzzle used in the IKE_SA_INIT b= e different than the puzzle used in the IKE_AUTH exchange to prevent the in= itiator from sending back a cached response or am I misunderstanding someth= ing? Same comment for section 8.2.1.2.

 

Section 11:

 

The security consideration section needs to be compl= eted. Perhaps this could be made a summary of the threats and related count= ermeasures described in the document?

 

Nits:

------

 

In section 1:

 

s/half-open IKE SA (Security Association)/half-open = Internet Key Exchange (IKE) Security Association (SA)/

 

s/Exchange, but if/Exchange. If/

 

s/against an Internet Key Exchange (IKE) Responder/a= gainst an IKE Responder/

 

s/such as bot-nets can/such as in the case of a bot-= net, can/

 

s/allowed for one peer address/allowed per peer addr= ess/

 

s/Initiator, by/Initiator by/

 

s/attacker's CPU to/attacker's CPU, to/

 

In section 2:

 

s/re-uses a D-H/re-uses a Diffie-Hellman (D-H)/=

 

s/a responder SPI./a responder Security Parameter In= dex (SPI)./

 

s/them - it's enough/them; it's enough/

 

s/So if a half-open/For example, if a half-open/

 

The example text states that “a half-open SA t= akes 1 KB”. The “takes 1 KB” doesn’t look like it i= s relevant to the example. Consider removing this text as follows:

s/a half-open SA takes 1 KB and it's kept for 1 minu= te/a half-open SA is kept for 1 minute/

 

s/Make each of those more expensive by introducing a= puzzle, and you're/By introducing a puzzle, each half-open SA becomes more= expensive, making it more/

 

s/database in no longer/database is no longer/<= /o:p>

 

s/because each one of them allows/because each one a= llows/

 

Section 3:

 

s/BitCoins ([bitcoins])/BitCoins [bitcoins]/

 

The sentence containing the following text is diffic= ult to parse even with the following change. Consider rewording.=

s/rate-limiting in Section 5/rate-limiting method de= scribed in Section 5/

 

s/of a PRF algorithm/of a Pseudo-Random Function (PR= F) algorithm/

 

In table 1, it is not clear what the unit of time is= . This should be listed in the table header and the descriptive text below.=

 

Section 4:

 

s/derive the Diffie-Hellman shared/derive the D-H sh= ared/ (Note: The use of D-H is not used very consistently in the draft. If = the intent is to spell it out, this should be done consistently.)

 

s/prefixes from which are considered suspect/prefixe= s that are considered suspect/

 

Section 5:

 

While the text “if a certain purveyor of bever= ages resembling coffee provides” is humorous, it may be better to cho= ose a more mundane example.

 

s/that a sufficiently resourceful (in the sense that= they have a lot of resources) adversary/that an adversary with sufficient = CPU resources/

 

The last sentence in this section starting with R= 20;Regardless” is difficult to parse. Consider rephrasing.=

 

Section 6:

 

s/section 2.16 or RFC 7296/section 2.16 of RFC 7296/=

 

s/Typical figures might/Typical measures might/=

 

Section 8.1:

 

s/optionally contain COOKIE notification/optionally = contain a COOKIE notification/

 

s/in Section 6, IKE responder/in Section 6, the IKE = responder/

 

The following wording is confusing. Consider rephras= ing:

 

   then it either requests the initiator t= o return a cookie or, if the

   volume is so high, that puzzles need to= be used for defense, it

   requests the initiator to solve a puzzl= e.

 

s/puzzle even being under attack/puzzle while being = under attack/

 

s/to have chances to/to have a chance to/=

 

s/Only those requests, that contain COOKIE notificat= ion, must/Only the requests that contain COOKIE notification must/

 

Section 8.1.1.3:

 

s/to those of them, which were created spending more= initiator's/to the requests which were created by spending more of the ini= tiator's/

 

The following occurs twice in this section:

s/initiator spent a little resources/initiator spent= little resources/

 

s/contais fewer bits, than were/contains fewer bits = than were/

 

s/less resources, than expected/less resources than = expected/

 

s/the following considerations./the following consid= erations:/

 

Section 8.1.2:

 

s/If initiator receives puzzle/If the initiator rece= ives a puzzle,/

 

s/will ignore PUZZLE notification as unrecognized/wi= ll ignore the PUZZLE notification as an unrecognized/

 

s/MAY ignore puzzle/MAY ignore the PUZZLE notificati= on/

 

s/puzzle of requested difficulty/the puzzle of the r= equested difficulty/

 

s/message contains PUZZLE notification/message conta= ins a PUZZLE notification/

 

s/contain cookie, then/contain a cookie, then/ (shou= ld cookie be capitalized here?)

 

s/malformed, because it/malformed because it/ (note = this paragraph contains multiple “buts”. It would be good to re= phrase this run-on sentence.)

 

s/wrong and IKE SA cannot/wrong and the IKE SA canno= t/

 

s/If initiator supports puzzles/If the initiator sup= ports puzzles/

 

s/payload called Puzzle Solution/payload called a Pu= zzle Solution/

 

Section 8.1.2.1:

 

s/IKE initiator is to find/the IKE initiator is to f= ind/

 

Note: There is not a section 8.1.2.2. Perhaps this t= ext should be folded into the parent section?

 

Section 8.1.3:

 

s/least contain COOKIE notification/least contain a = COOKIE notification/

 

s/to those of them, which were created/to requests t= hat were created by/

 

Multiple matches of the following in this section:

s/spent a little resources/spent little resources/

 

s/that puzzle was given/that the puzzle was given/

 

s/doesn't contain PS payload/doesn't contain a PS pa= yload/

 

Section 8.1.4:

 

s/would be its chances ro be served/its chances are = to be served/

 

s/the responder takes decision/the responder makes t= he decision/

 

s/request are implementation dependant/request is im= plementation dependent/

 

s/number of alailable memory/number of available mem= ory/

 

s/that number of the/that number of/

 

Section 8.2:

 

s/to exhaust responder's CPU/to exhaust a responder'= s CPU/

 

s/keys after unsuccessful verification of IKE_AUTH/k= eys after an unsuccessful verification of the IKE_AUTH/

 

s/responder includes puzzle/responder includes a puz= zle/

 

s/initiator includes puzzle/initiator includes a puz= zle/

 

s/selected so, that the/selected so that the/

 

s/the puzzle, than the responder/the puzzle than the= responder/

 

s/IKE SA states, that receive/IKE SA states that rec= eive/

 

s/messages, but cannot decrypt them due to the/messa= ges that cannot be decrypted due to/

 

Section 8.2.1.1:

 

s/should be chosen so,/should be chosen so/

 

s/solve the puzzle, than/solve the puzzle than/=

 

s/compute Diffie-Hellman shared secret and the keys,= /compute the D-H shared secret and the keys/

 

Section 8.2.2:

 

“Section 2.5.3 of RFC7383” should includ= e a reference.

 

Section 8.2.2.1:

 

Note: There is not a section 8.2.2.2. Perhaps this t= ext should be folded into the parent section?

 

s/the same, the difference is in constructing of/the= same; the difference is in the construction of/

 

s/| SPIr) has sufficient/| SPIr) has a sufficient/

 

Section 8.2.3:

 

s/initiator to solve puzzle/initiator to solve a puz= zle/

 

s/message containing solution for the puzzle is rece= ived/message containing a solution for the puzzle is received,/<= /p>

 

s/operations – computing/operations i.e. compu= ting/

 

s/due to packets loss and/due to packet loss and/

 

Section 9:

 

s/usually no much traffic/usually not much traffic/<= o:p>

 

s/rekey or delete/rekey, or delete/

 

s/Child SA lifetimes there/Child SA lifetimes, there= /

 

s/must be no more than a few such exchanges/are typi= cally no more than a few such exchanges/

 

s/can initiate new exchange/can initiate a new excha= nge/

 

s/many exchanges, that could/many exchanges that cou= ld/

 

s/becomes more real threat/becomes more of a real th= reat/

 

s/that allow it to escape/allowing it to escape/

 

s/IKE sessions.  However/ IKE sessions; however= ,/

 

s/exchanges, that would potentially/exchanges that c= ould/

 

s/that reason if is NOT/that reason it is NOT/<= /o:p>

 

s/increase IKEv2 window size/increase the IKEv2 wind= ow size/

 

s/making possible to process/making it possible to p= rocess/

 

s/should not be too long not to cause IKE SA/SHOULD = NOT be too long to avoid causing the IKE SA/

 

s/delete IKE SA with/delete the IKE SA with/

 

Section 10.1:

 

s/used by IKE responder/used by the IKE responder/

 

Section 10.2:

 

s/called Puzzle Solution/called the Puzzle Solution/=

 

--_000_DM2PR09MB0365FB3FEEA870743DDFDD21F00F0DM2PR09MB0365namp_-- From nobody Mon Nov 30 21:39:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3801B393C for ; Mon, 30 Nov 2015 21:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhDXnev-OVEW for ; Mon, 30 Nov 2015 21:39:48 -0800 (PST) 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 ED31C1B3937 for ; Mon, 30 Nov 2015 21:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1334; q=dns/txt; s=iport; t=1448948383; x=1450157983; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HTmMIkmJyvMgsryeZcPcQpF7g8+QmIP5KWPzK36/lco=; b=BvowUlqyjJ3txLwKSl5rko4KMF3gA2e0jL1SW5ki4IyftX2Hp3qpGTiX rOxPaArXGtOejcElI0STAUzpvkCX37FUlr9GpCYqds5vOes6hSsFcdXdU ur2k9COCWHWVNg9bSMiH2GK37ZmwzL+E/aD6eeIHawQXqA0Mm3oURYuL2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQBXMl1W/5JdJa1egzuBQga+LQENg?= =?us-ascii?q?WaGDwKBOzgUAQEBAQEBAYEKhDQBAQEDATpECwIBCBUhCQcyFBECBAESCIgeCLw?= =?us-ascii?q?YAQEBAQEBAQMBAQEBAQEBAQEahlSEfoQ0AYUEBZZXAY0wnGcBHwEBQoIRHYFWc?= =?us-ascii?q?oQnAR8jgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,367,1444694400"; d="scan'208";a="213427213" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2015 05:39:24 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tB15dOFn029611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 05:39:24 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.1104.5; Tue, 1 Dec 2015 00:39:23 -0500 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.1104.000; Tue, 1 Dec 2015 00:39:23 -0500 From: "Scott Fluhrer (sfluhrer)" To: Michael Richardson , IPsecme WG Thread-Topic: [IPsec] certificate lifetimes vs SA lifetimes Thread-Index: AQHRKuh14oHyD5WvuUakq/HEzG4h5J61lbxg Date: Tue, 1 Dec 2015 05:39:23 +0000 Message-ID: References: <22069.1448830591@sandelman.ca> In-Reply-To: <22069.1448830591@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.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 05:39:49 -0000 > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael > Richardson >=20 > It is my belief/memory that IKEv2 implementations should NOT limit SA > (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifeti= me. >=20 > Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. > Yet, I'm sure that this was consensus at some point. Maybe I've mis- > remembered? > What document did I miss? It's listed as a requirement in 4301; section 4.4.2.1, Data Items in the SA= D, which is the obvious place one should look for requirements on how IPSec= /IKE interacts with PKI. See the bullet point 'Lifetime of this SA': "If time is employed [as a limit on the lifetime of theSA], and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the Certificate Revocation Lists (CRLs) used in the IKE exchange for the SA." Hmmm, the above implies that if the SA has a negotiated lifetime of a milli= on years, then it is limited to the expiration of the certificate (if one w= as used), but if it has a technically unlimited lifetime (as far as time is= concerned), then it is not. I'm not sure what's the reasoning behind that= .