From nobody Wed Apr 1 04:26: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 EC8221A1B2D for ; Wed, 1 Apr 2015 04:26:08 -0700 (PDT) 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 lZBGOrOHdwEZ for ; Wed, 1 Apr 2015 04:26:07 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 1CF171A1B3F for ; Wed, 1 Apr 2015 04:26:06 -0700 (PDT) Received: by wgdm6 with SMTP id m6so49728762wgd.2 for ; Wed, 01 Apr 2015 04:26:04 -0700 (PDT) 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=uhwZzLw9ES1VTfUGdDTZzoeK7QO2Zb6zi/DSVNQ2fEY=; b=CyLg+YnAyVMSSm4EG9RgRVSqIbBGv2/KMBYBHiv6UkizOqWVfMRUPEg+qxbt6krFD/ nh42qswKKzMoR8x9uhcenwUK7syGp/JmonHIc/xvnZT/AUvUasRefy4+9A7p9Qt1yrRz iJoyQatF/T4fqNBnNZmHxuVK5zYaUSJkwnCwnBoQaJxS8tQPrOX1ejV9LeAAHFoWM964 yQiBLUzU17PXJAo0VjWIwnjloapYRxQKn9tU25AQ1Tw6beLNqh7kgJEV/G22MiPHR/s1 LNyt/+vpQ6i+82xsvhxQTaz+ohW11vesEQXNHc3+UUJMGWA6w15mxomh4MpFtdiOupUs nQow== X-Received: by 10.180.14.135 with SMTP id p7mr6304518wic.8.1427887564801; Wed, 01 Apr 2015 04:26:04 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id dj5sm2244391wjb.28.2015.04.01.04.26.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 04:26:03 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_095AA162-FCD9-4D08-B2F7-7D9AF88D8AC1" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Wed, 1 Apr 2015 14:26:02 +0300 References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> To: IETF IPsec In-Reply-To: X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-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: Wed, 01 Apr 2015 11:26:09 -0000 --Apple-Mail=_095AA162-FCD9-4D08-B2F7-7D9AF88D8AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK, so this thread kind of got side-tracked about the name of the = algorithm. I think ENCR_CHACHA20_POLY1305 works for everybody. What about early code point assignment? Thanks Yoav > On Mar 31, 2015, at 12:15 PM, Yoav Nir wrote: >=20 > One more thing. >=20 > I would like to request early code point assignment for = ESP_ChaCha20-Poly1305. >=20 > I know that it is the goal of the chairs to bring this to LC sooner = rather than later, but I would like to get started on implementation = sooner rather than later, and the IETF process takes three months at = best, and six months in the more common case. >=20 > Thanks >=20 > Yoav --Apple-Mail=_095AA162-FCD9-4D08-B2F7-7D9AF88D8AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii OK, so this thread kind of = got side-tracked about the name of the algorithm.  I = think ENCR_CHACHA20_POLY1305 works for everybody.

What about early code point assignment?

Thanks

Yoav

On = Mar 31, 2015, at 12:15 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

One more = thing.

I would like = to request early code point assignment for ESP_ChaCha20-Poly1305.

I know that it is the goal of the = chairs to bring this to LC sooner rather than later, but I would like to = get started on implementation sooner rather than later, and the IETF = process takes three months at best, and six months in the more common = case.

Thanks

Yoav

= --Apple-Mail=_095AA162-FCD9-4D08-B2F7-7D9AF88D8AC1-- From nobody Wed Apr 1 05:37: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 CEF171A896D for ; Wed, 1 Apr 2015 05:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611] 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 4zufAeu3DiEq for ; Wed, 1 Apr 2015 05:37:48 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [IPv6:2001:620:130:a080::46]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264EF1A88D0 for ; Wed, 1 Apr 2015 05:37:48 -0700 (PDT) Received: from [192.168.1.118] (143.204.173.83.static.wline.lns.sme.cust.swisscom.ch [83.173.204.143]) by mail.strongswan.org (Postfix) with ESMTPSA id 45B5A401DA for ; Wed, 1 Apr 2015 14:39:03 +0200 (CEST) Message-ID: <1427891865.3514.16.camel@martin> From: Martin Willi To: ipsec@ietf.org Date: Wed, 01 Apr 2015 14:37:45 +0200 In-Reply-To: <20150331105545.775.28233.idtracker@ietfa.amsl.com> References: <20150331105545.775.28233.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] ChaCha20/Poly1305 padding (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-01.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: Wed, 01 Apr 2015 12:37:53 -0000 Hi, In Section 2, draft-ietf-ipsecme-chacha20-poly1305-01 has the following text: > o Finally, the Poly1305 function is run on the data to be > authenticated, which is, as specified in section 2.7 of > [chacha_poly] a concatenation of the following in the below order: > > * The Authenticated Additional Data (AAD) - see Section 2.1. > * The AAD length in bytes as a 32-bit network order quantity. > * The ciphertext > * The length of the ciphertext as a 32-bit network order > quantity. First, I assume [chacha_poly] should be updated to draft-irtf-cfrg-chacha20-poly1305, where section 2.7 is now 2.8? draft-irtf-cfrg-chacha20-poly1305-10 2.8 defines AEAD construction for Poly1305 with padding and a final block with two 64-bit little endian length fields; in contrary to what is defined here. The GCM-like padding is certainly preferable, as it allows implementations to run four Poly1305 iterations on each ChaCha20 block. This is not only simpler, but allows parallel ChaCha20/Poly1305 processing without operating on partial blocks. Kind regards Martin From nobody Wed Apr 1 06:40: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 C317B1A9105 for ; Wed, 1 Apr 2015 06:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjdDDBa38-h2 for ; Wed, 1 Apr 2015 06:40:41 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227291A9121 for ; Wed, 1 Apr 2015 06:40:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lH7vL3zcbz5c; Wed, 1 Apr 2015 15:40:30 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=XY5CuYz3 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 IMDPUczRjKQV; Wed, 1 Apr 2015 15:40:29 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 1 Apr 2015 15:40:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 70E58803E0; Wed, 1 Apr 2015 09:40:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427895628; bh=HRrF1Tr9vdDC4ZSu7wt7SqL5Dbll0sMPgsvJZem7Ozo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XY5CuYz3RgoLUPzW3O0GNS8eHNys0AccoBlpczoaonDEAntW1YGRPLqHGSQk9ots5 IgEJzoK/9uWNFzS/s3Vq9sS98NSSwdJygSe+1PcRagiD+nVLfQErLIOMf4rrfa6LKe Iu7v5NTVwEJLXY6BR8L3I0bO+Zt7L87alpzae7Yg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t31DeSA0020150; Wed, 1 Apr 2015 09:40:28 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 1 Apr 2015 09:40:28 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-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: Wed, 01 Apr 2015 13:40:42 -0000 On Wed, 1 Apr 2015, Yoav Nir wrote: > OK, so this thread kind of got side-tracked about the name of the algorithm.  I think ENCR_CHACHA20_POLY1305 works for everybody. > What about early code point assignment? Just to confirm, yes please. As I said before, let's not have another twofish/serpent private use number in common use. Paul From nobody Wed Apr 1 07:50: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 90E391A1A67 for ; Wed, 1 Apr 2015 07:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6HdWf5zYu_Qy for ; Wed, 1 Apr 2015 07:50:24 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 A82071ACCF4 for ; Wed, 1 Apr 2015 07:50:13 -0700 (PDT) Received: by widdi4 with SMTP id di4so47838479wid.0 for ; Wed, 01 Apr 2015 07:50:12 -0700 (PDT) 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=0c2UTqgyeY9SPERnOGwOuTvs20MxG6TswEwZryHNwbk=; b=Ms6Q9seXX5jZkb9sL8gRVGxOdHBsjuR20adXlFfQE6Ljq54VdVA5f86Kc/zliDFgmw zaGkCYshJOH1Daa6az7tiBYKyL5lapOOsf67GkhuXDdlPUSAcrJp/F/hs69DAQ8sN/yj hYuks8JgcSOeFAC2Ckw+/7bgZ0WG3z41eOfYKjkae7O5LdVwBR6AFICOhAc5pME6NF2W MfAdbLmkKu6oEy0mM9eBbka7W4CoozkHAERnmfLiTxTWAjiyEo0KdLAE9DBCyNoW5CN+ re18/Dc7HMc7ZIb5SHQizAtNusjnan9H62m9O0bmHv0g9rL2HSkX2vslPPabMynkxDdU V7jg== X-Received: by 10.181.12.14 with SMTP id em14mr1261470wid.55.1427899812245; Wed, 01 Apr 2015 07:50:12 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([176.12.139.254]) by mx.google.com with ESMTPSA id r14sm3500747wiv.13.2015.04.01.07.50.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 07:50:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <1427891865.3514.16.camel@martin> Date: Wed, 1 Apr 2015 17:50:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6A224480-AA4E-4186-9303-A93EE5CC6270@gmail.com> References: <20150331105545.775.28233.idtracker@ietfa.amsl.com> <1427891865.3514.16.camel@martin> To: Martin Willi X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] ChaCha20/Poly1305 padding (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-01.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: Wed, 01 Apr 2015 14:50:32 -0000 > On Apr 1, 2015, at 3:37 PM, Martin Willi = wrote: >=20 > Hi, >=20 > In Section 2, draft-ietf-ipsecme-chacha20-poly1305-01 has the = following > text:=20 >=20 >> o Finally, the Poly1305 function is run on the data to be >> authenticated, which is, as specified in section 2.7 of >> [chacha_poly] a concatenation of the following in the below = order: >>=20 >> * The Authenticated Additional Data (AAD) - see Section 2.1. >> * The AAD length in bytes as a 32-bit network order quantity. >> * The ciphertext >> * The length of the ciphertext as a 32-bit network order >> quantity. >=20 > First, I assume [chacha_poly] should be updated to > draft-irtf-cfrg-chacha20-poly1305, where section 2.7 is now 2.8? Right you are. Thanks. I=E2=80=99ve fixed it in my local storage. = draft-irtf-cfrg-chacha20-poly1305 is now in the RFC editor=E2=80=99s = queue. In a few weeks it will be published as an RFC, and then I will = update the reference. > draft-irtf-cfrg-chacha20-poly1305-10 2.8 defines AEAD construction for > Poly1305 with padding and a final block with two 64-bit little endian > length fields; in contrary to what is defined here. Oh, right. That justifies a new revision immediately. The question is = whether I should just delete the bullet points, leaving only the = reference to the CFRG document, or fix it here. > The GCM-like padding is certainly preferable, as it allows > implementations to run four Poly1305 iterations on each ChaCha20 = block. > This is not only simpler, but allows parallel ChaCha20/Poly1305 > processing without operating on partial blocks. I doubt it would produce a measurable difference in performance, but I = agree. Yoav From nobody Wed Apr 1 09:24:43 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 A4B951ACEB7 for ; Wed, 1 Apr 2015 09:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 T_A2aWn_33Ao for ; Wed, 1 Apr 2015 09:24:40 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::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 599731A8958 for ; Wed, 1 Apr 2015 09:24:40 -0700 (PDT) Received: by pdbni2 with SMTP id ni2so59848110pdb.1 for ; Wed, 01 Apr 2015 09:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FiMDTycyHsqI5el7ftaOZ8W5xJ9OvVvHcE3ZcxrTL+o=; b=YpnG71n72ueEnDM0tL0mdmbmy3TDHt6uQlyI8pXNlkqK2UmfZYBvrSH0TwrXpF1W0g oo6JmonWnU4w9+tPppQqgo7ByaXj5oucqIOpKyVC8vDgX9w0AuKjoivMmLU5lgI+TCxL 6O+reTS4+CP/cyHCNE9DTsvvWtxayvwKb2/jO5OLZIR6AY/rFAu1oDyJMdYdjeZ0IXlD dx7PyjOQFg8HciuqLo8X0Ny7ST1XWAOJKmfA/4Ltd7HPhmgdUUhj8kruqUQRAdHd5n52 x9GywFIZszmT+J4E/4cRxuvW2XcDfuF1aEX2cwSm4XvJRJwEkllWBtMF9wp4rYvJOO9x i4dQ== X-Received: by 10.68.246.38 with SMTP id xt6mr78463935pbc.20.1427905480074; Wed, 01 Apr 2015 09:24:40 -0700 (PDT) Received: from [192.168.3.250] (50-203-213-210-static.hfc.comcastbusiness.net. [50.203.213.210]) by mx.google.com with ESMTPSA id k9sm2576361pbq.46.2015.04.01.09.24.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 09:24:38 -0700 (PDT) Message-ID: <551C1BC5.102@gmail.com> Date: Wed, 01 Apr 2015 09:24:37 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoav Nir , IETF IPsec References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Early code point assignment 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, 01 Apr 2015 16:24:41 -0000 Not while the latest revision still has two TBDs, while we're still debating two interop-critical issues (padding, salt) and another major security issue (IV). I don't want private use numbers any more than PaulW, but I also don't want errata like we had for TLS EtM. We can iron out these issues within a week or two and then I'd be all in favor of a code point assignment. Thanks, Yaron On 04/01/2015 04:26 AM, Yoav Nir wrote: > OK, so this thread kind of got side-tracked about the name of the > algorithm. I think ENCR_CHACHA20_POLY1305 works for everybody. > > What about early code point assignment? > > Thanks > > Yoav > >> On Mar 31, 2015, at 12:15 PM, Yoav Nir > > wrote: >> >> One more thing. >> >> I would like to request early code point assignment for >> ESP_ChaCha20-Poly1305. >> >> I know that it is the goal of the chairs to bring this to LC sooner >> rather than later, but I would like to get started on implementation >> sooner rather than later, and the IETF process takes three months at >> best, and six months in the more common case. >> >> Thanks >> >> Yoav > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Wed Apr 1 12:11: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 2F3471A87EF; Wed, 1 Apr 2015 12:11:18 -0700 (PDT) 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 4PMi9PqzKSKe; Wed, 1 Apr 2015 12:11:16 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 7B1091A8762; Wed, 1 Apr 2015 12:11:15 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so43664805lbb.3; Wed, 01 Apr 2015 12:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckG04zADOdDm6+B1sFk3wFi7+k7P+jjhX6MFLds+iQQ=; b=lv9E3IkFmZVp+IS3ll/hID7j5aJ5ZP5/AMk2c7+xUAljI8vvt34D5JsJ5DUnCZT32k 9RaKg30Au/svyI/MUUQ0FCDetTgaZkAOyueyfmDbKLN2/MK2JJ2AjHgI+h0LVrO7gR26 GlD0f1nDRaSWoB4E5IaR+fkVQaAxxD2TAXbXeE3ukqRAdNhqCRzyGxeOeurTX0Ne6dW0 OXsXZvZgerO5xea+WS3Z8CAz1yt2eSFe9V/xbyQLZSplZxCkVij3UoSAeZHweW2mtNFe aZ7Z+OAnBeHCbx+WiIwF/M//tmQMSjVDdMDPX28eJT90iY28E5FBqd11OC76S+8hicti X50A== MIME-Version: 1.0 X-Received: by 10.152.179.68 with SMTP id de4mr37333691lac.65.1427915474011; Wed, 01 Apr 2015 12:11:14 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 1 Apr 2015 12:11:13 -0700 (PDT) In-Reply-To: References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> Date: Wed, 1 Apr 2015 15:11:13 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11342ef2990adc0512ae7a89 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , draft-ietf-ipsecme-ikev2-null-auth@ietf.org, Tero Kivinen Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Wed, 01 Apr 2015 19:11:18 -0000 --001a11342ef2990adc0512ae7a89 Content-Type: text/plain; charset=UTF-8 Hi Paul, On Mon, Mar 30, 2015 at 8:51 PM, Paul Hoffman wrote: > On Mar 30, 2015, at 1:56 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > Thanks for making most of the suggested changes to the draft. I see > nothing happened in section 2.4 with the 'updates' text. Since this > requires changes to the referenced draft, it's easier to just state what is > being updated in the previous RFC with this draft. Could we work on that > change and have it ready soon? I'd rather do this before IETF last call or > in IESG review as I think it pretty clearly should be done. > > My interpretation from the WG discussion was that there was consensus that > this document doesn't need to be marked as "updates RFC 4301". I updated > the shepherd report to indicate that the WG defers to the IESG on judgement > about this. > In looking back at this, the email lists, and talking to a couple of fellow ADs, I think it's important to tweak some text as it will get held up otherwise. This text was not present in RFC4322. The last sentence of this paragraph is the mail issue: When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL Authentication, there is no ID at all. The processing of PAD described in Section 4.4.3.4 of [RFC4301] must be updated. The only change that would be required here is to reword that last sentence and mark the draft appropriately so it "updates" 4301 for this case. New text could be something like: When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL Authentication, there is no ID at all. The processing of PAD described in Section 4.4.3.4 of [RFC4301] is updated for NULL Authentication. Then you can add a few sentences specific to what is updated and where that text goes in 4.4.3.4. This keeps the update very specific and we see this in drafts pretty regularly when just a bit of text is needed. The other sentence that is problematic in this section is: To add support for ID_NULL, it needs to be included into the list of ID types, specified in Section 4.4.3.1 of [RFC4301]. As such, Section 4.4.3.1 of [RFC4301] is updated as follows: Old: New: You could simply then add a sentence that provides the text to update the list of ID types, showing where it is added in that section with surrounding text in the old/new. The way it is written now leaves you wondering if that list will get updated at some point in the future. One AD wasn't too fused and the other agreed (provided an alternative) Given the wording in 2.4, this draft most certainly needs to update RFC 4301. If it does not update 4301, it needs to subsume the necessary text from 4301 to make this spec standalone. From a quick read of 4301, I think section 2.4 would be augmented with 3-4 blocks indicating what text in 4301 is updated. I'm fine with the alternative as well. Does this draft update RFC4322 at all? I do see that it wasn't referenced, so maybe not, but figured I would check to be safe. Thanks. > > The next telechat is April 9th and this won't make it on it, so there is > time to get this update ready without holding up the draft. > > Unless you want us to make more changes to the draft, you might as well > put this into IETF Last Call now, even though it will miss the next > telechat. > > --Paul Hoffman -- Best regards, Kathleen --001a11342ef2990adc0512ae7a89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

On Mon, Mar 30, 2015 at 8:51 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
On Mar 30= , 2015, at 1:56 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

> Thanks for making most of the suggested changes to the draft.=C2=A0 I = see nothing happened in section 2.4 with the 'updates' text.=C2=A0 = Since this requires changes to the referenced draft, it's easier to jus= t state what is being updated in the previous RFC with this draft.=C2=A0 Co= uld we work on that change and have it ready soon?=C2=A0 I'd rather do = this before IETF last call or in IESG review as I think it pretty clearly s= hould be done.

My interpretation from the WG discussion was that there was consensu= s that this document doesn't need to be marked as "updates RFC 430= 1". I updated the shepherd report to indicate that the WG defers to th= e IESG on judgement about this.

In look= ing back at this, the email lists, and talking to a couple of fellow ADs, I= think it's important to tweak some text as it will get held up otherwi= se.=C2=A0 This text was not present in RFC4322.

Th= e last sentence of this paragraph is the mail issue:
=C2=A0    When using NULL Authentication, the peer identity is not<=
/pre>
   authenticated and cannot be trusted.  If ID_=
NULL is used with NULL

      Authentication, there is no ID at all.  The p=
rocessing of PAD
   described in Section 4.4.3.4 of [RFC4301] must be updated.

The only change that would be required here is to =
reword that last sentence and mark the draft appropriately so it "upda=
tes" 4301 for this case. New text could be something like:

=C2=A0    When using NULL Authentication, the peer identity is not
   authenticated and cannot be trusted.  =
If ID_NULL is used with NULL

      Authentication, there is no ID at all.  The p=
rocessing of PAD
   described in Section 4.4.3.4 of [RFC4301] is updated for NULL Authentica=
tion.

Then you can add a few sentence=
s specific to what is updated and where that text goes in 4.4.3.4. This kee=
ps the update very specific and we see this in drafts pretty regularly when=
 just a bit of text is needed.

The other senten=
ce that is problematic in this section is:
To add suppor=
t for ID_NULL, it needs to be included into the
   list of ID types, specified in Section 4.4.3.1 of [RFC4301].

As such, Sect= ion 4.4.3.1 of [RFC4301] is updated as follows:

Old:

New:


You could simply then add=
 a sentence that provides the text to update the list of ID types, showing =
where it is added in that section with surrounding text in the old/new.  Th=
e way it is written now leaves you wondering if that list will get updated =
at some point in the future.

One AD wasn't too fused and the other agreed =
(provided an alternative)
=C2=A0 =C2=A0 =C2=A0Given the wording in 2.4, this draft most certainly=
 needs to update
RFC 4301.=C2=A0=
 If it does not update 4301, it needs to subsume the necessary
text from 4301 to make this spec standalone.=
=C2=A0 From a quick read of 4301,
text in 4301 is updated.
I=
'm fine with the alternative as well.


Does this draft update RFC4322 at a=
ll?  I do see that it wasn't referenced, so maybe not, but figured I wo=
uld check to be safe.

Thanks.


> The next telechat is April 9th and this won't make it on it, so th= ere is time to get this update ready without holding up the draft.

Unless you want us to make more changes to the draft, you might as w= ell put this into IETF Last Call now, even though it will miss the next tel= echat.

--Paul Hoffman


<= br>
--

Be= st regards,
Kathleen
--001a11342ef2990adc0512ae7a89-- From nobody Wed Apr 1 16:44: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 9BAC01ACD75 for ; Wed, 1 Apr 2015 16:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 MTfBi3OXoulC for ; Wed, 1 Apr 2015 16:44:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 672331ACD70 for ; Wed, 1 Apr 2015 16:44:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t31NiGrm002090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 02:44:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t31NiFmx006877; Thu, 2 Apr 2015 02:44:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21788.33487.758520.39953@fireball.kivinen.iki.fi> Date: Thu, 2 Apr 2015 02:44:15 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: IETF IPsec , Yoav Nir Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-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: Wed, 01 Apr 2015 23:44:24 -0000 Paul Wouters writes: > On Wed, 1 Apr 2015, Yoav Nir wrote: >=20 > > OK, so this thread kind of got side-tracked about the name of the > > algorithm. =A0I think=A0ENCR=5FCHACHA20=5FPOLY1305 works for everyb= ody.=20 > > What about early code point assignment=3F >=20 > Just to confirm, yes please. As I said before, let's not have another= > twofish/serpent private use number in common use. While we are still discussing whether having 32-bit or 64-bit length fields in the mode, I think it is too early to allocate number for chacha20 (see last comments on the list). At least I want to make sure the draft is stable enough so that there will NOT be any bits on the wire changes after we allocate the real number. Before that it is better to use private numbers. --=20 kivinen@iki.fi From nobody Wed Apr 1 18:57: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 5DCFD1A92E6; Wed, 1 Apr 2015 18:57:36 -0700 (PDT) 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 h_PtjzQG6lwP; Wed, 1 Apr 2015 18:57:33 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010: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 36F901A07BE; Wed, 1 Apr 2015 18:57:33 -0700 (PDT) Received: by lagg8 with SMTP id g8so50046404lag.1; Wed, 01 Apr 2015 18:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dB6ysqBbGH9+HshzIFoasnn5dhFslkvP9kGQT6iyUeA=; b=FcumR7kLlI0eWONYeHqU90xepeX4Y686vRdN0BdNqCmd+NaR3zAFMnMLoMWx+NjjU5 V191SnrldSQY1YTuwzidLqlZe5R/sap7J93leaZjx4o6po5uzR65RrQwqmAMttri4SKX AjbE3GYBdl89dKwgw2vazihZfGdyUEDLKVsUQoQbKv1kNtxAD8QnvN8vvStqI3YiiXlP 1+yZ5zdFrSolSiHQ4KOBLtryAU0660/FRbHW62bQvgJfiUMsee0w9+FXXXOkAtb015OV Je5dCKMWxGePEEP7L2KQUFP2DT09rf5gmwxqzMTJutp2uVA9u7EwCqUEAs4isDU4V5rk iEVg== MIME-Version: 1.0 X-Received: by 10.112.218.5 with SMTP id pc5mr39507615lbc.32.1427939851541; Wed, 01 Apr 2015 18:57:31 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Wed, 1 Apr 2015 18:57:31 -0700 (PDT) In-Reply-To: References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> Date: Wed, 1 Apr 2015 21:57:31 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c322f69ca4020512b42762 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , draft-ietf-ipsecme-ikev2-null-auth@ietf.org, Tero Kivinen Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Thu, 02 Apr 2015 01:57:36 -0000 --001a11c322f69ca4020512b42762 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I went back to the email thread as I wanted to look at the consensus and don't see it the way Paul does. Here is the end of the thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html It reads as confusion with the term updates and most being ok with going in either direction, Paul against and Yaron more in favor. Updates can update very specific text in a draft. Since this just applies in this special case, the updates text needs to be clearly worded to reflect that or you copy in all the text that applies from the other draft. I'm at a day long conference tomorrow and will be slow to respond. Thanks. On Wed, Apr 1, 2015 at 3:11 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Paul, > > On Mon, Mar 30, 2015 at 8:51 PM, Paul Hoffman > wrote: > >> On Mar 30, 2015, at 1:56 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> > Thanks for making most of the suggested changes to the draft. I see >> nothing happened in section 2.4 with the 'updates' text. Since this >> requires changes to the referenced draft, it's easier to just state what= is >> being updated in the previous RFC with this draft. Could we work on tha= t >> change and have it ready soon? I'd rather do this before IETF last call= or >> in IESG review as I think it pretty clearly should be done. >> >> My interpretation from the WG discussion was that there was consensus >> that this document doesn't need to be marked as "updates RFC 4301". I >> updated the shepherd report to indicate that the WG defers to the IESG o= n >> judgement about this. >> > > In looking back at this, the email lists, and talking to a couple of > fellow ADs, I think it's important to tweak some text as it will get held > up otherwise. This text was not present in RFC4322. > > The last sentence of this paragraph is the mail issue: > > When using NULL Authentication, the peer identity is not > > authenticated and cannot be trusted. If ID_NULL is used with NULL > > Authentication, there is no ID at all. The processing of PAD > described in Section 4.4.3.4 of [RFC4301] must be updated. > > > The only change that would be required here is to reword that last > sentence and mark the draft appropriately so it "updates" 4301 for this > case. New text could be something like: > > > When using NULL Authentication, the peer identity is not > > authenticated and cannot be trusted. If ID_NULL is used with NULL > > Authentication, there is no ID at all. The processing of PAD > described in Section 4.4.3.4 of [RFC4301] is updated for NULL Authenti= cation. > > > Then you can add a few sentences specific to what is updated and where > that text goes in 4.4.3.4. This keeps the update very specific and we see > this in drafts pretty regularly when just a bit of text is needed. > > The other sentence that is problematic in this section is: > > To add support for ID_NULL, it needs to be included into the > list of ID types, specified in Section 4.4.3.1 of [RFC4301]. > > > As such, Section 4.4.3.1 of [RFC4301] is updated as follows: > > > Old: > > > New: > > > > You could simply then add a sentence that provides the text to update the= list of ID types, showing where it is added in that section with surroundi= ng text in the old/new. The way it is written now leaves you wondering if = that list will get updated at some point in the future. > > > One AD wasn't too fused and the other agreed (provided an alternative) > > Given the wording in 2.4, this draft most certainly needs to update > RFC 4301. If it does not update 4301, it needs to subsume the necessary > text from 4301 to make this spec standalone. From a quick read of 4301, > I think section 2.4 would be augmented with 3-4 blocks indicating what > text in 4301 is updated. > > > I'm fine with the alternative as well. > > > > Does this draft update RFC4322 at all? I do see that it wasn't reference= d, so maybe not, but figured I would check to be safe. > > > Thanks. > > > >> > The next telechat is April 9th and this won't make it on it, so there >> is time to get this update ready without holding up the draft. >> >> Unless you want us to make more changes to the draft, you might as well >> put this into IETF Last Call now, even though it will miss the next >> telechat. >> >> --Paul Hoffman > > > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --001a11c322f69ca4020512b42762 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I went back to the email thread as I wanted to look at the= consensus and don't see it the way Paul does. =C2=A0
Here is the e= nd of the thread:

It reads as confusion = with the term updates and most being ok with going in either direction, Pau= l against and Yaron more in favor.

Updates can upd= ate very specific text in a draft.=C2=A0 Since this just applies in this sp= ecial case, the updates text needs to be clearly worded to reflect that or = you copy in all the text that applies from the other draft.

<= /div>
I'm at a day long conference tomorrow and will be slow to res= pond. =C2=A0

Thanks.

On Wed, Apr 1, 2015 at 3:11 PM, Kat= hleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hi Paul,
On M= on, Mar 30, 2015 at 8:51 PM, Paul Hoffman <paul.hoffman@vpnc.org&g= t; wrote:
On Mar 30, 2015, at 1:56 PM, Kat= hleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

> Thanks for making most of the suggested changes to the draft.=C2=A0 I = see nothing happened in section 2.4 with the 'updates' text.=C2=A0 = Since this requires changes to the referenced draft, it's easier to jus= t state what is being updated in the previous RFC with this draft.=C2=A0 Co= uld we work on that change and have it ready soon?=C2=A0 I'd rather do = this before IETF last call or in IESG review as I think it pretty clearly s= hould be done.

My interpretation from the WG discussion was that there was consensu= s that this document doesn't need to be marked as "updates RFC 430= 1". I updated the shepherd report to indicate that the WG defers to th= e IESG on judgement about this.

= In looking back at this, the email lists, and talking to a couple of fellow= ADs, I think it's important to tweak some text as it will get held up = otherwise.=C2=A0 This text was not present in RFC4322.

=
The last sentence of this paragraph is the mail issue:
=C2=A0    When using NULL Authentication, the peer identity is not
   authenticated and cannot be trusted.  I=
f ID_NULL is used with NULL

      Authentication, there is no ID at all.  The p=
rocessing of PAD
   described in Section 4.4.3.4 of [RFC4301] must be updated.

The only change that would be required here is to = reword that last sentence and mark the draft appropriately so it "upda= tes" 4301 for this case. New text could be something like:

=C2=A0    When using NULL Authentication, the peer identity is not
   authenticated and cannot be trusted.  =
If ID_NULL is used with NULL

      Authentication, there is no ID at all.  The p=
rocessing of PAD
   described in Section 4.4.3.4 of [RFC4301] is updated for NULL Authentica=
tion.

Then you can add a few sentence= s specific to what is updated and where that text goes in 4.4.3.4. This kee= ps the update very specific and we see this in drafts pretty regularly when= just a bit of text is needed.

The other senten=
ce that is problematic in this section is:
To add suppor=
t for ID_NULL, it needs to be included into the
   list of ID types, specified in Section 4.4.3.1 of [RFC4301].

As such, Sect= ion 4.4.3.1 of [RFC4301] is updated as follows:

Old:

New:


You could simply then add=
 a sentence that provides the text to update the list of ID types, showing =
where it is added in that section with surrounding text in the old/new.  Th=
e way it is written now leaves you wondering if that list will get updated =
at some point in the future.

One AD wasn't too fused and the other agreed =
(provided an alternative)
=C2=A0 =C2=A0 =C2=A0Given the wording in 2.4, this dra=
ft most certainly needs to update
text from 4301 to make this=
 spec standalone.=C2=A0 From a quick read of 4301,
I think section 2.4 would be augmented with 3-4 blocks i=
ndicating what
text in 4301 is u=
pdated.

I'm fine with the alternative as well.


Does this d= raft update RFC4322 at all? I do see that it wasn't referenced, so may= be not, but figured I would check to be safe.

Thanks.


> The next telechat is April 9th and this won't make it on it, so th= ere is time to get this update ready without holding up the draft.

Unless you want us to make more changes to the draft, you might as w= ell put this into IETF Last Call now, even though it will miss the next tel= echat.

--Paul Hoffman



--
=

Best regards,
Kathleen



--

Best regards,
Kath= leen
--001a11c322f69ca4020512b42762-- From nobody Wed Apr 1 19:10: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 5D2061A1B12; Wed, 1 Apr 2015 19:10:15 -0700 (PDT) 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 jIvFJoQu87fY; Wed, 1 Apr 2015 19:10:14 -0700 (PDT) Received: from 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 62DB51A1B00; Wed, 1 Apr 2015 19:10:14 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t322AAkc073381 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 19:10:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Wed, 1 Apr 2015 19:10:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , draft-ietf-ipsecme-ikev2-null-auth@ietf.org, Tero Kivinen Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Thu, 02 Apr 2015 02:10:15 -0000 On Apr 1, 2015, at 6:57 PM, Kathleen Moriarty = wrote: >=20 > I went back to the email thread as I wanted to look at the consensus = and don't see it the way Paul does. =20 > Here is the end of the thread: > http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html >=20 > It reads as confusion with the term updates and most being ok with = going in either direction, Paul against and Yaron more in favor. Yes, exactly. So, it sounds like you see the consensus (and confusion) = the way I do. > Updates can update very specific text in a draft. Since this just = applies in this special case, the updates text needs to be clearly = worded to reflect that or you copy in all the text that applies from the = other draft. Sounds fine. Who do you want to make that decision? --Paul Hoffman= From nobody Thu Apr 2 03:07:08 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 0430F1B2ADD; Thu, 2 Apr 2015 03:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 g8i7w1Wnyy0x; Thu, 2 Apr 2015 03:07:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 BAA851B2C22; Thu, 2 Apr 2015 03:07:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t32A6wwG019146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 13:06:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t32A6wmj018723; Thu, 2 Apr 2015 13:06:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21789.5313.838988.31783@fireball.kivinen.iki.fi> Date: Thu, 2 Apr 2015 13:06:57 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 40 min X-Total-Time: 44 min Archived-At: Cc: "ipsec@ietf.org" , Kathleen Moriarty , Valery Smyslov , draft-ietf-ipsecme-ikev2-null-auth@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Thu, 02 Apr 2015 10:07:07 -0000 Paul Hoffman writes: > > Updates can update very specific text in a draft. Since this just > > applies in this special case, the updates text needs to be clearly > > worded to reflect that or you copy in all the text that applies > > from the other draft. I do not think the ikev2-null-auth updates the RFC4301. I does extend it, but it does not really change anything that is already there. In the similar way the RFC4739 (multiple authenticaiton exchanges in IKEv2) adds multiple authentication exchanges in IKEv2, and while implementing that rfc, you need to modify your code that handles the configuration data and processing rules for the authentication data, i.e. exactly this text we are talking in the RFC4301. The RFC5998 (EAP only authentication in IKEv2) does the same thing, i.e. it now allows the IKEv2 to be authenticated using only EAP. This of course means that the PAD and SPD processing in the RFC4301 needs to be extended in such way that you can configure that feature for certain end points. Neither one of those updates RFC4301, but both of them will extended the processing rules mentioned in the RFC4301. As those changes in the RFC4301 are obvious, neither one of them actually spells them out at all. The IKEv2-null-auth draft does the same thing, i.e. it just extends the processing rules of the RFC4301. Implementation which do not support that draft and does the RFC4301 processing does not need to be changed at all. I.e. my understanding is that when you change something that also causes changes that old implementations need to consider, even when they do not add that new feature, then you mark document as Updates RFC XXXX. For example the RFC 7383 (IKEv2 fragmentation) does NOT update IKEv2, because it does not require old implementations ont supporting the fragmentation to be changed at all. The old implementations will be able to interoperate with implementations doing fragmentation without any problem. RFC 6989 (Additional Diffie-Hellman tests for IKEv2) do update IKEv2 (RFC5996) as they add tests that needs to be taken care of also for old implementations implementing RFC5996. I.e. everybody implementation RFC5996 should also read the RFC6989. The reason IKEv2-null-auth mentions RFC4301 at all (while those two other authentication related drafts do not) is that when implementor adds support for null auth they need to make sure that they do those changes properly, and there are some security issues that implementor might otherwise miss if they are not pointed out. Anyways old implementations implementing RFC4301 does not need to read or care about the IKEv2-null-auth at all, unless they plan to implement that draft. If we mark IKEv2-null-auth as updating RFC4301 that would in my understanding mean that old implementations supporting RFC4301 would need to go and verify that they do correct things mentioned in the IKEv2-null-auth, as it supposedly changed something that is important for them. In the end there is nothing that implementors of RFC4301 need to do. > Sounds fine. Who do you want to make that decision? I would like to keep the "Updates" marking to really mean that "this RFC has something that everybody using this RFC should read, and make sure their implementations are updated to what is said in this RFC". Something that just "Extends" some RFC should not be marked as "Updates", as old implementations do not need to care about RFCs that add new features to old protocol, as long as the original RFC already has enough text that will make sure that new features can be added without breaking interoperability. RFC2223 says: Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. Which takes very document specific way of interpreting the Updates, not protocol specific way, and I think lately we have used it more in the protocol specific way, i.e. you cannot implement any of the IKEv2 extensions without reading the actual IKEv2 RFC (which is why IKEv2 is normative reference in there). We could of course remove the text about RFC4301 section 4.4.3.4 in the null-auth and just explain things without using the RFC 4301 references, but would that be better or not, I do not know. Something like: ---------------------------------------------------------------------- 2.4. Interaction with Peer Authorization Database (PAD) Section 4.4.3 of [RFC4301] defines the Peer Authorization Database (PAD), which provides the link between Security Policy Database (SPD) and the IKEv2. The PAD contains an ordered list of records, with peers' identities along with corresponding authentication data and Child SA authorization data. When the IKE SA is being established the PAD is consulted to determine how the peer should be authenticated and what Child SAs it is authorized to create. When using NULL Authentication, the peer identity is not authenticated and cannot be trusted. If ID_NULL is used with NULL Authentication, there is no ID at all. The NULL authentication does not have any authentication data, and the as ID_NULL does not have any content, the policy rules for matching it consists only of whether this type is used, i.e. no actual ID matching is done, as ID_NULL contains no identity data. When using the NULL authentication method the implementation MUST make sure that it does not mix authenticated and not-authenticated SPD rules, i.e. it needs to keep them separately, for example by adding flag in SPD to tell whether NULL authentication can be used or not for the entry. I.e. each SPD entry needs to be augmented to have a flag specifying whether it can be used with NULL authentication or not, and only those rules that explictly have that flag turned on can be used with unauthenticated connections. -- kivinen@iki.fi From nobody Thu Apr 2 03:41:22 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 9900B1B2C47 for ; Thu, 2 Apr 2015 03:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZBOti9x_1NxA for ; Thu, 2 Apr 2015 03:41:18 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 969591B2C3F for ; Thu, 2 Apr 2015 03:41:18 -0700 (PDT) Received: by wgra20 with SMTP id a20so80918493wgr.3 for ; Thu, 02 Apr 2015 03:41:17 -0700 (PDT) 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=htvZYC374pLifmtfGPP6CpxuGuPOzxKe99sOyqY1RQw=; b=RzkCvd6I/7+wUz4E5f+lzA9YboVBMTQsNXdKG/FA0Ad3B2Mu8NlUCcnW540FRpMstT BTytyC7CCyuk4m2o+/E0RNRl+7Ec2WCgOO4f1uaTv5XdNeC6JLdS9epIi/yF1vbXVQp9 zNPMP8Rl9bL8LINtwMPPVj61xpQXQHu37vIA+Ka8aXkZkIevJmgO7LqvwJ12ax4WXwkz uOfqX1tiyB0xLVOIj+IUvYO3JX5wgROaabQu7tXMMd7B3lvihRjjtWi59PSsgi8K3o28 gP4JNTfUb0Axj4kdfHra34EqwsCU1bOgGfshp1yizdPB++IGN7l7K4C5zWTxHRtmFfij 5fMA== X-Received: by 10.180.221.108 with SMTP id qd12mr23563114wic.41.1427971277325; Thu, 02 Apr 2015 03:41:17 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ei8sm29439342wib.10.2015.04.02.03.41.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 03:41:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <21786.31700.388695.942729@fireball.kivinen.iki.fi> Date: Thu, 2 Apr 2015 13:41:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> <21786.31700.388695.942729@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 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, 02 Apr 2015 10:41:21 -0000 > On Mar 31, 2015, at 1:49 PM, Tero Kivinen wrote: >=20 > Yoav Nir writes: >> First is the nonce/IV question: In the current draft, there is a >> 64-bit IV with guidance not to repeat them (so use a counter or >> LFSR). The function itself accepts a 96-bit input nonce, so the >> nonce is constructed from the 64-bit IV and 32 zero bits. The reason >> for doing this is so the algorithm could be used in a multi-sender >> case such as GDOI, where the 32-bit zero can be replaced by a sender >> ID. Alternatively, we could generate a 32-bit salt value from the >> key material, but I don=E2=80=99t see a reason why we=E2=80=99d want = that. >=20 > Reserving that 32-bits as sender-ID is fine... >=20 >> Another thing we could do is what some people are advocating for >> TLS: Since a counter is a fine IV (no need for secrecy), we don=E2=80=99= t >> need a 64-bit IV that has the exact same value as the replay >> counter. We might as well save 8 bytes per packet and just feed the >> replay counter to the function. The argument against this is that >> some crypto modules may have the API set up in such a way that the >> IVs are generated within the module and could be something other >> than a counter (like an LFSR). The proposal will break such APIs. >=20 > As Kent explained in the meeting, if you move the IV generation out > from the crypto operation, then that also moves the FIPS boundary, > i.e. if the uniqueness of the IV generation (counter) is inside the > IPsec module, not in the ChaCha20 module, then you need to FIPS > certify whole thing. >=20 > On the other hand with IPsec I think you mostly need to FIPS certify > quite a lot of stuff anyways... >=20 > On the other hand, I think it would be possible to do things other way > around, i.e. make cipher to internally generate IV, but define that IV > MUST be running counter starting from 0, and use that counter as > sequence number in the ESP and compress sequence number out from the > packet. I.e. we would still have IV (coming form inside the crypto > boundary), but we compress the sequence number away, as it would > always be the same as IV... >=20 > Currently we cannot do that, as we do not define how the IVs are > generated, thus the IPsec part cannot know for sure that IVs are > generated in such way. >=20 > On the other hand if we define this cipher in such way that IV MUST be > generated such way, then we could make sequence number compression > option in the future, which would compress sequence number away from > the actual packet... I.e. gain the same effect, but not compressing > the IV, but compressing the sequence number... >=20 > This would save 32-bits from the packet, as only 32-bits of the > sequence number is transmitted, not the full 64-bits, but that would > still be something, and if even more IV compression is needed, there > would be ways to only transmit smaller part of the IV and then > reconstruct it before decryption and verification. >=20 > These compression extensions could happen after ESP encryption and > before ESP decryption, so the actual ESP packets seen by the engine > would be exactly same, only difference would be that they would need > to maintain strict requirement that SEQ matches IV=E2=80=A6 Such a compression extension would work fine for both ChaCha20-Poly1305 = and AES-GCM at least. Probably the other currently-defined AEAD mode. = OK, for now I=E2=80=99ll leave the TBD in, but I won=E2=80=99t change = the text. >> Second issue is about UI advice. Some implementations (yes, mine is >> included) allow the user to configure encryption algorithm, MAC >> algorithm, and D-H group. There is no setting for PRF since such UIs >> date back to IKEv1. The PRF is usually just taken from the setting >> for MAC algorithm. This works fine as long as all supported MAC >> algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same >> issue, but RFC 5282 makes no mention of this issue. I=E2=80=99m = wondering if >> we should recommend to pair this algorithm in IKE with >> PRF_HMAC_SHA2_256.=20 >=20 > There is no need in IKEv2 to tie the PRF to other algorithms, so I see > no reason to do so in this draft. >=20 > On the other hand the other draft making the UI suite for this will of > course need to select suitable PRF, but that draft might want to wait > for new EC curves, so we could have complete DJB suite... >=20 > Btw, in the draft introduction you have text which says: >=20 > weakness in AES, VPN users will be in an unenviable position. With > the only other widely supported cipher being the much slower 3DES, = it > is not feasible to re-configure IPsec installations to use 3DES. > [standby-cipher] describes this issue and the need for a standby > cipher in greater detail. >=20 > I do not think the problem with 3DES is the speed, I think the bigger > problem is the way too short block length of it. As RFC7321 says: >=20 > The Triple Data Encryption Standard (TDES) is obsolete because of = its > small block size; as with all 64-bit block ciphers, it SHOULD NOT be > used to encrypt more than one gigabyte of data with a single key > [M13]. Its key size is smaller than that of the Advanced Encryption > Standard (AES), while at the same time its performance and = efficiency > are worse. Thus, its use in new implementations is discouraged. >=20 > With gigabit links that would mean rekeying every ten seconds or so...=20= The Create Child SA exchange can be efficiently run every ten seconds or = so, and most VPN tunnels are not that saturated. So I think the scale = argument is the stronger one. But both arguments lead to the conclusion = that you can=E2=80=99t tell someone who uses AES to switch to 3DES = because their setup may not be able to take it (rekey often enough or = encrypt fast enough), and you can=E2=80=99t tell them to switch to = ENCR_CAMELIA_CCM or ENCR_BLOWFISH because peers may not support these = algorithms. Yoav From nobody Thu Apr 2 07:21:15 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 B82291B2B70 for ; Thu, 2 Apr 2015 07:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p33VQ2qXeEFh for ; Thu, 2 Apr 2015 07:21:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3051A90F2 for ; Thu, 2 Apr 2015 07:21:02 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33062 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YdfzQ-000LWj-Mt for ipsec@ietf.org; Thu, 02 Apr 2015 10:21:00 -0400 Message-ID: <551D504C.7040601@bbn.com> Date: Thu, 02 Apr 2015 10:21:00 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> In-Reply-To: <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Thu, 02 Apr 2015 14:21:14 -0000 As the primary author of 4301, and the creator of the PAD, I believe this work does update that section of 4301. I agree with Kathleen that this doc needs to say precisely what parts of 4301 are being updated, perhaps using a before/after approach. Steve > On Apr 1, 2015, at 6:57 PM, Kathleen Moriarty wrote: >> I went back to the email thread as I wanted to look at the consensus and don't see it the way Paul does. >> Here is the end of the thread: >> http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html >> >> It reads as confusion with the term updates and most being ok with going in either direction, Paul against and Yaron more in favor. > Yes, exactly. So, it sounds like you see the consensus (and confusion) the way I do. > >> Updates can update very specific text in a draft. Since this just applies in this special case, the updates text needs to be clearly worded to reflect that or you copy in all the text that applies from the other draft. > Sounds fine. Who do you want to make that decision? > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Apr 2 08:05: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 D75721B2CC6 for ; Thu, 2 Apr 2015 08:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 skzuBRxJkXrs for ; Thu, 2 Apr 2015 08:05:46 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 6F2651B2CF1 for ; Thu, 2 Apr 2015 08:05:35 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so88451824wgb.1 for ; Thu, 02 Apr 2015 08:05:34 -0700 (PDT) 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=TgXNpmW1huXeUV2SkWe11CX7GPYoN5aWIE0b6zc+qr8=; b=BIpv3toBkxMly6grBNnxYbJZ4szKC05AcHPhjlf/BDztSIs2etkoZ+Tsy4+2NdvzW0 7bm686dQNX7GBUxW0gApfgzncuR37TdUVLYb0JEXDLeMH3DP9gZ694n+WqY+JEwPteIV E9PJaQRYufdKw9GJ+CpoUbu+nfHzhgl309nTKNinqXPEsIWGxZC2uKhgNNG31EUHBEmy SVRdKbTwt7paYzGYgOkYHW5yvb/XEe5EEpgpNoFz15u7qXtbRRJnl0US1e5pKnSPuabi CdqYQ4U/TfSWw/8as5lfb+FmrnhFAQz+1NisuHltbvufuALwXyVxaCUOHLIga/jqpc4e y5Lg== X-Received: by 10.194.93.165 with SMTP id cv5mr97481549wjb.24.1427987134233; Thu, 02 Apr 2015 08:05:34 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ge8sm7622773wjc.32.2015.04.02.08.05.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 08:05:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 2 Apr 2015 18:05:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> To: "Scott Fluhrer (sfluhrer)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 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, 02 Apr 2015 15:05:48 -0000 > On Mar 30, 2015, at 8:42 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Monday, March 30, 2015 10:40 AM > To: internet-drafts@ietf.org > Cc: ipsec@ietf.org; i-d-announce@ietf.org > Subject: [IPsec] Two questions about = draft-ietf-ipsecme-chacha20-poly1305-00 >=20 >> Hi, >>=20 >> There is two questions I would like guidance from the group about. >>=20 >> First is the nonce/IV question: In the current draft, there is a = 64-bit IV with guidance not to repeat them (so use a counter or LFSR). = The function itself accepts a 96-bit input nonce, so the nonce is = constructed from the 64-bit IV and 32 zero bits. The reason for doing = this is so the algorithm could be used in a multi-sender case such as = GDOI, where the 32-bit zero can be replaced by a sender ID.=20 >=20 > This idea about the multi-sender case works only if the there's a = sender id somewhere in the encrypted packet. You=E2=80=99re right. For some reason I thought that the SID in GDOI was = implied rather than transmitted on the wire. Oh, well=E2=80=A6 >> Alternatively, we could generate a 32-bit salt value from the key = material, but I don=E2=80=99t see a reason why we=E2=80=99d want that. >=20 > Here's the reason that we do use the 32-bit salt value for GCM - to = prevent batching attacks. >=20 > Consider the case that an attacker is able to collect packets from a = billion (2^30) sessions; each such session contains a packet with the = same IV (say, IV=3D0), and contains a packet with the same known = plaintext (or, at least, plaintext that satisfies the same known linear = equations). Then, what an attacker can do is check a key to see if any = of the IV=3D0 packets used that key, in constant time. The reduces the = effort for an attacker to find the n bit key for some session from 2^n = to 2^{n-30}. What the salt does is multiply the effort involved in this = specific attack by a factor of 2^32 (because the attacker needs to guess = the key and the salt); that way, the attacker needs to collect 4 billion = sessions before this attack starts to have any advantage over a simpler = attack that just attacks a single packet (which the salt doesn=E2=80=99t = protect against). >=20 > Now, of course, chacha20 has 256 bit keys; hence even if we decided = not to apply the same protection, someone with a collection of a billion = sessions might be able to use this to reduce the effort to 2^226. >=20 > I'll let you decide whether this is a compelling argument or not=E2=80=A6= I think that for 256-bit keys it=E2=80=99s not that compelling. So the = question is which is simpler: to do as AES-GCM does, or to set the salt = to zero? Yoav From nobody Thu Apr 2 20:22: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 276421A0107 for ; Thu, 2 Apr 2015 20:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 F8KU__B4d9lV for ; Thu, 2 Apr 2015 20:22:39 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 956441A00A7 for ; Thu, 2 Apr 2015 20:22:34 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so126708961wib.1 for ; Thu, 02 Apr 2015 20:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PD5BKK+rnXS441B7YJKDlGJkDQV6q2dE9GywbFyVd48=; b=wbO/ew2qxUabMPJe1FmsON8x8ByHsVQViiokDPsgvx2w79PZ0AukHLPN0Xj3I+g+Do JVfehcPydoDbCPba0JHiqBawLX+/3xcmwviNswPLzJx2UNE/F1UM61Ah6sO12d9BcODo fd3t94FO2vnKVGRp3GAr+VBMpcdYcjj49urbafi0U+h80un2/h/L+OhGMZEl318/IU+t k5CT7MbQNAUk1wRrPFMiUnc5pu7DwFkEGjmLbJ/QcVPlS3zjOWWtHa+H6oMetGCHS0FY 7GIVgWxgALi1U+SxWZ4ofXdDAkUvcKEsO2L233R6PAy2lIdXu1us3J9/wMf6gbl/ZvSM 6Znw== X-Received: by 10.180.101.225 with SMTP id fj1mr1593065wib.56.1428031353420; Thu, 02 Apr 2015 20:22:33 -0700 (PDT) Received: from [10.0.0.4] (bzq-109-64-164-3.red.bezeqint.net. [109.64.164.3]) by mx.google.com with ESMTPSA id ad7sm914312wid.21.2015.04.02.20.22.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 20:22:31 -0700 (PDT) Message-ID: <551DE781.6070507@gmail.com> Date: Fri, 03 Apr 2015 02:06:09 +0100 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoav Nir , "Scott Fluhrer (sfluhrer)" References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 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, 03 Apr 2015 03:22:41 -0000 >> Here's the reason that we do use the 32-bit salt value for GCM - to prevent batching attacks. >> >> Consider the case that an attacker is able to collect packets from a billion (2^30) sessions; each such session contains a packet with the same IV (say, IV=0), and contains a packet with the same known plaintext (or, at least, plaintext that satisfies the same known linear equations). Then, what an attacker can do is check a key to see if any of the IV=0 packets used that key, in constant time. The reduces the effort for an attacker to find the n bit key for some session from 2^n to 2^{n-30}. What the salt does is multiply the effort involved in this specific attack by a factor of 2^32 (because the attacker needs to guess the key and the salt); that way, the attacker needs to collect 4 billion sessions before this attack starts to have any advantage over a simpler attack that just attacks a single packet (which the salt doesn’t protect against). >> >> Now, of course, chacha20 has 256 bit keys; hence even if we decided not to apply the same protection, someone with a collection of a billion sessions might be able to use this to reduce the effort to 2^226. >> >> I'll let you decide whether this is a compelling argument or not… > > I think that for 256-bit keys it’s not that compelling. So the question is which is simpler: to do as AES-GCM does, or to set the salt to zero? > It seems to me like a "truth in advertising" kind of thing: if we use a 256-bit cipher then people using it expect 256-bit strength, rather than 2^226. So I would be happy if we can get the salt without having to pay in packet length. Thanks, Yaron From nobody Sat Apr 4 18:00: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 AEE371A1B82 for ; Sat, 4 Apr 2015 18:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqP-5TWGL9Pf for ; Sat, 4 Apr 2015 18:00:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0B51A1B8C for ; Sat, 4 Apr 2015 18:00:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lKGrC0FNsz6c; Sun, 5 Apr 2015 03:00:11 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=GbwwKnc/ 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 O2lacGv7x2r0; Sun, 5 Apr 2015 03:00:08 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 5 Apr 2015 03:00:08 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6D3D803E0; Sat, 4 Apr 2015 21:00:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1428195607; bh=jZ4g7upq46e0Yjvu1GVZTgMRCpBZhuZShoj9orAwD4Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GbwwKnc/3KE0BIKCWLBYukv+OXwiTo/3phJ9OApWBifPoufLQgMdRGSVrLY534BZ6 25XorEWZ+YotZh3ySDLeNbqX7Mx0kTwUaaXAgH80z0UnuX2Y6JvSYuY9o+u2J7V8dO HSPL7Nc6npk4b0bPXZAzYiCMZ8xJz0K9eHdtAzn0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t351071S027514; Sat, 4 Apr 2015 21:00:07 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 4 Apr 2015 21:00:07 -0400 (EDT) From: Paul Wouters To: Stephen Kent In-Reply-To: <551D504C.7040601@bbn.com> Message-ID: References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> <551D504C.7040601@bbn.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Sun, 05 Apr 2015 01:00:16 -0000 On Thu, 2 Apr 2015, Stephen Kent wrote: Hi Steve, > As the primary author of 4301, and the creator of the PAD, I believe this > work > does update that section of 4301. I agree with Kathleen that this doc needs > to > say precisely what parts of 4301 are being updated, perhaps using a > before/after > approach. Section 2.4 already describes our the changes to the PAD processing: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-05#section-2.4 The original PAD text of 4301 is here: https://tools.ietf.org/html/rfc4301#section-4.4.3.1 If our text is not suitable, could you perhaps explain what is missing, or even better, suggest text that would address your concerns with the current section? The text currently suggests using a new BOOL to determine if a PAD entry can use AUTH_NULL/ID_NULL. Would you prefer it rewritten as just another type of ID that is only added to the PAD authentication types as specified in 4301? If our current text is adequate, we can just add the "updated 4301" to the document. Thanks, Paul From nobody Sat Apr 4 18:44: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 E9AA01A6F3F for ; Sat, 4 Apr 2015 18:44:25 -0700 (PDT) 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 rVVinOvgOjgo for ; Sat, 4 Apr 2015 18:44:24 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 C87801A6F27 for ; Sat, 4 Apr 2015 18:44:23 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so1724603lbb.0 for ; Sat, 04 Apr 2015 18:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yl4o7fliRFeo2EXQo8JL1ZUJyFaSS+TZsSu/avRCh1U=; b=MZ7t5eeY7Y5q9GSIhcFlckIdjeGEPKtP8pBpNOF6UJlCKw0xBoWvoKsSMrW7BchuVo 7gil01DrNmLRJYPNQZ94ZdxlsTpWFRL8nNEr9wYv8OkOz8017OUqCXdoE7pjGQMOZjcV pQ7gtaO/eh/NQYmxOGUDe2ng1fq9+R2XfAZ/e6nD9eAdTF/DkAosS63Tr1uFcmP41AIo bKFZqH842CGRKs8fmevs123fogPiP3z/rjnE9kksjyyMbFFb4jc7fmAOGbNXGcopJlJe vdSybE4ZWnKep2UPckAp+qlYNEomtMGJeUN203+d0tR0C7HvXMW8OoBP/U5XYsuHpEAt 4q/g== MIME-Version: 1.0 X-Received: by 10.112.199.133 with SMTP id jk5mr607089lbc.32.1428198262062; Sat, 04 Apr 2015 18:44:22 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Sat, 4 Apr 2015 18:44:21 -0700 (PDT) In-Reply-To: References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> <8CB67699-1986-417D-B270-678EBCBA7C29@vpnc.org> <551D504C.7040601@bbn.com> Date: Sat, 4 Apr 2015 21:44:21 -0400 Message-ID: From: Kathleen Moriarty To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c264be14436c0512f05292 Archived-At: Cc: "ipsec@ietf.org WG" , Stephen Kent Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.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: Sun, 05 Apr 2015 01:44:26 -0000 --001a11c264be14436c0512f05292 Content-Type: text/plain; charset=UTF-8 Sorry for my delay in response, I was at a conference in Thursday and am still catching up. On Sat, Apr 4, 2015 at 9:00 PM, Paul Wouters wrote: > On Thu, 2 Apr 2015, Stephen Kent wrote: > > Hi Steve, > > As the primary author of 4301, and the creator of the PAD, I believe this >> work >> does update that section of 4301. I agree with Kathleen that this doc >> needs to >> say precisely what parts of 4301 are being updated, perhaps using a >> before/after >> approach. >> > > Section 2.4 already describes our the changes to the PAD processing: > > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null- > auth-05#section-2.4 > > The original PAD text of 4301 is here: > > https://tools.ietf.org/html/rfc4301#section-4.4.3.1 > > If our text is not suitable, could you perhaps explain what is missing, > or even better, suggest text that would address your concerns with the > current section? > > The text currently suggests using a new BOOL to determine if a PAD entry > can use AUTH_NULL/ID_NULL. Would you prefer it rewritten as just another > type of ID that is only added to the PAD authentication types as specified > in 4301? > > If our current text is adequate, we can just add the "updated 4301" to > the document. > The problem is the current wording. I see Tero's point that you are really extending 4301, but you say you are updating it in the text with MUST statements. If you change that language, and include what you need from 4301, then you are fine with this as stand alone. Another way to handle it is to say that you are updating 4301, in a way that is specific to NULL Auth and this extension/update is only needed for AUTH_NULL/ID_NULL. That's still an "updates'. Thanks, Kathleen > > Thanks, > > Paul > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Best regards, Kathleen --001a11c264be14436c0512f05292 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for my delay in response, I was at a conference in T= hursday and am still catching up.

On Sat, Apr 4, 2015 at 9:00 PM, Paul Wouters <paul@nohats.ca= > wrote:
On Thu, 2 Apr 2015= , Stephen Kent wrote:

Hi Steve,

As the primary author of 4301, and the creator of the PAD, I believe this w= ork
does update that section of 4301. I agree with Kathleen that this doc needs= to
say precisely what parts of 4301 are being updated, perhaps using a before/= after
approach.

 Section 2.4 already describes our the changes to the PAD processing:

https://tools.ietf.org/html/draft-i= etf-ipsecme-ikev2-null-auth-05#section-2.4

The original PAD text of 4301 is here:

https://tools.ietf.org/html/rfc4301#section-4.4.3.1

If our text is not suitable, could you perhaps explain what is missing,
or even better, suggest text that would address your concerns with the
current section?

The text currently suggests using a new BOOL to determine if a PAD entry can use AUTH_NULL/ID_NULL. Would you prefer it rewritten as just another type of ID that is only added to the PAD authentication types as specified<= br> in 4301?

If our current text is adequate, we can just add the "updated 4301&quo= t; to
the document.

The problem is the curren= t wording.=C2=A0 I see Tero's point that you are really extending 4301,= but you say you are updating it in the text with MUST statements.=C2=A0 If= you change that language, and include what you need from 4301, then you ar= e fine with this as stand alone.=C2=A0 Another way to handle it is to say t= hat you are updating 4301, in a way that is specific to NULL Auth and this = extension/update is only needed for AUTH_NULL/ID_NULL.=C2=A0 That's sti= ll an "updates'.

Thanks,
Kathle= en

Thanks,

Paul


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



--
=

Best regards,
Kathleen
--001a11c264be14436c0512f05292-- From nobody Sat Apr 4 22: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 B1DDB1A88C5; Sat, 4 Apr 2015 22:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 hhTXz-FWKJE1; Sat, 4 Apr 2015 22:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9595E1A88BE; Sat, 4 Apr 2015 22:34:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150405053454.12661.13478.idtracker@ietfa.amsl.com> Date: Sat, 04 Apr 2015 22:34:54 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-02.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: Sun, 05 Apr 2015 05:34:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE & IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-02.txt Pages : 7 Date : 2015-04-04 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 4 22:39:53 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 1FE271A88C4 for ; Sat, 4 Apr 2015 22:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 QeW2MTsemXh6 for ; Sat, 4 Apr 2015 22:39:50 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 4BC6B1A88BF for ; Sat, 4 Apr 2015 22:39:50 -0700 (PDT) Received: by wgra20 with SMTP id a20so4252354wgr.3 for ; Sat, 04 Apr 2015 22:39:49 -0700 (PDT) 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=9R8Dzu/77fhZ8culZnW/8YYnghLWe56m9LXvsewwRks=; b=fhOPBT/4vnjgSWDT10Z5CW3yB4xJJ6wZ87+r2b1+k/IaMeUiyiWVXWIENk4sWOozuc 5VIU9Lta5WRn/rfCnP3ZyLhTtuAnn9Z0anSo8ac9DDYXUnemK6e7VTGWm3BZzgVL3rNf fZ1gbDyE/YY4XKwsF37bp7M1+wDdRWUscqO+TAnIDlNFN4R72AOexbv2X0H+q0GFd2lo C5PYZpFipqk7h39o2EOTKN3qH/hJiiw3dZrFhi75ETp6GCQDFtC88NOzfdfl9HvFlJ6k Wdf61QrB34U4+cqS3fkJMaaAcuPUWt/hSQ3TOSnLj5pMk1N76BXnFHTV1kGMmgUp4DH6 UYZQ== X-Received: by 10.194.120.230 with SMTP id lf6mr19454295wjb.78.1428212389089; Sat, 04 Apr 2015 22:39:49 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([109.253.157.204]) by mx.google.com with ESMTPSA id ng5sm1008598wic.24.2015.04.04.22.39.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Apr 2015 22:39:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150405053454.12661.13478.idtracker@ietfa.amsl.com> Date: Sun, 5 Apr 2015 08:39:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <21F037E7-04E9-42BD-A93F-EF45407B7D4E@gmail.com> References: <20150405053454.12661.13478.idtracker@ietfa.amsl.com> To: IETF IPsec X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-02.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: Sun, 05 Apr 2015 05:39:52 -0000 Hi Updated the draft. Changes: * Aligned the description of the AEAD construction with the one in the = latest CFRG draft and fixed the references (thanks, Martin Willi) * Added a section about negotiating it in IKE * Renamed the constant to uppercase: ENCR_CHACHA20_POLY1305 Since I only got an opinion from Yaron, and the explanation from Scott, = for now I=E2=80=99ve left the SenderID as zero rather than convert it to = a derived-from-the-key-block salt. Yoav > On Apr 5, 2015, at 8:34 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IKE & = IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-02.txt > Pages : 7 > Date : 2015-04-04 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-02 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-02= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 6 11:40: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 1D1B11A90B4 for ; Mon, 6 Apr 2015 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WmHF2-CuKg6o for ; Mon, 6 Apr 2015 11:40:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C858F1A90AF for ; Mon, 6 Apr 2015 11:40:13 -0700 (PDT) Received: from BLUPR03MB1330.namprd03.prod.outlook.com (25.163.80.20) by BLUPR03MB550.namprd03.prod.outlook.com (10.141.76.28) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 6 Apr 2015 18:40:12 +0000 Received: from DM2PR03MB448.namprd03.prod.outlook.com (10.141.85.24) by BLUPR03MB1330.namprd03.prod.outlook.com (25.163.80.20) with Microsoft SMTP Server (TLS) id 15.1.130.23; Mon, 6 Apr 2015 18:40:10 +0000 Received: from DM2PR03MB448.namprd03.prod.outlook.com ([10.141.85.24]) by DM2PR03MB448.namprd03.prod.outlook.com ([10.141.85.24]) with mapi id 15.01.0130.020; Mon, 6 Apr 2015 18:40:10 +0000 From: "jyothi.v@freescale.com" To: Tero Kivinen , "suram@freescale.com" Thread-Topic: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt Thread-Index: AQHQZxoNamsAqjBlfUGhIeXSidl54J0xceCAgAOXW4CAC1gyQA== Date: Mon, 6 Apr 2015 18:40:10 +0000 Message-ID: References: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> <21785.19623.491977.563080@fireball.kivinen.iki.fi> In-Reply-To: <21785.19623.491977.563080@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.169.1] authentication-results: iki.fi; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1330; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB550; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(377454003)(54356999)(66066001)(76176999)(74316001)(19580395003)(122556002)(40100003)(46102003)(230783001)(19580405001)(99286002)(106116001)(50986999)(33656002)(2900100001)(62966003)(92566002)(2656002)(76576001)(87936001)(2950100001)(102836002)(86362001)(77156002)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1330; H:DM2PR03MB448.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BLUPR03MB1330; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1330; x-forefront-prvs: 0538A71254 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2015 18:40:10.3325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1330 X-OriginatorOrg: freescale.com Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-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, 06 Apr 2015 18:40:16 -0000 Hi, Very sorry for the late reply. We have considered roaming VPN client scenario where MOBIKE may not be requ= ired,=20 NAT can be enabled or disabled any time due to administrative reasons. Thanks Jyothi -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, March 30, 2015 6:46 PM To: Suram Chandra Sekhar-B38523 Cc: ipsec@ietf.org Subject: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-t= raversal-00.txt suram@freescale.com writes: > A new Internet Draft is posted to the working group. > The draft addresses a problem where NAT is enabled dynamically (after=20 > IPsec SA is created) because of which traffic stops. This is already supported when MOBIKE is used, and without MOBIKE the IP-ad= dresses cannot change, thus NAT cannot suddenly appear in the middle. Can you explain in which situations the NAT will be enbled after the IKEv2 connection has been creteated in such way that IP-addresses of both e= nd points stay same? If the IP-addresses change, then to be able to keep the same IKEv2 connecti= on you need to use MOBIKE and MOBIKE will already automatically enable NAT = if it detects NAT while moving traffic from one IP-address to another. > The draft uses the existing IKEv2 framework (without defining any new=20 > payloads) and maintains backward compatibility with older=20 > implementations of IKEv2 that does not support this draft. >=20 > We request your feedback on the same. Can you explain what is problem with the already standardized solution to t= his problem, and why do you think it does not solve the issue? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 6 12:08: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 2D6541A90D0 for ; Mon, 6 Apr 2015 12:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5qc-m3Y-C3A1 for ; Mon, 6 Apr 2015 12:08:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C0D1A90CD for ; Mon, 6 Apr 2015 12:08:00 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:52399 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YfCNK-000Ao5-UL for ipsec@ietf.org; Mon, 06 Apr 2015 15:07:59 -0400 Message-ID: <5522D98E.6010500@bbn.com> Date: Mon, 06 Apr 2015 15:07:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [IPsec] mot sure if this posted before, so resending 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, 06 Apr 2015 19:08:01 -0000 Yoav, > Hi, > > There is two questions I would like guidance from the group about. > > First is the nonce/IV question: In the current draft, there is a > 64-bit IV with guidance not to repeat them (so use a counter or LFSR). > The function itself accepts a 96-bit input nonce, so the nonce is > constructed from the 64-bit IV and 32 zero bits. The reason for doing > this is so the algorithm could be used in a multi-sender case such as > GDOI, where the 32-bit zero can be replaced by a sender ID. > Alternatively, we could generate a 32-bit salt value from the key > material, but I don’t see a reason why we’d want that. Another thing > we could do is what some people are advocating for TLS: Since a > counter is a fine IV (no need for secrecy), we don’t need a 64-bit IV > that has the exact same value as the replay counter. We might as well > save 8 bytes per packet and just feed the replay counter to the > function. The argument against this is that some crypto modules may > have the API set up in such a way that the IVs are generated within > the module and could be something other than a counter (like an LFSR). > The proposal will break such APIs. agreed. The other, related issue, is that if one wants to achieve FIPS certification for an alg like this, the nonce/IV needs to be within the eval boundary for the alg certification. I realize that ChaCha is not a FIPS alg, but I recall someone asking NIST if it might be willing to evaluate ChaCha. If the goal is (eventual) FIPS evaluation, then it makes sense to consider the implications of trying to reuse the ESP sequence counter as an input to the IV/nonce in this context. Steve From nobody Tue Apr 7 02:04: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 AE2BE1B3337 for ; Tue, 7 Apr 2015 02:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 dR_6oHT738CT for ; Tue, 7 Apr 2015 02:04:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 9EC2B1B332F for ; Tue, 7 Apr 2015 02:04:33 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t3794PvL003525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Apr 2015 12:04:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t3794OLU015638; Tue, 7 Apr 2015 12:04:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21795.40344.313715.918148@fireball.kivinen.iki.fi> Date: Tue, 7 Apr 2015 12:04:24 +0300 From: Tero Kivinen To: "jyothi.v\@freescale.com" In-Reply-To: References: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> <21785.19623.491977.563080@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: Cc: "ipsec@ietf.org" , "suram@freescale.com" Subject: Re: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-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, 07 Apr 2015 09:04:35 -0000 jyothi.v@freescale.com writes: > Hi, > > Very sorry for the late reply. > > We have considered roaming VPN client scenario where MOBIKE may not > be required, So you do not want to implement already standardized protocol to solve the issue, and want to create new extension to solve partial issue? > NAT can be enabled or disabled any time due to administrative > reasons. And how is that supposed to work. If I have network described in the draft: +-+-+-+-+ +-+-+-+-+ IPsec +-+-+-+-+ |Roaming| |Edge | tunnel |Corp | Protected | User |<--->|Router |<========>|Gateway|<--> network +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 198. 198. 130. 133. 51. 51. 233. 42. 100. 100. 208. 11. 22 1 1 1 I.e. Roaming user has public IP-address of 192.51.100.22, and its default gateway is 192.51.100.1, and it uses that to connect to the corporate gateway at ip-address 133.42.11.1. The roaming user already has public routable IP-address which it can use to connect to internet. What benefits you get by suddenly NAT:ing it to some other public routable IP-address? The normal reason for NAT is to provide ability to have multiple user sharing the same IP address, but if roaming user already has public routable IP-address, there is no need for that. I do not really see what you are trying to do here, what is the reason for this, and why it would ever be useful to add NAT for public routable IP-address because of some adminstrative reasons? I.e. what are those adminstrative reasons? In normal case when you add NAT there in the middle, the roaming user will loose its public IP-address, and then network will then be: +-+-+-+-+ +-+-+-+-+ IPsec +-+-+-+-+ |Roaming| |Edge | tunnel |Corp | Protected | User |<--->|Router |<========>|Gateway|<--> network +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 10. 10. 130. 133. 1. 1. 233. 42. 1. 1. 208. 11. 22 1 1 1 and that is again the case which MOBIKE was specified to solve. -- kivinen@iki.fi From nobody Tue Apr 7 03:27: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 0EA591B33E3 for ; Tue, 7 Apr 2015 03:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RF81JwI-wZ-c for ; Tue, 7 Apr 2015 03:27:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98431B33D2 for ; Tue, 7 Apr 2015 03:27:42 -0700 (PDT) Received: from DM2PR03MB448.namprd03.prod.outlook.com (10.141.85.24) by BLUPR03MB1329.namprd03.prod.outlook.com (0.163.80.19) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 10:27:25 +0000 Received: from DM2PR03MB448.namprd03.prod.outlook.com ([10.141.85.24]) by DM2PR03MB448.namprd03.prod.outlook.com ([10.141.85.24]) with mapi id 15.01.0130.020; Tue, 7 Apr 2015 10:27:25 +0000 From: "jyothi.v@freescale.com" To: Tero Kivinen Thread-Topic: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt Thread-Index: AQHQZxoNamsAqjBlfUGhIeXSidl54J0xceCAgAOXW4CAC1gyQIAA9A4AgAAVvXA= Date: Tue, 7 Apr 2015 10:27:25 +0000 Message-ID: References: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> <21785.19623.491977.563080@fireball.kivinen.iki.fi> <21795.40344.313715.918148@fireball.kivinen.iki.fi> In-Reply-To: <21795.40344.313715.918148@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.169.1] authentication-results: iki.fi; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1329; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377454003)(2656002)(99286002)(93886004)(50986999)(62966003)(230783001)(46102003)(54356999)(87936001)(19580405001)(106116001)(19580395003)(76176999)(77156002)(110136001)(66066001)(76576001)(33656002)(2900100001)(2950100001)(40100003)(92566002)(102836002)(77096005)(86362001)(74316001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1329; H:DM2PR03MB448.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR03MB1329; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1329; x-forefront-prvs: 0539EEBD11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2015 10:27:25.3034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1329 Archived-At: Cc: "ipsec@ietf.org" , "suram@freescale.com" Subject: Re: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-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, 07 Apr 2015 10:27:45 -0000 Roaming user is behind the edge router. Control of issuing address is in edge router. Edge router may issue a public IP when NAT is not configured, later NAT con= figured, but IP is not changed immediately. Thanks Jyothi -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Tuesday, April 07, 2015 2:34 PM To: Vemulapalli Jyothi-B37784 Cc: Suram Chandra Sekhar-B38523; ipsec@ietf.org Subject: RE: [IPsec] FW: New Version Notification for draft-suram-dynamic-n= at-traversal-00.txt jyothi.v@freescale.com writes: > Hi, >=20 > Very sorry for the late reply. >=20 > We have considered roaming VPN client scenario where MOBIKE may not be=20 > required, So you do not want to implement already standardized protocol to solve the = issue, and want to create new extension to solve partial issue?=20 > NAT can be enabled or disabled any time due to administrative reasons. And how is that supposed to work. If I have network described in the draft: +-+-+-+-+ +-+-+-+-+ IPsec +-+-+-+-+ |Roaming| |Edge | tunnel |Corp | Protected | User |<--->|Router |<=3D=3D=3D=3D=3D=3D=3D=3D>|Gateway|<--> network +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 198. 198. 130. 133. 51. 51. 233. 42. 100. 100. 208. 11. 22 1 1 1 I.e. Roaming user has public IP-address of 192.51.100.22, and its default g= ateway is 192.51.100.1, and it uses that to connect to the corporate gatewa= y at ip-address 133.42.11.1. The roaming user already has public routable IP-address which it can use to= connect to internet. What benefits you get by suddenly NAT:ing it to some = other public routable IP-address? The normal reason for NAT is to provide a= bility to have multiple user sharing the same IP address, but if roaming us= er already has public routable IP-address, there is no need for that. I do not really see what you are trying to do here, what is the reason for = this, and why it would ever be useful to add NAT for public routable IP-add= ress because of some adminstrative reasons? I.e. what are those adminstrati= ve reasons? In normal case when you add NAT there in the middle, the roaming user will = loose its public IP-address, and then network will then be: +-+-+-+-+ +-+-+-+-+ IPsec +-+-+-+-+ |Roaming| |Edge | tunnel |Corp | Protected | User |<--->|Router |<=3D=3D=3D=3D=3D=3D=3D=3D>|Gateway|<--> network +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ 10. 10. 130. 133. 1. 1. 233. 42. 1. 1. 208. 11. 22 1 1 1 and that is again the case which MOBIKE was specified to solve.=20 -- kivinen@iki.fi From nobody Tue Apr 7 04:21: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 D9EA91B3497 for ; Tue, 7 Apr 2015 04:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 k0ymoVf6jMMB for ; Tue, 7 Apr 2015 04:21:51 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 363F21B3495 for ; Tue, 7 Apr 2015 04:21:51 -0700 (PDT) Received: by widdi4 with SMTP id di4so13343185wid.0 for ; Tue, 07 Apr 2015 04:21:50 -0700 (PDT) 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=YxzBlqL9XDpKs20+p1KRPBIrbdoOGa5V3U7sNW69NFw=; b=vu3KyiH1uy+/Kpxgy6PZWlWG2TJqtF1ItNS4o8oOAIMDdjDK2uAL94/zDSwTHN4adE TlWFb5mKCzGJlveuqyYktxk0jD/iMgfKCScqmYIkQHvRX9cf4x/EfyEKeTNeJh6/bjio 0lWuQHL3uNnJziZrJgrGN5GZbzVY83R6JdjZD0/yt/hj11KBMq+6O7HdxHj1/PD3RCrP GCYqSd8kgGqtnb0HO2J5P57A1oNUpHOtcg7/IvfaWnw6ujS3f6YEOrNqQC6yck0mh8en rqeRRgKyhFFrNEzcSLGNFAR4zS8rIk9OZQ9XtDr/MGWFBcnbz/aYktEMhro1q/QZKfUg fZqQ== X-Received: by 10.180.106.70 with SMTP id gs6mr3636381wib.36.1428405709942; Tue, 07 Apr 2015 04:21:49 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ey10sm10598707wib.2.2015.04.07.04.21.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Apr 2015 04:21:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <5522D98E.6010500@bbn.com> Date: Tue, 7 Apr 2015 14:21:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <26620372-A54A-45EE-B0AE-8321CAF5738C@gmail.com> References: <5522D98E.6010500@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ipsec Subject: Re: [IPsec] mot sure if this posted before, so resending 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, 07 Apr 2015 11:21:54 -0000 > On Apr 6, 2015, at 10:07 PM, Stephen Kent wrote: >=20 > Yoav, >=20 >> Hi, >>=20 >> There is two questions I would like guidance from the group about. >>=20 >> First is the nonce/IV question: In the current draft, there is a = 64-bit IV with guidance not to repeat them (so use a counter or LFSR). = The function itself accepts a 96-bit input nonce, so the nonce is = constructed from the 64-bit IV and 32 zero bits. The reason for doing = this is so the algorithm could be used in a multi-sender case such as = GDOI, where the 32-bit zero can be replaced by a sender ID. = Alternatively, we could generate a 32-bit salt value from the key = material, but I don=E2=80=99t see a reason why we=E2=80=99d want that. = Another thing we could do is what some people are advocating for TLS: = Since a counter is a fine IV (no need for secrecy), we don=E2=80=99t = need a 64-bit IV that has the exact same value as the replay counter. We = might as well save 8 bytes per packet and just feed the replay counter = to the function. The argument against this is that some crypto modules = may have the API set up in such a way that the IVs are generated within = the module and could be something other than a counter (like an LFSR). = The proposal will break such APIs. > agreed. The other, related issue, is that if one wants to achieve FIPS = certification > for an alg like this, the nonce/IV needs to be within the eval = boundary for the > alg certification. I realize that ChaCha is not a FIPS alg, but I = recall someone > asking NIST if it might be willing to evaluate ChaCha. If the goal is = (eventual) > FIPS evaluation, then it makes sense to consider the implications of = trying to reuse the > ESP sequence counter as an input to the IV/nonce in this context. >=20 I think it=E2=80=99s risky to base decisions on our attempts to divine = future NIST decisions, but I agree that out best option now is to leave = the 64-bit IV (or nonce) explicit for now and perhaps later add an IKE = extension that allows you to =E2=80=9Ccompress=E2=80=9D the IV as long = as it=E2=80=99s equal to the packet counter. That allows the ESP = implementation to compress the ESP packet as long as the encryption = module keeps generating payloads that have an IV exactly the same as the = packet counter. I=E2=80=99ve recently had the dubious pleasure of going over some NIST = document ([1]). Appendix A.5 is about Key/IV pair uniqueness in AES-GCM, = but I guess (divining again=E2=80=A6) that if they ever accept ChaCha20, = they might ask for similar things. So what does it say about IV = generation?=20 There are several ways to generate the IV. One is to generate = the IV in compliance with the TLS 1.2 GCM Cipher Suites for TLS, as described in the corresponding IETF = RFC 5116 and 5288. Alternatively, the IV may=20 be generated randomly or set deterministically, possibly by = being incremented by 1 every time a new value=20 is needed. That sounds good, because =E2=80=9Cdeterministically=E2=80=A6 by being = incremented by 1 every time=E2=80=9D is exactly what we=E2=80=99re = looking for, right? The document goes on to say that the method in RFC = 5288 is allowed only for TLS 1.2, and =E2=80=9Cin all other cases the = following requirements shall be satisfied=E2=80=9D If the GCM Key is generated either internally or externally and = the IV is generated internally=20 deterministically then the requirement of SP 800-38D quoted in = the Background section above will be=20 modified. Instead of requiring that the probability of any (key, = IV) collision anywhere in the=20 Universe at all times did not exceed 2^-32, it will only be = required that for a given key distributed to=20 one or more cryptographic modules, the (key, IV) collision = probability would not exceed 2^-32. This=20 is equivalent to the requirement that for any key distributed to = one or more modules the probability of=20 a collision between the deterministically-generated IVs is no = greater than 2^-32. That is still fine, because a 64-bit counter has a zero chance of = repeating, and 0 < 2^-32. But then the document goes on to =E2=80=9Cspecif= y what the module has to do to meet this requirement=E2=80=9D. Each deterministically established IV shall include an encoding = of the module=E2=80=99s name and the=20 name shall be long enough to allow for at least 2^32 different = names. For example, if the module=E2=80=99s=20 name is such that it consists of at least 8 hexadecimal = characters then this condition is satisfied,=20 since 16^8 is no smaller than (indeed, equal to) 2^32 . = Alternatively, if the name consists of at least=20 6 alphanumerical characters, each having at least 62 values, = then this is also sufficient. Even=20 though not all possible names are equally likely to be used, = just the fact that the modules can=20 possibly have at least 232 different names will be sufficient to = meet this requirement. So now we=E2=80=99re supposed to dedicate 32 bits of the available 64 to = encoding the module name??? That leaves 32 bits per key for packet = counter. That also means that ESN is a superfluous feature, because if = you go above 2^32 packets per SA, the pigeonhole principle applies. Does anyone know the method behind this madness? Yoav [1] = http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf= From nobody Tue Apr 7 07:42:53 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 1E30D1B3662 for ; Tue, 7 Apr 2015 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FnM-NvysnIKT for ; Tue, 7 Apr 2015 07:42:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D449B1B3659 for ; Tue, 7 Apr 2015 07:42:19 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:56548 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YfUhm-000JcH-AZ for ipsec@ietf.org; Tue, 07 Apr 2015 10:42:18 -0400 Message-ID: <5523ECCA.4050709@bbn.com> Date: Tue, 07 Apr 2015 10:42:18 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <5522D98E.6010500@bbn.com> <26620372-A54A-45EE-B0AE-8321CAF5738C@gmail.com> In-Reply-To: <26620372-A54A-45EE-B0AE-8321CAF5738C@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] mot sure if this posted before, so resending 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, 07 Apr 2015 14:42:51 -0000 Yoav, > I think it’s risky to base decisions on our attempts to divine future NIST decisions, but I agree that out best option now is to leave the 64-bit IV (or nonce) explicit for now and perhaps later add an IKE extension that allows you to “compress” the IV as long as it’s equal to the packet counter. That allows the ESP implementation to compress the ESP packet as long as the encryption module keeps generating payloads that have an IV exactly the same as the packet counter. works for me. > I’ve recently had the dubious pleasure of going over some NIST document ([1]). Appendix A.5 is about Key/IV pair uniqueness in AES-GCM, but I guess (divining again…) that if they ever accept ChaCha20, they might ask for similar things. So what does it say about IV generation? > > There are several ways to generate the IV. One is to generate the IV in compliance with the TLS 1.2 GCM > Cipher Suites for TLS, as described in the corresponding IETF RFC 5116 and 5288. Alternatively, the IV may > be generated randomly or set deterministically, possibly by being incremented by 1 every time a new value > is needed. > > That sounds good, because “deterministically… by being incremented by 1 every time” is exactly what we’re looking for, right? seems reasonable to me. > The document goes on to say that the method in RFC 5288 is allowed only for TLS 1.2, and “in all other cases the following requirements shall be satisfied” > > If the GCM Key is generated either internally or externally and the IV is generated internally > deterministically then the requirement of SP 800-38D quoted in the Background section above will be > modified. Instead of requiring that the probability of any (key, IV) collision anywhere in the > Universe at all times did not exceed 2^-32, it will only be required that for a given key distributed to > one or more cryptographic modules, the (key, IV) collision probability would not exceed 2^-32. This > is equivalent to the requirement that for any key distributed to one or more modules the probability of > a collision between the deterministically-generated IVs is no greater than 2^-32. > > That is still fine, because a 64-bit counter has a zero chance of repeating, and 0 < 2^-32. But then the document goes on to “specify what the module has to do to meet this requirement”. > > Each deterministically established IV shall include an encoding of the module’s name and the > name shall be long enough to allow for at least 2^32 different names. For example, if the module’s > name is such that it consists of at least 8 hexadecimal characters then this condition is satisfied, > since 16^8 is no smaller than (indeed, equal to) 2^32 . Alternatively, if the name consists of at least > 6 alphanumerical characters, each having at least 62 values, then this is also sufficient. Even > though not all possible names are equally likely to be used, just the fact that the modules can > possibly have at least 232 different names will be sufficient to meet this requirement. > > So now we’re supposed to dedicate 32 bits of the available 64 to encoding the module name??? That leaves 32 bits per key for packet counter. That also means that ESN is a superfluous feature, because if you go above 2^32 packets per SA, the pigeonhole principle applies. > > Does anyone know the method behind this madness? I think the module name requirement is intended to accommodate multi-sender, same key, scenarios, but you should direct the question to NIST, e.g., lily.chen@nist.gov. Steve From nobody Tue Apr 14 01:47:21 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 193211A00E5 for ; Tue, 14 Apr 2015 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.509 X-Spam-Level: *** X-Spam-Status: No, score=3.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_31=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 OTvVoSqmAlwH for ; Tue, 14 Apr 2015 01:47:18 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71B61A00CC for ; Tue, 14 Apr 2015 01:47:17 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so2458274lbb.3 for ; Tue, 14 Apr 2015 01:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding; bh=tSUX+oGGeH3BOwD2PuZYg0StQQ7Zz8nQSi/vgHRqEyM=; b=Cxu6+NdtM9aPrwpBgKQXuWqwaq4zcKYtjhBdJ3dJF0PDPMpTydItyn3aLU/81fWUSg Ph6t2P4xZWvDCtqxQDIb65pAFANevOuO2kqqaLupf86rdtORkeSXpvrtaNtN8cubZm8r jWfNJrFiWYj8iszvKvpp4Qs1BCWwGHIFFr2w+H2Szk31iZYPxYZf1rz9cDyDBQjCOI3b wRq7w8fXZzGrDl0qsTDTICyazutXGBHI5j2hdx4hfEOG5c4bgpGqQab8Mcza2R06KBPK sfMDeSytK6oDB/5pXFXuuMP+Srpf2fliNTsJPTlXl6X0R7oR6qbysKGWas6I6t4Mxp5f ZkLg== X-Received: by 10.152.23.99 with SMTP id l3mr16964623laf.61.1429001236205; Tue, 14 Apr 2015 01:47:16 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id oy3sm84288lbb.1.2015.04.14.01.47.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 14 Apr 2015 01:47:15 -0700 (PDT) Message-ID: <020FB07F2D6E4240BC82077777117CE8@buildpc> From: "Valery Smyslov" To: Date: Tue, 14 Apr 2015 11:47:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ynir.ietf@gmail.com Subject: [IPsec] Fw: [ipsecme] #229 (ddos-protection): Need to decide the nature of the puzzle 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, 14 Apr 2015 08:47:20 -0000 Hi all, Yoav added a couple of new issues into the tracker, so I'd like to initiate the discussion of these issues. The first issue (#229) is concerned with the inconsistency of the puzzle solution time with the current definition of the puzzle. So the question - should we change the puzzle definition so that the deviation of the time required to solve it become smaller (ideally - all equally difficult puzzles should be solved in constant time by equal hosts). My opinion is that while this is a desireable property, it is not so important in real life. First, even if we make puzzle constant-time for equal initiators, it won't help since in real life the initiators are different and their computational power can differ even more than the deviation of solution time with the current puzzle definition. In other words, the real difficulty of any given puzzle is a relative value and it includes not only the requested number of zero bits, but also the computantional power of the initiator, which is in any case an unknown value for the responder. And second - the draft is about DDoS protection. It implies that the attack would involve many thouthands of attackers. In this situation the deviation of puzzle difficulty becomes less important, since statistically the puzzle solving time as it is seen from responder's point of view will be close to average. Of course, for any given initiator it will be a lottery and sometimes powerfull attacker will receive easy puzzle and sometimes weak legacy initiator will receive difficult puzzle. I see nothing fatal in the former - yes some DoS attacks will be successful. The protocol doesn't have the goal to completely eliminate the possibility of DoS attacks (and I don't think it is ever possible), but to make it harder for attackers. What about the latter - the protocol should consider such situation and should leave an initiator a chance to establish IKE SA even if the initiator is weak and the puzzle appeared to be difficult. So the conclusion - I don't think we should change puzzle definition so that it becomes close to constant-time giving the little value that it would give us (taking into consideration the vast diversity of clients) and the complexity it would involve and the increasing of the size of IKE messages. Regards, Valery. > #229: Need to decide the nature of the puzzle > > Current text has PRF based puzzles: for a given cookie and difficulty leve > l, find a key k, such that PRF(k, cookie) has at least l trailing zero > bits. > The problem with this puzzle is that while the expected time to solve this > puzzle is 2^l, the actual time varies wildly. > > Scott Fluhrer suggested ([1]) that we use another kind of puzzle that is > closer to constant-time. That requires more up-front work on the part of > the responder (creating a new opportunity for DoS?) and larger IKE_SA_INIT > requests. IKE_SA_INIT requests are not protected by IKEv2 fragmentation > > [1] http://www.ietf.org/mail-archive/web/ipsec/current/msg09601.html > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-ipsecme-ddos- > ynir.ietf@gmail.com | protection@tools.ietf.org > Type: task | Status: new > Priority: normal | Milestone: > Component: ddos- | Severity: Active WG Document > protection | > Keywords: | > -------------------------+------------------------------------------------- > > Ticket URL: > ipsecme From nobody Tue Apr 14 04:33: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 9209A1A8A09 for ; Tue, 14 Apr 2015 04:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.909 X-Spam-Level: ** X-Spam-Status: No, score=2.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 uoVkJG5-BBcE for ; Tue, 14 Apr 2015 04:33:30 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 1C72E1A8A0E for ; Tue, 14 Apr 2015 04:33:21 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so5621223lbb.3 for ; Tue, 14 Apr 2015 04:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding; bh=SLJhAsBuyKoI9tgiclRNkpP81HmyqWUf4tR6UG9A5MQ=; b=wvRbvd38HJ7YJEwEhpuFhjCa6/lEo6PuGVZerwu+IY7BF0QR2KacFXlHPdN7n/FMrI ZA5V/rqzjdKerPOIBkinB60CQqXQL0VYP9ArSZN11DYZUAcY8877PHAzbhusG6/qi+Lw qHamoXnIig/EAO7GLkdZjihSU2VTelg/D717PIk+QY6JTvjRLYGLQFaS9UTXKFvlOI7t TT5ikL6cMp4wbDDHrZ3d/+gxP2wsr+5ZqtPm8frXnzRDpByisu/CudUxwhk48KoMUu4/ L1yF/dOWEUxrVqALVx3Ng6FikLzq1YaR3nA6y/CppXfpFdLn38ssV0JlyQFhMPJwjLUC rCFA== X-Received: by 10.152.219.2 with SMTP id pk2mr17537160lac.107.1429011199465; Tue, 14 Apr 2015 04:33:19 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id f4sm173982lae.18.2015.04.14.04.33.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 14 Apr 2015 04:33:18 -0700 (PDT) Message-ID: <6E5D7F871230467B9CED1C081E45F15B@buildpc> From: "Valery Smyslov" To: Date: Tue, 14 Apr 2015 14:33:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ynir.ietf@gmail.com Subject: [IPsec] Fw: [ipsecme] #230 (ddos-protection): Use puzzles for DoS protection within an IKE SA 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, 14 Apr 2015 11:33:31 -0000 Hi again, another issue that is added to the tracker - whether to use puzzles for protection against nefarious IKE peers after IKE SA is established. My opinion - using puzzles after IKE SA is established is possible, but is not justified. It would significantly complicate IKE state machine (I presume that the initiator would have to be able to restart any exchange if it received puzzle). On the other hand, after the IKE SA is established the host has various means to deal with nefarious peer. Some of them are listed in the draft, such as TEMPORARY_FAILURE and NO_ADDITIONAL_SAS notifications, artificial delays, limiting IKE window size to 1 etc. Regards, Valery. > #230: Use puzzles for DoS protection within an IKE SA > > Earlier versions of the draft did not cover DoS by an authenticated > client. With the approval of NULL-auth, the fact that a peer has a valid > IKE SA is less of an indication that it is not an attacker. > > At IETF 92 the question was asked if we wanted to use puzzles within > encrypted IKE, so that a peer with an IKE SA is not able to needlessly > rekey a child SA (with PFS), flood the responder with liveness checks, or > do other kinds of nefarious IKE. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-ipsecme-ddos- > ynir.ietf@gmail.com | protection@tools.ietf.org > Type: enhancement | Status: new > Priority: normal | Milestone: > Component: ddos- | Severity: Active WG Document > protection | > Keywords: | > -------------------------+------------------------------------------------- > > Ticket URL: > ipsecme > From nobody Tue Apr 14 05:52: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 EBC271A905C for ; Tue, 14 Apr 2015 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 mtJGlUPqoBSe for ; Tue, 14 Apr 2015 05:52:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 E82C01A905A for ; Tue, 14 Apr 2015 05:52:51 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t3ECqkjm000457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Apr 2015 15:52:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t3ECqj3s000391; Tue, 14 Apr 2015 15:52:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21805.3485.651433.532036@fireball.kivinen.iki.fi> Date: Tue, 14 Apr 2015 15:52:45 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <020FB07F2D6E4240BC82077777117CE8@buildpc> References: <020FB07F2D6E4240BC82077777117CE8@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 11 min Archived-At: Cc: ipsec@ietf.org, ynir.ietf@gmail.com Subject: [IPsec] Fw: [ipsecme] #229 (ddos-protection): Need to decide the nature of the puzzle 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, 14 Apr 2015 12:52:54 -0000 Valery Smyslov writes: > Of course, for any given initiator it will be a lottery and > sometimes powerfull attacker will receive easy puzzle and sometimes > weak legacy initiator will receive difficult puzzle. I think that is actually wrong way of thinking this. There are no easy or hard puzzles, all the puzzles are equal hard. You have to find key that generates that number of zero bits in end. You can whatever method to go through keys. If someone starts from key 0x00...00 and counts up he might need to count n numbers. If someone starts from 0xff..ff and counts down he might find suitable key on first try for the exactly same puzzle. I.e. the puzzles are of same difficulty, the issue is that one solving the puzzle might be lucky or not and thats why time to solve a puzzle is different for different puzzles. Time to solve a puzzle is also different if different methods of enumerating keys are used. > So the conclusion - I don't think we should change puzzle definition so > that it becomes close to constant-time giving the little value that it would > give us (taking into consideration the vast diversity of clients) > and the complexity it would involve and the increasing of the size of IKE > messages. I agree. If we make the time constant, then we will with 100% propability lock out weak clients, as strong attackers can always solve puzzles faster, so we need to add randomess in the queue system. Now when we alredy have randomess in the solving time, the weak client might get lucky and manage to find suitable solution to puzzle on first try, so we already have randomness needed to allow weak clients to get in if they try long enough. -- kivinen@iki.fi From nobody Wed Apr 15 00:48:22 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 2B8781B3255 for ; Wed, 15 Apr 2015 00:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.509 X-Spam-Level: ** X-Spam-Status: No, score=2.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 vqAfGuwmAwJt for ; Wed, 15 Apr 2015 00:48:20 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA471B3272 for ; Wed, 15 Apr 2015 00:48:20 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so27412151lbb.2 for ; Wed, 15 Apr 2015 00:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=t/9gU1dp9GtNFMqr9lHIoozcFiQBD0Ogx6kJpzWLAwk=; b=qGXhPgdIJJ0BJL7/or7oMcfBly1oCk0jTwEFDtx2AjXTcqCLtcaji5R54APazhTHK4 4szCwzp8H6W+MieIDSJuV+CJYNrTjxdRqFWcMYSosEfAeqwtzWw/XgNKH6DJamcvuJu9 Rri0vLGhIA8+wIkTMPR0oQuWasEKHZO14m8Zrr+TH8/R0DXJkRwwl/R/ysMD99PzBkIz 1Yt/Xt6C2Hx2ol3O8OeYGd8tmp48vfSWKskAH9gb/7H66SEJ+tNhPsF09FLsY40qRM8u i3Y2DniA1SHZe2bAVGS4dcWditKJMFXGGjbOhEmhgGIA/xsZac/ioqKj/YfKgf4NaP9z /HUQ== X-Received: by 10.112.54.165 with SMTP id k5mr22696011lbp.57.1429084098779; Wed, 15 Apr 2015 00:48:18 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id xg4sm761525lac.0.2015.04.15.00.48.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 15 Apr 2015 00:48:18 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , "IETF IPsec" References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> <82E3B176-6865-4137-859D-CFD36FDB030F@gmail.com> Date: Wed, 15 Apr 2015 10:48:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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] Two questions aboutdraft-ietf-ipsecme-chacha20-poly1305-00 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, 15 Apr 2015 07:48:22 -0000 Hi, >> On Mar 30, 2015, at 5:39 PM, Yoav Nir wrote: >> >> Hi, >> >> There is two questions I would like guidance from the group about. >> >> First is the nonce/IV question: In the current draft, there is a 64-bit >> IV with guidance not to repeat them (so use a counter or LFSR). The >> function itself accepts a 96-bit input nonce, so the nonce is constructed >> from the 64-bit IV and 32 zero bits. The reason for doing this is so the >> algorithm could be used in a multi-sender case such as GDOI, where the >> 32-bit zero can be replaced by a sender ID. Alternatively, we could >> generate a 32-bit salt value from the key material, but I don’t see a >> reason why we’d want that. Another thing we could do is what some people >> are advocating for TLS: Since a counter is a fine IV (no need for >> secrecy), we don’t need a 64-bit IV that has the exact same value as the >> replay counter. We might as well save 8 bytes per packet and just feed >> the replay counter to the function. The argument against this is that >> some crypto modules may have the API set up in such a way that the IVs >> are generated within the module and could be something other than a >> counter (like an LFSR). The proposal will break such APIs. First, the third option is absolutely inappropriate. The draft suggests using Chacha+Poly for both ESP and IKE and in case of IKE there are no replay counter that is unique in the context of IKE SA. Message ID in IKE header _is_not_ unique - it can be repeated at least in two cases: RFC6311 and RFC7383. So, the IKE Message ID is allowed to repeat and these repetitions would be fatal for security. Among the first two options I prefer the AES-GCM-like approach - taking the needed 32 bits from the keying material. >> Second issue is about UI advice. Some implementations (yes, mine is >> included) allow the user to configure encryption algorithm, MAC >> algorithm, and D-H group. There is no setting for PRF since such UIs date >> back to IKEv1. The PRF is usually just taken from the setting for MAC >> algorithm. This works fine as long as all supported MAC algorithms are >> HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC 5282 >> makes no mention of this issue. I’m wondering if we should recommend to >> pair this algorithm in IKE with PRF_HMAC_SHA2_256. I think UI issues are out of scope of this draft. The draft should make no recommendations of what PRF should be used (at least it should not make such recommendations with RFC2119 keywords). Regards, Valery. >> >> Thanks >> >> Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Apr 20 08:16: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 CDD951B2EBF; Mon, 20 Apr 2015 08:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8rRWwCHOIj1u; Mon, 20 Apr 2015 08:16:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 202C11A7D80; Mon, 20 Apr 2015 08:16:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420151641.28943.75065.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 08:16:41 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-06.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, 20 Apr 2015 15:16:43 -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 : The NULL Authentication Method in IKEv2 Protocol Authors : Valery Smyslov Paul Wouters Filename : draft-ietf-ipsecme-ikev2-null-auth-06.txt Pages : 14 Date : 2015-04-20 Abstract: This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-06 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 Apr 20 08:23:21 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 29C901B2EE1 for ; Mon, 20 Apr 2015 08:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 d3LC3XlbIikm for ; Mon, 20 Apr 2015 08:23:19 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55451B2EDE for ; Mon, 20 Apr 2015 08:23:18 -0700 (PDT) Received: by laat2 with SMTP id t2so129548269laa.1 for ; Mon, 20 Apr 2015 08:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=LoNy8KZyrFCBHFJW4pByPzSxucTufCN80GuEW4SI9/4=; b=oO3fQEgS7gNMABr5TjTlb39NaHqADdoQksVTVmojWlTRgIkC+cboubVFotRk1jW+YE eoH+PxooIGLaOZeUORxOLOfuqdptGTF5t+odDnEwLMjzEyYnvnwdN1BamhqR9ELEdltX 9maBBJanChfqIGKufU4tF6hu9llSx4+40iZ9TfPlG7v/2gTzgrPPt+PnqLt0KocbUnMj tChbOMsH/39kBJ8i85asHbt/r7H0/ma8OhhT0dDtjNGfZtRJ5/9VGQgmuH+ojEMb1x7S A11vIZjEDr8GY0cbujzwBoVL0rEks8kl0uhCk7lY0KFrldvIJTtktVBqJm4KAUNrVYR4 su0Q== X-Received: by 10.112.234.163 with SMTP id uf3mr16363367lbc.9.1429543397247; Mon, 20 Apr 2015 08:23:17 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id r13sm809121lal.21.2015.04.20.08.23.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 20 Apr 2015 08:23:16 -0700 (PDT) Message-ID: <4363402748C6482C913A6B0E074943CE@buildpc> From: "Valery Smyslov" To: "IETF IPsec" Date: Mon, 20 Apr 2015 18:23:13 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: [IPsec] Fw: New Version Notification for draft-ietf-ipsecme-ikev2-null-auth-06.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, 20 Apr 2015 15:23:20 -0000 Hi all, a new version of the draft is published. It now updates RFC4301 and it contains the specific changes of PAD processing text that should be followed if NULL Authenticated is supported. Regards, Valery & Paul. > A new version of I-D, draft-ietf-ipsecme-ikev2-null-auth-06.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-ietf-ipsecme-ikev2-null-auth > Revision: 06 > Title: The NULL Authentication Method in IKEv2 Protocol > Document date: 2015-04-20 > Group: ipsecme > Pages: 14 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-null-auth-06.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ > Htmlized: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-06 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-06 > > Abstract: > This document specifies the NULL Authentication method and the > ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This > allows two IKE peers to establish single-side authenticated or mutual > unauthenticated IKE sessions for those use cases where a peer is > unwilling or unable to authenticate or identify itself. This ensures > IKEv2 can be used for Opportunistic Security (also known as > Opportunistic Encryption) to defend against Pervasive Monitoring > attacks without the need to sacrifice anonymity. > > > > > 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. > > The IETF Secretariat > From nobody Mon Apr 20 08:40:51 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 3E2FE1A032D for ; Mon, 20 Apr 2015 08:40:49 -0700 (PDT) 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 k7oaaVGlInw5 for ; Mon, 20 Apr 2015 08:40:47 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 AE7A11B2B9D for ; Mon, 20 Apr 2015 08:40:46 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so133859478lbb.0 for ; Mon, 20 Apr 2015 08:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iK7zIBUiABENFMO430S0t45eWAFxtsUsIfQBAiNXTFU=; b=KLOsprwTy6dXzXanVLIYd+zhyVkUFZnCZu4eCQIxKabULZxuN3GuOLAjvswyFAkaQ5 JntDd5tTa0AOwBrqIJBSqr5BtilUI3Je2tA8dch6peWUc8L3LJzbrTAGl6YNyPSyHaJb I0CnN2y93301zmaOEl+x+Q/1M9lrnfrFkX6kfg8IWe5rbMQ8oW17Ox6ztjz3f8w+VGGs o+h9bCYasfbJ0XIfVgQK3xftsgWzLWV6l0uiWFFvanvFVfbdfQd2lXzNJdBQ6JRn9S/Z 3cGKmWYSIwNm6aFekSao9sa7qTarF6UkAxDNJmvEkNssE8aIm/B5u2aIKLEJp3E1iCUM 02JA== MIME-Version: 1.0 X-Received: by 10.152.204.40 with SMTP id kv8mr16028688lac.113.1429544445230; Mon, 20 Apr 2015 08:40:45 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Mon, 20 Apr 2015 08:40:45 -0700 (PDT) In-Reply-To: <4363402748C6482C913A6B0E074943CE@buildpc> References: <4363402748C6482C913A6B0E074943CE@buildpc> Date: Mon, 20 Apr 2015 11:40:45 -0400 Message-ID: From: Kathleen Moriarty To: Valery Smyslov Content-Type: multipart/alternative; boundary=001a11347da6d94351051429c0f0 Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Fw: New Version Notification for draft-ietf-ipsecme-ikev2-null-auth-06.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, 20 Apr 2015 15:40:49 -0000 --001a11347da6d94351051429c0f0 Content-Type: text/plain; charset=UTF-8 Hi Valery, Thank you for the updates, this looks much better. I'll kick off IETF last call and if there are comments from the WG members on these updates, please post them to the list. Best regards, Kathleen On Mon, Apr 20, 2015 at 11:23 AM, Valery Smyslov wrote: > Hi all, > > a new version of the draft is published. > It now updates RFC4301 and it contains the specific changes of PAD > processing text that should be followed if NULL Authenticated is supported. > > Regards, > Valery & Paul. > > > A new version of I-D, draft-ietf-ipsecme-ikev2-null-auth-06.txt >> has been successfully submitted by Valery Smyslov and posted to the >> IETF repository. >> >> Name: draft-ietf-ipsecme-ikev2-null-auth >> Revision: 06 >> Title: The NULL Authentication Method in IKEv2 Protocol >> Document date: 2015-04-20 >> Group: ipsecme >> Pages: 14 >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-null-auth-06.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ >> Htmlized: >> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-06 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-06 >> >> Abstract: >> This document specifies the NULL Authentication method and the >> ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This >> allows two IKE peers to establish single-side authenticated or mutual >> unauthenticated IKE sessions for those use cases where a peer is >> unwilling or unable to authenticate or identify itself. This ensures >> IKEv2 can be used for Opportunistic Security (also known as >> Opportunistic Encryption) to defend against Pervasive Monitoring >> attacks without the need to sacrifice anonymity. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Best regards, Kathleen --001a11347da6d94351051429c0f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Valery,

Thank you for the updates, t= his looks much better.=C2=A0 I'll kick off IETF last call and if there = are comments from the WG members on these updates, please post them to the = list.

Best regards,
Kathleen
=

On Mon, Apr 20, 2= 015 at 11:23 AM, Valery Smyslov <svanru@gmail.com> wrote:
=
Hi all,

a new version of the draft is published.
It now updates RFC4301 and it contains the specific changes of PAD
processing text that should be followed if NULL Authenticated is supported.=

Regards,
Valery & Paul.


A new version of I-D, draft-ietf-ipsecme-ikev2-null-auth-06.txt
has been successfully submitted by Valery Smyslov and posted to the
IETF repository.

Name: draft-ietf-ipsecme-ikev2-null-auth
Revision: 06
Title: The NULL Authentication Method in IKEv2 Protocol
Document date: 2015-04-20
Group: ipsecme
Pages: 14
URL: http://www.ietf.org/internet-drafts/d= raft-ietf-ipsecme-ikev2-null-auth-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf= -ipsecme-ikev2-null-auth/
Htmlized: http://tools.ietf.org/html/draft-ietf-ipsecme= -ikev2-null-auth-06
Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-ipsecme-ikev2-null-auth-06

Abstract:
=C2=A0 This document specifies the NULL Authentication method and the
=C2=A0 ID_NULL Identification Payload ID Type for the IKEv2 Protocol.=C2=A0= This
=C2=A0 allows two IKE peers to establish single-side authenticated or mutua= l
=C2=A0 unauthenticated IKE sessions for those use cases where a peer is
=C2=A0 unwilling or unable to authenticate or identify itself.=C2=A0 This e= nsures
=C2=A0 IKEv2 can be used for Opportunistic Security (also known as
=C2=A0 Opportunistic Encryption) to defend against Pervasive Monitoring
=C2=A0 attacks without the need to sacrifice anonymity.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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



--

Best regards,
Kath= leen
--001a11347da6d94351051429c0f0-- From nobody Mon Apr 20 08:51: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 EA66C1B2EB3; Mon, 20 Apr 2015 08:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 QVivwq__ybsE; Mon, 20 Apr 2015 08:51:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 937F31B2E6A; Mon, 20 Apr 2015 08:51:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150420155129.16398.92967.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 08:51:29 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (The NULL Authentication Method in IKEv2 Protocol) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:51:31 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'The NULL Authentication Method in IKEv2 Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 21 09:19: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 EBCF61AD06B for ; Tue, 21 Apr 2015 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 1BJf8RSZVlSY for ; Tue, 21 Apr 2015 09:19:44 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EDB1AD069 for ; Tue, 21 Apr 2015 09:19:44 -0700 (PDT) Received: by lagv1 with SMTP id v1so155181727lag.3 for ; Tue, 21 Apr 2015 09:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=dupyvmM56xkqftjiM2IDvSG8avdKV07qDuzlvTKlfik=; b=y165wH+rtrglIcoFBHH2T/MA3hCpfPWGjSH0xUpRTfYuv/WAK3TtNooH9G/DIwxqkd 5PZ8tVDd3CoUvB24tHB2SufnUW3Kf7ahiXrOeeb1jZs/WxL5K/lKTlRjBjEhAyNcIGXs TIeJFOziOlL3WB1fjuOv+WWGnoWreNvhb1DP0nNIOIpJk2NkQgJjFPnSSGNMITtsa0wz 3sJHLfna3jEpvq49hhBJHthHw/pqM0cWueHiq2Hwv7OISUEU9nhbf1L21lqE9EVSGFyD g1WnvO3ka4PnXh1qXRoQ8SzfcC+mVmS/ngFdBNpSuaCzSm2caDrg2rRT0eAQV1TCSZYi N1Fw== X-Received: by 10.112.170.166 with SMTP id an6mr9859735lbc.118.1429633182607; Tue, 21 Apr 2015 09:19:42 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id x2sm509182laj.8.2015.04.21.09.19.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 Apr 2015 09:19:41 -0700 (PDT) Message-ID: <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> From: "Valery Smyslov" To: "IPsecME WG" References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> Date: Tue, 21 Apr 2015 19:19:39 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 21 Apr 2015 16:19:46 -0000 Hi, this is my review of draft-ietf-ipsecme-chacha20-poly1305-02. I think that the draft is in a good shape. A few issues need to be resolved. Technical issues. 1. For the question raised in the draft: TBD: do we want an extra 32 bits as salt for the nonce like in GCM, or keep the salt (=SenderID) at zero? I prefer to follow GCM-like approach, i.e. to take these 32 bits from the KEYMAT. It is cryptographically sound and is good from evaluation point of view - you know where these bits come from. I understand that it would require some adaptation for multi-sender case, like in RFC6054, but AFAIK currently Many-to-Many IPsec SAs are rare and look exotic. And as RFC6054 states, the nonce is not transferred in packet, so it is not the best place for SenderID (unlike explicit IV). 2. Section 4. When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or IPsec, the value xxx (TBA by IANA) should be used in the transform substructure of the SA payload as the ENCR (type 1) transform ID. As with other AEAD algorithms, INTEG (type 3) transform substructures SHOULD NOT be specified unless at least one of the ENCR transforms is non-AEAD. The last sentence is wrong. Section 3.3 of RFC7296 states: Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and MUST either offer no integrity algorithm or a single integrity algorithm of "NONE", with no integrity algorithm being the RECOMMENDED method. So INTEG either MUST NOT be present in the proposal substructure containing ChaCha20-Poly1305 or MUST be NONE. And RFC7296 requires not to mix AEAD and non-AEAD algorithms in the same proposal: If an initiator wants to propose both combined- mode ciphers and normal ciphers, it must include two proposals: one will have all the combined-mode ciphers, and the other will have all the normal ciphers with the integrity algorithms. Editorial issues. 1. Section 2, first bullet. o The Initialization Vector (IV) is 64-bit, and is used as part of the nonce. The IV MUST be unique for each SA but does not need to be unpredictable. The use of a counter or an LFSR is RECOMMENDED. The IV MUST be unique for each invocation (ESP packet or IKEv2 message), not for each SA. 2. Section 2, last but one bullet: * The length of the additional data in octets (as a 64-bit little-endian integer). "additional data" is a bit vague, please use "Authenticated Additional Data" (or "AAD") for clarity. 3. Informative References [FIPS-46] National Institute of Standards and Technology, "Data Encryption Standard", FIPS PUB 46-2, December 1993, . The url is incorrect, it leads to the NIST home page. I believe the correct url is http://csrc.nist.gov/publications/fips/archive/fips46-3/fips46-3.pdf (and it is FIPS 46-3, that superceeded FIPS 46-2). Minor nits (subjective). 1. Section 1. I think the main problem with 3DES is not that it is significantly slower than AES, but that it has blocksize of 64 bits, that is considered loo small for high-speed networks, when the possibility of birthday attack leads to necessity to frequently rekey. 2. Section 2. >From the description of how ESP packet is constructed it is not absolutely clear what parts of the nonce are explicitely included in the packet, and what aren't. I guess it is 64 bit IV that is included and the higher 32 bits (SenderID) - that aren't, but it is not explicitely stated. I'd prefer to it to be spelled out. 3. Section 3. The last sentence is too long and refers to different sections in different documents (this draft and RFC5282). That makes it a bit difficult to follow. Could you, please, split it into several shorter sentences. 4. Section 5. The terms "64-bit cipher", "128-bit cipher" and "256-bit cipher" look like a jargon (and could be mixed up with key length by naive reader). I'd prefer to use "block cipher with 64-bit block" etc. 5. Section 6. I think it is worth to instruct IANA that tis document must be referenced in both ESP and IKEv2 columns of IANA registry. However it is not strictly necessary since IANA will ask this question anyway. Regards, Valery Smyslov. From nobody Tue Apr 21 12:22:00 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 150EC1B2A88 for ; Tue, 21 Apr 2015 12:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 roSH3L7CswKG for ; Tue, 21 Apr 2015 12:21:58 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 4FB301B2A80 for ; Tue, 21 Apr 2015 12:21:49 -0700 (PDT) Received: by widdi4 with SMTP id di4so151474718wid.0 for ; Tue, 21 Apr 2015 12:21:48 -0700 (PDT) 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=1T8I86HJZjaBF3uSVugMEqmDW58z79alJkjK3B81gaQ=; b=NT7CqPTJR0cN//FbICie6PH/VDmkMMeIPHGxSlB9FuxhFGD2NbhL5+zFRUOkFNTWcC WN3if6iOcAsmy/OOb/1zPprmzw8xHnOUVwOxoiW64SUVM8Vbi4DDpB91N10Ws6VQI3SE c49l0K5/2MLSK5K6g8jZSe6Kc7U6GGb2kXELOMO8tZ295mpmz4DorUJLO1gmMArbRD+Q Mm+kvIDJkIMqJp8/zUj7c/wy0IQdqffIzDOFhw/8gXntV/H3hck8lpfma5wylxJ4z+Sl tzlIrft5fmU0vhbUb5PYOHkPA6gB7sKpkyJ4l0HxkUJRdSL98b58TGt30/fpSjyGyZkV 1LPw== X-Received: by 10.194.59.199 with SMTP id b7mr44481088wjr.26.1429644108015; Tue, 21 Apr 2015 12:21:48 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id l10sm3923120wje.15.2015.04.21.12.21.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Apr 2015 12:21:46 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=windows-1252 From: Yoav Nir X-Priority: 3 In-Reply-To: <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> Date: Tue, 21 Apr 2015 22:21:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <818C9ECF-3EE7-4804-B0BB-A3E802230751@gmail.com> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 21 Apr 2015 19:22:00 -0000 Hi, Valery. Thanks for the review. See my reply inline. > On Apr 21, 2015, at 7:19 PM, Valery Smyslov wrote: >=20 > Hi, >=20 > this is my review of draft-ietf-ipsecme-chacha20-poly1305-02. >=20 > I think that the draft is in a good shape. A few issues need to be = resolved. >=20 >=20 >=20 > Technical issues. >=20 > 1. For the question raised in the draft: >=20 > TBD: do we want an extra 32 bits as salt for the nonce like > in GCM, or keep the salt (=3DSenderID) at zero? >=20 > I prefer to follow GCM-like approach, i.e. to take these 32 bits > from the KEYMAT. It is cryptographically sound and is good > from evaluation point of view - you know where these bits come from. I thought so as well. In the meantime, the TLS working group is = discussing the same thing for TLS 1.3, and they are proposing to get rid = of the salt (or IV) for AES-GCM as well as ChaCha20.=20 http://www.ietf.org/mail-archive/web/tls/current/msg15884.html The TLS working group is not making decisions for us, but I think it = would be a shame to arrive at different conclusions where the cases are = very similar. More technically, I use a single crypto library for both = TLS and IPsec, and having a =93salt" parameter that is always set to = zero for TLS makes me sad. > I understand that it would require some adaptation > for multi-sender case, like in RFC6054, but AFAIK currently > Many-to-Many IPsec SAs are rare and look exotic. > And as RFC6054 states, the nonce is not transferred in packet, > so it is not the best place for SenderID (unlike explicit IV). As RFC 6045 says in section 3, the sender ID is carved out of the = explicit IV, not out of the invisible salt. So that part of my question = made no sense anyway. We either want the salt to protect against = something, or we don=92t. It=92s not reserved for sender ID. > 2. Section 4. >=20 > When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or > IPsec, the value xxx (TBA by IANA) should be used in the transform > substructure of the SA payload as the ENCR (type 1) transform ID. As > with other AEAD algorithms, INTEG (type 3) transform substructures > SHOULD NOT be specified unless at least one of the ENCR transforms is > non-AEAD. >=20 > The last sentence is wrong. Section 3.3 of RFC7296 states: >=20 > Combined-mode ciphers include > both integrity and encryption in a single encryption algorithm, and > MUST either offer no integrity algorithm or a single integrity > algorithm of "NONE", with no integrity algorithm being the > RECOMMENDED method. >=20 > So INTEG either MUST NOT be present in the proposal substructure > containing ChaCha20-Poly1305 or MUST be NONE. And RFC7296 > requires not to mix AEAD and non-AEAD algorithms in the same proposal: >=20 > If an initiator wants to propose both combined- > mode ciphers and normal ciphers, it must include two proposals: one > will have all the combined-mode ciphers, and the other will have all > the normal ciphers with the integrity algorithms. Thanks. I forgot about this restriction. Will fix in the next draft. >=20 > Editorial issues. >=20 > 1. Section 2, first bullet. >=20 > o The Initialization Vector (IV) is 64-bit, and is used as part of > the nonce. The IV MUST be unique for each SA but does not need to > be unpredictable. The use of a counter or an LFSR is RECOMMENDED. >=20 > The IV MUST be unique for each invocation (ESP packet or IKEv2 = message), > not for each SA. Unique for each invocation *with the same key, no? And keys are = different from one SA to another. > 2. Section 2, last but one bullet: >=20 > * The length of the additional data in octets (as a 64-bit > little-endian integer). >=20 > "additional data" is a bit vague, please use "Authenticated Additional = Data" > (or "AAD") for clarity. OK. > 3. Informative References >=20 > [FIPS-46] National Institute of Standards and Technology, "Data > Encryption Standard", FIPS PUB 46-2, December 1993, > . >=20 > The url is incorrect, it leads to the NIST home page. > I believe the correct url is > http://csrc.nist.gov/publications/fips/archive/fips46-3/fips46-3.pdf > (and it is FIPS 46-3, that superceeded FIPS 46-2). It worked when I first wrote the draft. Will fix. >=20 > Minor nits (subjective). >=20 > 1. Section 1. >=20 > I think the main problem with 3DES is not that it is significantly = slower > than AES, but that it has blocksize of 64 bits, that is considered > loo small for high-speed networks, when the possibility of birthday = attack > leads to necessity to frequently rekey. It=92s hard to make that case. The blocksize is 64 bits. So it=92s = prudent to not use more than, say, a billion blocks. A billion blocks is = 64 Gb. There are very few real tunnels that run that kind of throughput = in under a minute. OTOH it=92s no problem at all to run a CreateChildSA = every minute, or even every five seconds. So I think there are very few = cases that *can=92t* use 3DES. > 2. Section 2. >=20 > =46rom the description of how ESP packet is constructed it is not > absolutely clear what parts of the nonce are explicitely included in > the packet, and what aren't. I guess it is 64 bit IV that is included > and the higher 32 bits (SenderID) - that aren't, but it is not = explicitely > stated. I'd prefer to it to be spelled out. OK. I=92ll fix that when we decide what to do with the salt. > 3. Section 3. >=20 > The last sentence is too long and refers to different sections in = different > documents (this draft and RFC5282). That makes it a bit difficult to = follow. > Could you, please, split it into several shorter sentences. I guess I can split that. > 4. Section 5. >=20 > The terms "64-bit cipher", "128-bit cipher" and "256-bit cipher" > look like a jargon (and could be mixed up with key length by naive = reader). > I'd prefer to use "block cipher with 64-bit block" etc. I think I=92ll just drop everything after "Counters and LFSRs are both = acceptable ways of generating unique nonces.=94 Encrypting counters gets = the job done, but is a very inefficient way of generating unique IV. = Especially if it means bringing DES into the mix. > 5. Section 6. >=20 > I think it is worth to instruct IANA that tis document must be = referenced > in both ESP and IKEv2 columns of IANA registry. > However it is not strictly necessary since IANA will ask this question = anyway. OK. Yoav= From nobody Wed Apr 22 01:39: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 B26701B2DDC for ; Wed, 22 Apr 2015 01:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] 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 QdOwbyW25BJw for ; Wed, 22 Apr 2015 01:39:32 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010: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 93B471B2FCC for ; Wed, 22 Apr 2015 01:39:22 -0700 (PDT) Received: by layy10 with SMTP id y10so169373115lay.0 for ; Wed, 22 Apr 2015 01:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=ukRfMZU/W5iBxm1PG+R9RxtR9UbMLczZvP8+EyrmLBc=; b=hkxR54ZjP+6LN/5+V488sxuI4dRXinenAxpVYiTalVErAcHZ/Jkcq1xeJpIxa5prqx rRNukHxu4BL5X5Ro2kvyIzvLCMI5n/r6OmOtiDCB2+BH2DyyT6JItcwp1rlms7ltFwIp BJoh/06cr0zfMng2rvefm+e3PGZrktkNzRgGOgTHekR9bN4b00L6j+mXNTeeyTnV8ULu tev3Vqn5JHbNYZ4Yw68dy8g3D/lgnOs3Xl/UyFuoYLhEl8AUf8f+2zCkYV8gh//pZHME uKCzGFS69CIXRpFpWFXQakpV/vMRsmx5GeQ4jpFpPu9SZXKdEbKAsf7ICz8Hn6ANysOf 4UoA== X-Received: by 10.112.139.1 with SMTP id qu1mr23746517lbb.8.1429691961020; Wed, 22 Apr 2015 01:39:21 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id at2sm976869lbc.12.2015.04.22.01.39.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Apr 2015 01:39:20 -0700 (PDT) Message-ID: <7619B0FCC67A43ACB52141E63B65C1B9@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <818C9ECF-3EE7-4804-B0BB-A3E802230751@gmail.com> Date: Wed, 22 Apr 2015 11:39:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 22 Apr 2015 08:39:33 -0000 Hi Yoav, > Hi, Valery. > > Thanks for the review. See my reply inline. > > >> Technical issues. >> >> 1. For the question raised in the draft: >> >> TBD: do we want an extra 32 bits as salt for the nonce like >> in GCM, or keep the salt (=SenderID) at zero? >> >> I prefer to follow GCM-like approach, i.e. to take these 32 bits >> from the KEYMAT. It is cryptographically sound and is good >> from evaluation point of view - you know where these bits come from. > > I thought so as well. In the meantime, the TLS working group is discussing > the same thing for TLS 1.3, and they are proposing to get rid of the salt > (or IV) for AES-GCM as well as ChaCha20. > > http://www.ietf.org/mail-archive/web/tls/current/msg15884.html AFAIK they are discussing the possibility to get rid of explicit IV at all and to use record number for that purpose. I don't think it will work in our case. More precisely it could work for ESP, where sequence numbers are unique, but it won't work for IKEv2, since Message ID is not unique and can repeat (in cases of cluster synchronization or IKE Fragmentation). So either we need to define two different mechnisms (implicit IV for ESP and explicit IV for IKE) or always use explicit IV. > The TLS working group is not making decisions for us, but I think it would > be a shame > to arrive at different conclusions where the cases are very similar. More > technically, > I use a single crypto library for both TLS and IPsec, and having a “salt" > parameter > that is always set to zero for TLS makes me sad. I agree that it is better to have a single mechanism for TLS and IPsec. However I doubt if TLS WG would take into considerations our problems, when making its own decision. On the other hand I think that implicit IV is unacceptable for us (at least for IKE). >> I understand that it would require some adaptation >> for multi-sender case, like in RFC6054, but AFAIK currently >> Many-to-Many IPsec SAs are rare and look exotic. >> And as RFC6054 states, the nonce is not transferred in packet, >> so it is not the best place for SenderID (unlike explicit IV). > > As RFC 6045 says in section 3, the sender ID is carved out of the explicit > IV, > not out of the invisible salt. So that part of my question made no sense > anyway. > We either want the salt to protect against something, or we don’t. It’s > not reserved for sender ID. Then, I think, it's better to use the salt as a salt, than not to use it :-) >> Editorial issues. >> >> 1. Section 2, first bullet. >> >> o The Initialization Vector (IV) is 64-bit, and is used as part of >> the nonce. The IV MUST be unique for each SA but does not need to >> be unpredictable. The use of a counter or an LFSR is RECOMMENDED. >> >> The IV MUST be unique for each invocation (ESP packet or IKEv2 message), >> not for each SA. > > Unique for each invocation *with the same key, no? And keys are different > from one SA to another. In its current form the text could be read that the IV is static (unique for each SA, but not changing during the lifetime of SA, so that each message of a particular SA have the same IV). But in fact the IV must be unique for each message encrypted with the same key, so it must change (e.g. incremented) after each use. I just wanted to emphasize that fact and avoid possible readers confusion. >> Minor nits (subjective). >> >> 1. Section 1. >> >> I think the main problem with 3DES is not that it is significantly slower >> than AES, but that it has blocksize of 64 bits, that is considered >> loo small for high-speed networks, when the possibility of birthday >> attack >> leads to necessity to frequently rekey. > > It’s hard to make that case. The blocksize is 64 bits. So it’s prudent to > not use more than, say, a billion blocks. > A billion blocks is 64 Gb. There are very few real tunnels that run that > kind of throughput in under a minute. > OTOH it’s no problem at all to run a CreateChildSA every minute, or even > every five seconds. > So I think there are very few cases that *can’t* use 3DES. Well, I'm not a cryptographer, but I've heard several times that the real problem of 3DES is its short block. And the attacker could precalculate large number of keys, in which case a billion blocks would not be prudent, the safe number could be a million blocks, that is too small even for 1Gb networks. Of course it is possible to rekey every 5 seconds, but it would consume more resourses. Eventually all those frequent rekeys would lead to decreased performance, so your initial idea is correct :-) > Yoav Regards, Valery. From nobody Thu Apr 23 03:44: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 B75AD1ACE57 for ; Thu, 23 Apr 2015 03:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 GXB-g-LHDBST for ; Thu, 23 Apr 2015 03:44:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 7E60B1ACDE8 for ; Thu, 23 Apr 2015 03:44:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t3NAiERZ024115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Apr 2015 13:44:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t3NAiE3m014477; Thu, 23 Apr 2015 13:44:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21816.52477.890081.649693@fireball.kivinen.iki.fi> Date: Thu, 23 Apr 2015 13:44:13 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <7619B0FCC67A43ACB52141E63B65C1B9@buildpc> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <818C9ECF-3EE7-4804-B0BB-A3E802230751@gmail.com> <7619B0FCC67A43ACB52141E63B65C1B9@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 11 min Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 23 Apr 2015 10:44:30 -0000 Valery Smyslov writes: > > I thought so as well. In the meantime, the TLS working group is dis= cussing > > the same thing for TLS 1.3, and they are proposing to get rid of th= e salt > > (or IV) for AES-GCM as well as ChaCha20. > > > > http://www.ietf.org/mail-archive/web/tls/current/msg15884.html >=20 > AFAIK they are discussing the possibility to get rid of explicit IV a= t all > and to use record number for that purpose. I don't think it will work= > in our case. More precisely it could work for ESP, where sequence num= bers > are unique, but it won't work for IKEv2, since Message ID is not uniq= ue > and can repeat (in cases of cluster synchronization or IKE Fragmentat= ion). > So either we need to define two different mechnisms (implicit IV for = ESP > and explicit IV for IKE) or always use explicit IV. What I proposed earlier was that we define that chacha20 uses explicit IV, but the IV is always generated as running counter incremented by one. In normal case the IV is sent inside the both IKEv2 and ESP packets. In ESP the sequence number is used normally for replay protection. Then we could create new "ESP Sequence number + IV compression" protocol, that would negotiate the support for this in the IKEv2 for ESP, and if enabled by both ends, then they would set the ESP sequence number and chacha20 IV to be linked, i.e. they would always be same, and then we could compress one of them away after the encryption, and decompress them back in place before decryption. I.e. the actual packets sent would only have one number, and IV and ESP sequence number would be derived from that before decryption. For IKEv2 we would still use just normal explict IV. This would require us to define chacha20 IV generation so it uses running counter starting from fixed value, but everything else can be done later. > >> 1. Section 1. > >> > >> I think the main problem with 3DES is not that it is significantly= slower > >> than AES, but that it has blocksize of 64 bits, that is considered= > >> loo small for high-speed networks, when the possibility of birthda= y=20 > >> attack > >> leads to necessity to frequently rekey. > > > > It=E2=80=99s hard to make that case. The blocksize is 64 bits. So i= t=E2=80=99s prudent to=20 > > not use more than, say, a billion blocks. > > A billion blocks is 64 Gb. There are very few real tunnels that run= that=20 > > kind of throughput in under a minute. > > OTOH it=E2=80=99s no problem at all to run a CreateChildSA every mi= nute, or even=20 > > every five seconds. > > So I think there are very few cases that *can=E2=80=99t* use 3DES. >=20 > Well, I'm not a cryptographer, but I've heard several times that > the real problem of 3DES is its short block. That is also my understanding, and I would rather use real reason why 3DES cannot be used (short blocksize) than some other random reason (i.e. claiming it to be too slow). If we claim 3DES cannot be used because it is slower than AES, then vendors having separate hardware acceleration for 3DES, but very slow CPU otherwise, could say that they have no reason to implement chacha, as their 3DES acceleration is fast enough. --=20 kivinen@iki.fi From nobody Sat Apr 25 02:10:43 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 D05A81A90CF; Sat, 25 Apr 2015 02:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 zR5YWn9oUFEc; Sat, 25 Apr 2015 02:10:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A43E71A90E1; Sat, 25 Apr 2015 02:10:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> Date: Sat, 25 Apr 2015 02:10:38 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.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: Sat, 25 Apr 2015 09:10:40 -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 : ChaCha20, Poly1305 and their use in IKE & IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-03.txt Pages : 7 Date : 2015-04-25 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange protocol (IKEv2) and for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 25 02:25: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 668221B2BC9; Sat, 25 Apr 2015 02:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 UMouITW83qKg; Sat, 25 Apr 2015 02:25:06 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 057C61B2BCF; Sat, 25 Apr 2015 02:25:06 -0700 (PDT) Received: by wizk4 with SMTP id k4so47427156wiz.1; Sat, 25 Apr 2015 02:25:03 -0700 (PDT) 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=lJlHwu3BT5oSbJEKbhUik8HlPvmlmD1DSnMRHxpQtAU=; b=C43u03C90crg3xuaACuV/29koy3ITt1anLB9dqcZldVhH0h1ebNlcY9O4QJvcXiFXU vfkDv19c87BxjCgXeaL20EfNkvt1HwOknSQnNY+GoUhpGkcEq+V88kEnOuNTKX2ptwvv tg4HLUBSlWRwUMpPZr624Pp5zQ784EBl4EXK+8pEPWsM+lzeK2p9D1kKjA6De/Cnjg1X 968IAwfiM36igHmtGOu8hKP4bwl7ze6da9OoeT+dwqeDOQQKHGFMBUc8gROWFYp2hmYU 8mNrRZf3EDxH4+Vpz9Zn2Cc4di92H5aK4FcT4hL29ST4Qn+axott/DEegxZvOdIDSnlh bOUQ== X-Received: by 10.180.92.161 with SMTP id cn1mr3871651wib.91.1429953903643; Sat, 25 Apr 2015 02:25:03 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id pm1sm2012642wjb.23.2015.04.25.02.25.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 02:25:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> Date: Sat, 25 Apr 2015 12:25:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <99449AC5-968B-470D-8386-068EC71C3F35@gmail.com> References: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ipsec@ietf.org, i-d-announce@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.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: Sat, 25 Apr 2015 09:25:08 -0000 Hi This new version closes (I think) all the open issues. I have removed = all references to GDOI as it has been pointed out that GDOI allocated = sender-ID bits from the visible IV, not the invisible salt. I have = replaced all places where it said =E2=80=9Csender ID=E2=80=9D with = =E2=80=9CSalt=E2=80=9D. I have made the salt generated from the keymat = just as it is for AES-GCM. The TLS working group has moved in a whole = other direction ([1]) where they will generate a 96-bit value and XOR = that with the record counter to produce the nonce. We can=E2=80=99t do = that without revising ESP, so for this document I=E2=80=99ll just leave = it at that. With this I believe the document is ready for WGLC. I might want to add = an appendix with an example. Yoav > On Apr 25, 2015, at 12:10 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IKE & = IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-03.txt > Pages : 7 > Date : 2015-04-25 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > the Internet Key Exchange protocol (IKEv2) and for IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-03= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Apr 25 02:27:08 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 2103A1A89C5 for ; Sat, 25 Apr 2015 02:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 PtmuJ70wpJYt for ; Sat, 25 Apr 2015 02:27:05 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 2B5B01B2BC9 for ; Sat, 25 Apr 2015 02:27:05 -0700 (PDT) Received: by wgso17 with SMTP id o17so72339470wgs.1 for ; Sat, 25 Apr 2015 02:27:03 -0700 (PDT) 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=yKQAjABI7Q4itCG1bWyLDIJx0Kqec3jpJTCc/F6b3gE=; b=PRHdEUnRcbxLKL+ckVXCOdZpdT7XCMEF6VUswg6eoAiisPJVoJXPF826GftTDAh/DF vtk7Q0asLXXzXkl3IoG9n+AdlYkZK+573t5jL+dpmKmAVstuwo+Wu08ZWnO9gndo9egO TcTvESQh9L1I7JmydF17dE10p7F7GT7lUFDIKxRaDieiHsmpZ149jA4oUNqq5ir9bBS2 jmX7kUbZqgffCy1ZBshbJbWeq5DgV80qOa4KjTPZMohR7n+9TIKLuyUvKuWIjpRL+d2Q BIMpUGfGoR8UKGyWt/EYGJWG9G6FHEZfxkHer+78MXuFlZUob5FcU0kevy4hyCkgvwFr QxNw== X-Received: by 10.180.104.4 with SMTP id ga4mr4064108wib.86.1429954023896; Sat, 25 Apr 2015 02:27:03 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id e2sm20312242wjy.46.2015.04.25.02.27.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 02:27:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <99449AC5-968B-470D-8386-068EC71C3F35@gmail.com> Date: Sat, 25 Apr 2015 12:27:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A8CCD2B-4290-4889-805E-3DE5ED7A6489@gmail.com> References: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> <99449AC5-968B-470D-8386-068EC71C3F35@gmail.com> To: ipsec X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.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: Sat, 25 Apr 2015 09:27:07 -0000 Replying to myself to prevent others from sending messages to the = internet-drafts and i-d-announce. On Apr 25, 2015, at 12:25 PM, Yoav Nir wrote: Hi This new version closes (I think) all the open issues. I have removed = all references to GDOI as it has been pointed out that GDOI allocated = sender-ID bits from the visible IV, not the invisible salt. I have = replaced all places where it said =E2=80=9Csender ID=E2=80=9D with = =E2=80=9CSalt=E2=80=9D. I have made the salt generated from the keymat = just as it is for AES-GCM. The TLS working group has moved in a whole = other direction ([1]) where they will generate a 96-bit value and XOR = that with the record counter to produce the nonce. We can=E2=80=99t do = that without revising ESP, so for this document I=E2=80=99ll just leave = it at that. With this I believe the document is ready for WGLC. I might want to add = an appendix with an example. Yoav > On Apr 25, 2015, at 12:10 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IKE & = IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-03.txt > Pages : 7 > Date : 2015-04-25 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > the Internet Key Exchange protocol (IKEv2) and for IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-03= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Apr 25 02:28: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 2B7271B2BD7 for ; Sat, 25 Apr 2015 02:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 HqGUI5RpJqKB for ; Sat, 25 Apr 2015 02:28:13 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 4A11A1B2BD3 for ; Sat, 25 Apr 2015 02:28:13 -0700 (PDT) Received: by widdi4 with SMTP id di4so47430611wid.0 for ; Sat, 25 Apr 2015 02:28:12 -0700 (PDT) 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=9QWrdjYgLvBtAisjbRlYInBa01Qq4h9PyZCqErOZKXs=; b=U2KLGooiG8+hw5S30kOX4rt8YlsgwjmBg16AhMGNfCCogOwlu/4OCgNGcKBIARhtsT qtoM5M8VFSC59p8zRgPmaYaI66Orfh78Qslt7Y/47tjlRsoJwB1SAougHAGwv32FsKxs N884/npL2U9pHSNPtCoi0J4fRp8bpB1vlWJsSwwqkyUV5yUZkqDwfCyoHEZ5FtnURfxe biDGRf4+Sl+Eh4FPUqPNTJQEfVPlHzugk1p9/MlDlje4S0BMofZD0aSBg7lJj7FWas23 05evFm9HgW3b22/LttgI7oD+dUUxvzoXQPikcHY/TYXAbAwsK1rYt0hvuJl97u5DUYm2 IBHw== X-Received: by 10.180.100.101 with SMTP id ex5mr4087647wib.13.1429954092073; Sat, 25 Apr 2015 02:28:12 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id o6sm2496598wiz.24.2015.04.25.02.28.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 02:28:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <0A8CCD2B-4290-4889-805E-3DE5ED7A6489@gmail.com> Date: Sat, 25 Apr 2015 12:28:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5ED276B3-B698-44F3-B3C3-06C76080220A@gmail.com> References: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> <99449AC5-968B-470D-8386-068EC71C3F35@gmail.com> <0A8CCD2B-4290-4889-805E-3DE5ED7A6489@gmail.com> To: ipsec X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.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: Sat, 25 Apr 2015 09:28:15 -0000 And adding the [1]=E2=80=A6 On Apr 25, 2015, at 12:27 PM, Yoav Nir wrote: Replying to myself to prevent others from sending messages to the = internet-drafts and i-d-announce. On Apr 25, 2015, at 12:25 PM, Yoav Nir wrote: Hi This new version closes (I think) all the open issues. I have removed = all references to GDOI as it has been pointed out that GDOI allocated = sender-ID bits from the visible IV, not the invisible salt. I have = replaced all places where it said =E2=80=9Csender ID=E2=80=9D with = =E2=80=9CSalt=E2=80=9D. I have made the salt generated from the keymat = just as it is for AES-GCM. The TLS working group has moved in a whole = other direction ([1]) where they will generate a 96-bit value and XOR = that with the record counter to produce the nonce. We can=E2=80=99t do = that without revising ESP, so for this document I=E2=80=99ll just leave = it at that. With this I believe the document is ready for WGLC. I might want to add = an appendix with an example. Yoav [1] http://www.ietf.org/mail-archive/web/tls/current/msg16122.html > On Apr 25, 2015, at 12:10 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IKE & IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-03.txt > Pages : 7 > Date : 2015-04-25 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > the Internet Key Exchange protocol (IKEv2) and for IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-03= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Apr 25 07:54:33 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 0EDE91B2CD0 for ; Sat, 25 Apr 2015 07:54:32 -0700 (PDT) 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 k5miwpgRR8di for ; Sat, 25 Apr 2015 07:54:31 -0700 (PDT) Received: from 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 5809F1B2CD1 for ; Sat, 25 Apr 2015 07:54:31 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t3PEsRaU090705 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Apr 2015 07:54:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <0A8CCD2B-4290-4889-805E-3DE5ED7A6489@gmail.com> Date: Sat, 25 Apr 2015 07:54:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99E25ADD-1272-4E8D-8758-A261F9A0D57D@vpnc.org> References: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> <99449AC5-968B-470D-8386-068EC71C3F35@gmail.com> <0A8CCD2B-4290-4889-805E-3DE5ED7A6489@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.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: Sat, 25 Apr 2015 14:54:32 -0000 On Apr 25, 2015, at 2:27 AM, Yoav Nir wrote: > With this I believe the document is ready for WGLC. I might want to = add an appendix with an example. As chair and shepherd: we can't start the WG Last Call on this until we = have examples*s*, given the changes in the -03 to add IKEv2. Please = issue a -04 soon that has an appendix with one example of use in IKEv2, = and another in IPsec. --Paul Hoffman= From nobody Sat Apr 25 10:50: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 D05141B2E29 for ; Sat, 25 Apr 2015 10:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dTjoCt6jQNav for ; Sat, 25 Apr 2015 10:50:46 -0700 (PDT) Received: from mail-wi0-x244.google.com (mail-wi0-x244.google.com [IPv6:2a00:1450:400c:c05::244]) (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 CF2531B2E12 for ; Sat, 25 Apr 2015 10:50:45 -0700 (PDT) Received: by wivr20 with SMTP id r20so6637770wiv.3 for ; Sat, 25 Apr 2015 10:50:44 -0700 (PDT) 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=zBM2LfZADKyjM4afwPTHt2TlTb30b11XAJiJwR/0C4c=; b=ZRTQYVBum9tYsgWGBWEvaH1TLBNNQPXRoiYABVa9c/msgDT+0JjL8IlgjjPBLF3lPo XnUAhov7pZAgrtFr6US3N106Y26eCYM2PqZBbgpfBL0zMcSMK8TI8Eqlt4wnz22qXoPt 0Ozz7m86wKrsRsnCr+dLY5nfHA8GOwNrGyc8GdiQFw4oPQdXTL0f1ewO+GiuxxKYedtI wuWSQldRhVIDeEkY0s53p8QP4sS4DXQz+CxfAL9jMhWhDqWeS1J+6vEi4ef3v4zBBvPB mJN5g85HsTPlHoTqrBXj3dJ3GmMpvol2KSAwPfmwXxoN40yroDWErJF9MLYUQrc+sWOS Te5g== X-Received: by 10.180.102.34 with SMTP id fl2mr6736827wib.73.1429984244439; Sat, 25 Apr 2015 10:50:44 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id ei4sm4091991wib.22.2015.04.25.10.50.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 10:50:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <99E25ADD-1272-4E8D-8758-A261F9A0D57D@vpnc.org> Date: Sat, 25 Apr 2015 20:50:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150425091038.10644.88454.idtracker@ietfa.amsl.com> <99449AC5-968B-470D-8386-068EC71C3F35@gmail.com> <0A8CCD2B-4290-4889-805E-3DE5ED7A6489@gmail.com> <99E25ADD-1272-4E8D-8758-A261F9A0D57D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.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: Sat, 25 Apr 2015 17:50:48 -0000 Will do, although 4106 doesn=E2=80=99t have any either. Yoav > On Apr 25, 2015, at 5:54 PM, Paul Hoffman = wrote: >=20 > On Apr 25, 2015, at 2:27 AM, Yoav Nir wrote: >> With this I believe the document is ready for WGLC. I might want to = add an appendix with an example. >=20 > As chair and shepherd: we can't start the WG Last Call on this until = we have examples*s*, given the changes in the -03 to add IKEv2. Please = issue a -04 soon that has an appendix with one example of use in IKEv2, = and another in IPsec. >=20 > --Paul Hoffman From nobody Sun Apr 26 13:48: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 2A0DC1A909B; Sun, 26 Apr 2015 13:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 p37J9jjCcbMW; Sun, 26 Apr 2015 13:48:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216A61A908A; Sun, 26 Apr 2015 13:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 13:48:34 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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: Sun, 26 Apr 2015 20:48:35 -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 : ChaCha20, Poly1305 and their use in IKE & IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-04.txt Pages : 11 Date : 2015-04-26 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange protocol (IKEv2) and for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 26 13:50:35 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 618141A909F for ; Sun, 26 Apr 2015 13:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Y3fHw8gFUcCI for ; Sun, 26 Apr 2015 13:50:33 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 D872A1A9092 for ; Sun, 26 Apr 2015 13:50:32 -0700 (PDT) Received: by wizk4 with SMTP id k4so77624121wiz.1 for ; Sun, 26 Apr 2015 13:50:31 -0700 (PDT) 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=4l3nR35gYjx6HxQkvnSY3/70+9MuG/Hcfks6gIPMbfE=; b=noAGWeT2bYmuyCeC++aKdc9S10Ndu4Ws3Ooq1zb4YSr71N5GQRCrqwHygHs1aNor1c ylZEQhTYUWVYKByOIlc4lJ/tZr+6n5ubz5ZkmaAHMsQKgVX2HqIXDVGqkcRGMqGxQlUi C3GLHH19LnoeRMHVxWCXV1zjCg1syzjt/oBD7PJnTsNek/WcsNT8tK9hSiC3NV7bLJls sv4WkXmGzjSs3G4+YS01UryHFariHef4s+r891NM5CrBvzJQ9g4jHJvpFi8Z7QASEmYv VRMhFTX38c82ZtePLaEEbmqmb6AjyazOgm395lzwNPvl9QjNW5Yod0wL2HrWZXkuxPV9 zzzw== X-Received: by 10.180.105.227 with SMTP id gp3mr14973033wib.56.1430081431666; Sun, 26 Apr 2015 13:50:31 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id gs7sm8735102wib.10.2015.04.26.13.50.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Apr 2015 13:50:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 23:50:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> To: ipsec X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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: Sun, 26 Apr 2015 20:50:34 -0000 Hi. At Paul=E2=80=99s request I have added examples in appendix A and = appendix B. At Yaron=E2=80=99s request I have added some text about the key and salt = derivation in IKE (as opposed to IPsec) Yoav > On Apr 26, 2015, at 11:48 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IKE & = IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-04.txt > Pages : 11 > Date : 2015-04-26 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > the Internet Key Exchange protocol (IKEv2) and for IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-04 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-04= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Apr 26 13:52: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 7ED011A90D7 for ; Sun, 26 Apr 2015 13:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 5kLlCOVGHFC6 for ; Sun, 26 Apr 2015 13:52:07 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 E8B271A90CD for ; Sun, 26 Apr 2015 13:52:06 -0700 (PDT) Received: by wgso17 with SMTP id o17so97506177wgs.1 for ; Sun, 26 Apr 2015 13:52:05 -0700 (PDT) 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=mrJgkVIWO8b8ThETQKaKPnHOAMhdSlTa93Ye8ZzBT7o=; b=Q0tX4hPC1olJ/F0o9xsc54ISWW4lo/hmu6SoDqi/9Xmm32s63BbYTlWTiFpDZkliBO b/GiXkw4+1N3JtboHW0YdNvfe1kLIygjR526p7Uf+P7H4ciNb4IcYF8eFhg08FZ15Tez SkuhqC8FNF6+a9aajolmfIIokRwWhDIN+PiSdBU/XFJeP8g6e4LFD4wMWHxd73FN4vVi TZ07m32bqTRXy0CRkPqkQGs27JjqCqLB+/HBaG7VBBW0CkgD0oXdBNUjv5XW6q9qqQUX Ecej1FmOMM/Lx6IXpmKDxX+x/tN9haY9pW51gVKvZS/Ovysdi+YWtgp+MnkxxcUP+r+z YcJw== X-Received: by 10.180.109.136 with SMTP id hs8mr14776797wib.73.1430081525641; Sun, 26 Apr 2015 13:52:05 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id i6sm26519101wjf.29.2015.04.26.13.52.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Apr 2015 13:52:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Sun, 26 Apr 2015 23:52:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <17580688-772E-45A0-8107-50014FA425D3@gmail.com> References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> To: ipsec X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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: Sun, 26 Apr 2015 20:52:08 -0000 Oh, and one more thing: I=E2=80=99d really appreciate it if somebody = checked my examples. All I can be sure of is that they work in my code. Yoav > On Apr 26, 2015, at 11:50 PM, Yoav Nir wrote: >=20 > Hi. >=20 > At Paul=E2=80=99s request I have added examples in appendix A and = appendix B. >=20 > At Yaron=E2=80=99s request I have added some text about the key and = salt derivation in IKE (as opposed to IPsec) >=20 > Yoav >=20 >> On Apr 26, 2015, at 11:48 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >>=20 >> Title : ChaCha20, Poly1305 and their use in IKE & = IPsec >> Author : Yoav Nir >> Filename : draft-ietf-ipsecme-chacha20-poly1305-04.txt >> Pages : 11 >> Date : 2015-04-26 >>=20 >> Abstract: >> This document describes the use of the ChaCha20 stream cipher along >> with the Poly1305 authenticator, combined into an AEAD algorithm for >> the Internet Key Exchange protocol (IKEv2) and for IPsec. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-04 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly1305-04= >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 From nobody Sun Apr 26 14:12: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 BC8341A916F; Sun, 26 Apr 2015 14:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 C300GWzF7m5H; Sun, 26 Apr 2015 14:12:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4481A1BF6; Sun, 26 Apr 2015 14:12:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150426211200.5284.16048.idtracker@ietfa.amsl.com> Date: Sun, 26 Apr 2015 14:12:00 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-05.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: Sun, 26 Apr 2015 21:12:01 -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 : ChaCha20, Poly1305 and their use in IKE & IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-05.txt Pages : 11 Date : 2015-04-26 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange protocol (IKEv2) and for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-05 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 Sun Apr 26 15:44: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 9693E1A9168 for ; Sun, 26 Apr 2015 15:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mGQaHwuuST-O for ; Sun, 26 Apr 2015 15:44:24 -0700 (PDT) Received: from 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 EF97D1A9167 for ; Sun, 26 Apr 2015 15:44:23 -0700 (PDT) Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t3QMiIsb015642 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Apr 2015 15:44:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Apr 2015 15:44:17 -0700 To: IPsecME WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 26 Apr 2015 22:44:24 -0000 Greetings again. This begins the two-week WG Last Call on = draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would = love to hear from people in either of two groups: - Those who have already reviewed an earlier version of this draft. = Please re-read the draft now, and let us know if it is perfect, or if = there anything else you want added or changed. This includes Yaron, = PaulW, Tero, ScottF, and Valery. - Those who have *not* yet reviewed this draft, but want to help the = IETF create good standards in this area. If you are an IPsec = implementer, or know one at your organization, reviewing this draft and = sending any comments to the list (even just "seems fine" or "I liked it = except this one thing") is useful to all of us. It seems very likely that this new algorithm combination will appear in = IKEv2 and ESP soon, and having folks give a bit more review will help = prevent whoopsies in the future. --Paul Hoffman= From nobody Mon Apr 27 00:46: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 856521B2A11 for ; Mon, 27 Apr 2015 00:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 3c-df-4Juofm for ; Mon, 27 Apr 2015 00:46:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E359A1B2A15 for ; Mon, 27 Apr 2015 00:46:24 -0700 (PDT) Received: by wizk4 with SMTP id k4so88592671wiz.1 for ; Mon, 27 Apr 2015 00:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KnmHRXY8EHb2owwhWadrSGrRu0eqUcIMuQ8FdZt/f4w=; b=aRInpZ6FNhzTu0mbqaogzl6zTuDFymV9IAFxVo9sHkKXZdF0LW9+z4uTTbQpQ+MZ4K UJ61mxquTNgdwU3/gr7DdYtbay2/QvtcCNb827LAdfKbZrktHOsIvetHryTDghSJSPdM FR03jX5Z2ObI7mQj+DFZtUwprcoc/ht00944sic1estwb5NtEAY8QbVsfsQFpJ2r8YLl LexRWM43CuOr2tjc2zKArnRv9H7AU7T797g9/SV6RKVOOxBHMkd9I0VYIJhqndlnuCM6 dbbw4s0Tma9w6ZdbS0SzVbdz+dRxRmMrk7eee99iRTDW0vl+F2F1njyIn6O1nhr/ySr8 PjDw== X-Received: by 10.194.77.180 with SMTP id t20mr20329224wjw.115.1430120783677; Mon, 27 Apr 2015 00:46:23 -0700 (PDT) Received: from [192.168.12.107] (bzq-218-112-74.red.bezeqint.net. [81.218.112.74]) by mx.google.com with ESMTPSA id l3sm10371072wiv.18.2015.04.27.00.46.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 00:46:22 -0700 (PDT) Message-ID: <553DE94D.9050708@gmail.com> Date: Mon, 27 Apr 2015 10:46:21 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Hoffman , IPsecME WG References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 27 Apr 2015 07:46:26 -0000 I am still a bit confused about Sec. 3 (use in IKEv2): - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the IV is included explicitly, and where exactly it should go? - In the bullet that describes the IV, I would add text that the IKE Message ID is not an option, and why. - How do we make sure that the key/IV combination is unique between Initiator and Responder? Thanks, Yaron On 04/27/2015 01:44 AM, Paul Hoffman wrote: > Greetings again. This begins the two-week WG Last Call on draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love to hear from people in either of two groups: > > - Those who have already reviewed an earlier version of this draft. Please re-read the draft now, and let us know if it is perfect, or if there anything else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and Valery. > > - Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft and sending any comments to the list (even just "seems fine" or "I liked it except this one thing") is useful to all of us. > > It seems very likely that this new algorithm combination will appear in IKEv2 and ESP soon, and having folks give a bit more review will help prevent whoopsies in the future. > > --Paul Hoffman > From nobody Mon Apr 27 01:38:43 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 331201B2F09 for ; Mon, 27 Apr 2015 01:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Ij1Pethy6EKe for ; Mon, 27 Apr 2015 01:38:40 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 4C85C1B2F08 for ; Mon, 27 Apr 2015 01:38:40 -0700 (PDT) Received: by wiax7 with SMTP id x7so78534550wia.0 for ; Mon, 27 Apr 2015 01:38:39 -0700 (PDT) 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=Zc/1ZvK2WcNiPtHTbVUpPkiGNdCv8HK7oFTfMn1Jx6A=; b=me7+yB378kCKTQNjYiy3e2p8vS1pAGWmAw3JQo7QaMQUVVz6g1Hz0lQ6Fv4dmMJCbp Ciapway2h3WndeHnAaDTjX2qy79zIZ2T83xjKVkNvS0Cu/3Sigcok3NE1i9+pbTFHXB6 2CxMvMWENMy5yvQYtqdbUZiqTODtpQOT3iu9/MMD6t+teZAKYA1cgAd/aB/uTQgezQ7M AapVX1axZHrnh7zU89kkasjSHreTxSmy1KYXq91rB9wxKBjcyPjJKU5Kg/zLgJAvxBiN W6l9gB1pEst7zCl+tXxsYrsTturAul5ReqdXYKO9mElEvBAOB4i6fuoXxNKu8hH6cBZ7 Avkg== X-Received: by 10.194.133.229 with SMTP id pf5mr12476884wjb.49.1430123919047; Mon, 27 Apr 2015 01:38:39 -0700 (PDT) Received: from [172.24.248.247] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id gj7sm10592091wib.4.2015.04.27.01.38.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 01:38:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <553DE94D.9050708@gmail.com> Date: Mon, 27 Apr 2015 11:38:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <553DE94D.9050708@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 27 Apr 2015 08:38:42 -0000 > On Apr 27, 2015, at 10:46 AM, Yaron Sheffer = wrote: >=20 > I am still a bit confused about Sec. 3 (use in IKEv2): >=20 > - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) = that the IV is included explicitly, and where exactly it should go? It says that the IV is 64-bit, same as in section 2, and RFC 7296 = section 3.14 says that the IV is explicit. Although in honesty, it also = says that the size of the IV is equal to block length, which would make = it 512 bits here? Anyway, RFC 7296 does say that this is true only for = CBC. > - In the bullet that describes the IV, I would add text that the IKE = Message ID is not an option, and why. The whole idea of using sequence number as IV is now gone from the = draft. If we want to add some path-not-taken text, it should probably go = in the Security Considerations or maybe another appendix. I don=E2=80=99t = really think it is relevant. > - How do we make sure that the key/IV combination is unique between = Initiator and Responder? PRF+ generates a bitstring with separate SK_ei and SK_er for the = initiator and responder respectively. Each is 36 octets (288 bits). = While we don=E2=80=99t explicitly prevent PRF+ from generating the same = 36 bytes twice, good PRFs hardly ever will. The same is not true for = IKEv1 (RFC 2409) where the same SKEYID_e is used by both. > Thanks, > Yaron >=20 > On 04/27/2015 01:44 AM, Paul Hoffman wrote: >> Greetings again. This begins the two-week WG Last Call on = draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would = love to hear from people in either of two groups: >>=20 >> - Those who have already reviewed an earlier version of this draft. = Please re-read the draft now, and let us know if it is perfect, or if = there anything else you want added or changed. This includes Yaron, = PaulW, Tero, ScottF, and Valery. >>=20 >> - Those who have *not* yet reviewed this draft, but want to help the = IETF create good standards in this area. If you are an IPsec = implementer, or know one at your organization, reviewing this draft and = sending any comments to the list (even just "seems fine" or "I liked it = except this one thing") is useful to all of us. >>=20 >> It seems very likely that this new algorithm combination will appear = in IKEv2 and ESP soon, and having folks give a bit more review will help = prevent whoopsies in the future. >>=20 >> --Paul Hoffman >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 27 02:38: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 E84F21B2FA3 for ; Mon, 27 Apr 2015 02:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 NDu9SUAy0wSY for ; Mon, 27 Apr 2015 02:38:37 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 CC2371B2FA2 for ; Mon, 27 Apr 2015 02:38:36 -0700 (PDT) Received: by wizk4 with SMTP id k4so91991929wiz.1 for ; Mon, 27 Apr 2015 02:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8HVA7jZJ5LGkFlsVR8DZIux4h9tTO7gApg1zGPGSUyY=; b=V1M/BjUzHNYrcl70R6rs+3MPBUMNAvWrdvGC2fpn2x3gXesoQe6PvGoZJt3DrajKLi d+GANnGf0njukJGtaEYoWZuiR32OXELpxhUWAEKoSwOr5wxdIZv2lrtfyGPEKkykM4w7 C5NoCLjujjwMMm4EKZ7avcS2R35S6/WJ0hG35OGsZe9q+H0N8RskZvxoXhIMC+Kam9QJ S9KKxg1txuf18XuxmG3/fXdFZg0IQWS9M/0t+vAfqYA8s5zlDizlaO+bLZSo3rBRu4ke HYCyEdMFm8SkytvelWv6idVJIoYcpn3i0Jt3GYXzUjrkANRhrUfZD2wh9ueGirnXzd5N OCAA== X-Received: by 10.194.5.74 with SMTP id q10mr20734514wjq.27.1430127515546; Mon, 27 Apr 2015 02:38:35 -0700 (PDT) Received: from [192.168.12.107] (bzq-218-112-74.red.bezeqint.net. [81.218.112.74]) by mx.google.com with ESMTPSA id fm8sm10812214wib.9.2015.04.27.02.38.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 02:38:34 -0700 (PDT) Message-ID: <553E0398.4080502@gmail.com> Date: Mon, 27 Apr 2015 12:38:32 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yoav Nir References: <553DE94D.9050708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 27 Apr 2015 09:38:39 -0000 Clearly we need to mention that the IV is included, despite the text of RFC 7296. You are right about SK_ei/er. The second bullet in Sec. 3 should not mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er. Thanks, Yaron On 04/27/2015 11:38 AM, Yoav Nir wrote: > >> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer wrote: >> >> I am still a bit confused about Sec. 3 (use in IKEv2): >> >> - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the IV is included explicitly, and where exactly it should go? > > It says that the IV is 64-bit, same as in section 2, and RFC 7296 section 3.14 says that the IV is explicit. Although in honesty, it also says that the size of the IV is equal to block length, which would make it 512 bits here? Anyway, RFC 7296 does say that this is true only for CBC. > >> - In the bullet that describes the IV, I would add text that the IKE Message ID is not an option, and why. > > The whole idea of using sequence number as IV is now gone from the draft. If we want to add some path-not-taken text, it should probably go in the Security Considerations or maybe another appendix. I don’t really think it is relevant. > >> - How do we make sure that the key/IV combination is unique between Initiator and Responder? > > PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and responder respectively. Each is 36 octets (288 bits). While we don’t explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used by both. > >> Thanks, >> Yaron >> >> On 04/27/2015 01:44 AM, Paul Hoffman wrote: >>> Greetings again. This begins the two-week WG Last Call on draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love to hear from people in either of two groups: >>> >>> - Those who have already reviewed an earlier version of this draft. Please re-read the draft now, and let us know if it is perfect, or if there anything else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and Valery. >>> >>> - Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft and sending any comments to the list (even just "seems fine" or "I liked it except this one thing") is useful to all of us. >>> >>> It seems very likely that this new algorithm combination will appear in IKEv2 and ESP soon, and having folks give a bit more review will help prevent whoopsies in the future. >>> >>> --Paul Hoffman >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Apr 27 03:05: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 C695A1B2FD5 for ; Mon, 27 Apr 2015 03:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3msK4q6kct11 for ; Mon, 27 Apr 2015 03:05:53 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id BDC9A1B2FD2 for ; Mon, 27 Apr 2015 03:05:53 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 27 Apr 2015 03:05:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,656,1422950400"; d="scan'208";a="719747369" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga002.jf.intel.com with ESMTP; 27 Apr 2015 03:05:53 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.204]) by IRSMSX152.ger.corp.intel.com ([169.254.6.7]) with mapi id 14.03.0224.002; Mon, 27 Apr 2015 11:05:52 +0100 From: "Doyle, Stephen" To: "ipsec@ietf.org" Thread-Topic: WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 Thread-Index: AdCA0NDV6iIU5RnmQAy8KZ9i+0vDcg== Date: Mon, 27 Apr 2015 10:05:52 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 27 Apr 2015 10:05:55 -0000 In the ESP Example in Appendix A, the 'Next Header' field is missing from t= he ESP Trailer portion of the plaintext. Regards, Steve -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies. From nobody Mon Apr 27 04:02: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 46B621B3079 for ; Mon, 27 Apr 2015 04:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 CmDODo_lJd7E for ; Mon, 27 Apr 2015 04:02:55 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [IPv6:2001:620:130:a080::46]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FEC1B3078 for ; Mon, 27 Apr 2015 04:02:55 -0700 (PDT) Received: from [192.168.1.118] (143.204.173.83.static.wline.lns.sme.cust.swisscom.ch [83.173.204.143]) by mail.strongswan.org (Postfix) with ESMTPSA id 4BADB400DB; Mon, 27 Apr 2015 13:03:17 +0200 (CEST) Message-ID: <1430132572.3173.49.camel@martin> From: Martin Willi To: Yoav Nir Date: Mon, 27 Apr 2015 13:02:52 +0200 In-Reply-To: <17580688-772E-45A0-8107-50014FA425D3@gmail.com> References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> <17580688-772E-45A0-8107-50014FA425D3@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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, 27 Apr 2015 11:02:56 -0000 Yoav, > Oh, and one more thing: I’d really appreciate it if somebody checked my > examples. All I can be sure of is that they work in my code. I've hit two issues when verifying the IKEv2 example in our code: >From appendix B: > Padding as required by RFC 7296 is 4 bytes long. Do we have such a padding requirement for IKEv2? For ChaCha20 we have no requirement for input lengths, so no padding is needed. While we have 4 byte padding in ESP, I don't think this is true for IKEv2 Encrypted Payloads, is it? >From RFC 7296 3.14: > o Padding MAY contain any value chosen by the sender, and MUST have > a length that makes the combination of the payloads, the Padding, > and the Pad Length to be a multiple of the encryption block size. > This field is encrypted with the negotiated cipher. > > o Pad Length is the length of the Padding field. The sender SHOULD > set the Pad Length to the minimum value that makes the combination > of the payloads, the Padding, and the Pad Length a multiple of the > block size, but the recipient MUST accept any length that results > in proper alignment. This field is encrypted with the negotiated > cipher. So while the used padding is not invalid, it is not what we SHOULD use, and if so probably not a good example. Maybe we should also add a note about IKEv2 padding to section 3? The other issue I've seen is about the Next Payload: > Encrypted Payload: > 000 00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70 ...,........a..p The Next Payload field in the Encrypted Payload is 0. However, RFC 7296 defines: > Next Payload - The payload type of the first embedded payload. So I think Next Payload should be Notify (0x29). Kind Regards Martin From nobody Mon Apr 27 08:05:44 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 2F9921A87C0 for ; Mon, 27 Apr 2015 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XgF2yQWQRWmB for ; Mon, 27 Apr 2015 08:05:40 -0700 (PDT) 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 45EEC1A87B9 for ; Mon, 27 Apr 2015 08:05:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6FF33203AE for ; Mon, 27 Apr 2015 11:17:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 820BF63B86; Mon, 27 Apr 2015 11:05:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6871863731 for ; Mon, 27 Apr 2015 11:05:39 -0400 (EDT) From: Michael Richardson To: IPsecME WG In-Reply-To: <7619B0FCC67A43ACB52141E63B65C1B9@buildpc> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <818C9ECF-3EE7-4804-B0BB-A3E802230751@gmail.com> <7619B0FCC67A43ACB52141E63B65C1B9@buildpc> 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: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 27 Apr 2015 15:05:42 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > I agree that it is better to have a single mechanism for TLS and IPsec. > However I doubt if TLS WG would take into considerations our problems, > when making its own decision. On the other hand I think that implicit > IV is unacceptable for us (at least for IKE). Whatever problems we have with an implicit IV in ESP will also be felt by DTLS. -- 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) iQEVAwUBVT5QQ4CLcPvd0N1lAQKeOgf+P+Gi1u5z1ParP9/fxHdCmqn+fv6tff0i aLwHjhmCm+RflJ8FlizCE30Cl4Qt/Cr+1hAHtySOtJTkT17EKl9rlQyuMXo99G4r 5UtabsehFb8Qt3W7O+rQQOKPKYRjmOe0IRYAksFFw08/hxFpg8q4tdgY+ZbOn973 ZBMZAZvvLUfz8FzuHeCseZtOI+726v1O7h51m1gsOMSpbed1ZJRS6M/8I9Y6sivO WPBtGfAVCDUmZ/KNpZtTPQnkTlf9x/Y2pXQRR1OiwGH75Lf1fA/r+E8hSw7/cPco DI9d08W3awhlNiAT1uWFgQyNeWWtkQvACBH+kg35CcqFksZMgIp0qQ== =prx7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 27 08:08: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 406621A87C9 for ; Mon, 27 Apr 2015 08:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ip7YEpp8mqYI for ; Mon, 27 Apr 2015 08:08:34 -0700 (PDT) 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 C238E1A8729 for ; Mon, 27 Apr 2015 08:08:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C6D7203AE for ; Mon, 27 Apr 2015 11:20:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9763463B86; Mon, 27 Apr 2015 11:08:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7C9DC63731 for ; Mon, 27 Apr 2015 11:08:33 -0400 (EDT) From: Michael Richardson To: IPsecME WG In-Reply-To: <21816.52477.890081.649693@fireball.kivinen.iki.fi> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <818C9ECF-3EE7-4804-B0BB-A3E802230751@gmail.com> <7619B0FCC67A43ACB52141E63B65C1B9@buildpc> <21816.52477.890081.649693@fireball.kivinen.iki.fi> 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: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 27 Apr 2015 15:08:36 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > What I proposed earlier was that we define that chacha20 uses explicit > IV, but the IV is always generated as running counter incremented by > one. > In normal case the IV is sent inside the both IKEv2 and ESP packets. > In ESP the sequence number is used normally for replay protection. > Then we could create new "ESP Sequence number + IV compression" > protocol, that would negotiate the support for this in the IKEv2 for > ESP, and if enabled by both ends, then they would set the ESP sequence > number and chacha20 IV to be linked, i.e. they would always be same, > and then we could compress one of them away after the encryption, and > decompress them back in place before decryption. That's an interesting proposal. It seems excessively modular to me, but I'm willing to listen more to why it makes sense. Are there actually IKE daemons that use the IPsec code to do their decryption? I can see how this might happen in IoT space.. -- 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) iQEVAwUBVT5Q8YCLcPvd0N1lAQJmRAf+PiiFD9CmbQ9f6IGIZ7VegLb9pfILp0x6 c7VF8R4PKZHmGTkvETEtcGfj+qUJxd6mHYpqVF7UElkWkknTbVktW7PmZDC/MR4N nV1eLm9F9Yyzao9oURYYPunZTq09nxpBahpc4S3lSpLPCfHLvK2GknoiKxFfc9Yf 2QvFVlH/Rz4YavEfWLzJXXfyue1jpLDxM38J9MXhzZhpkuE62EyS4AAvOXxkqtFR neAU3tDj3QYBwuKB0akWjEx9ioIncSMNh4+Yq+BSr35jYWQCATVjQbJTdxG2XxXM MbWQmEsfC+VooMLYT1/rm7+n3X3lyY1PwOA0EcX4UNNttEKxThcsdQ== =xnCV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 27 08:15: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 E9A6E1A8849 for ; Mon, 27 Apr 2015 08:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_28=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jNQ6y5F3_Yau for ; Mon, 27 Apr 2015 08:14:56 -0700 (PDT) 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 58F331A8847 for ; Mon, 27 Apr 2015 08:14:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B145E007 for ; Mon, 27 Apr 2015 11:26:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8E61B63B86; Mon, 27 Apr 2015 11:14:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 759D063731 for ; Mon, 27 Apr 2015 11:14:55 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> 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: Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 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, 27 Apr 2015 15:15:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Second issue is about UI advice. Some implementations (yes, mine is > included) allow the user to configure encryption algorithm, MAC > algorithm, and D-H group. There is no setting for PRF since such UIs > date back to IKEv1. The PRF is usually just taken from the setting for > MAC algorithm. This works fine as long as all supported MAC algorithms > are HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC > 5282 makes no mention of this issue. I=E2=80=99m wondering if we shou= ld > recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256. So, in this case, if you wanted to not change your UI, maybe you would tell the user to configure encryption-algorithm=3DChacha20-Poly1305 MAC=3DHMAC-SHA2 DH=3Dwhatever the MAC would not apply to IPsec at all? I guess if we are deploying this algorithm with the concern that HMAC-SHA2/= AES might become weak, that it would seem odd to depend upon SHA2 as the PRF. At least, users might not understand. (noting that SHA2 !=3D HMAC-SHA2, and also that the inputs to the PRF as not very easily manipulated...) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVT5Sb4CLcPvd0N1lAQLd0gf/fQYulB66qXFIngOA/fx8SE/c22hjAsM7 tuPo9st2pVItnVbUSCHo6GOn8cXR8UkWEQC44DNIEk/IeNNd3JacWT3SqitSvTek Nyy26NMlJE8bR4vgDaDURLRWbOOmWXFeqO09ogzKsK2+IdLiRJ0QSHaBZy4OU5nf ajiD5GUI2Kj6pWBybjLyrG2LokJwDkoGPoKDbjzsT/JuyQ0BQyEMwlCsqIpegsMU mLX4Gm7mtwniSGpey/8ztd+M2FfQIiUyRR9+CQKZLSCC+hRMEiqC52jhD2B9g/c5 spstvhyGqYOWCVEgOUWGjBqHjfeHd/0CydQOcaqQYArnnMl14t3taw== =p5eL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 27 08:25:11 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 1801C1A8831 for ; Mon, 27 Apr 2015 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4vDPrjiH4b1d for ; Mon, 27 Apr 2015 08:25:05 -0700 (PDT) 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 8F3C71A882C for ; Mon, 27 Apr 2015 08:25:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C34A9E007 for ; Mon, 27 Apr 2015 11:36:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C759C63B86; Mon, 27 Apr 2015 11:25:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B18D563731 for ; Mon, 27 Apr 2015 11:25:04 -0400 (EDT) From: Michael Richardson To: "IPsecME WG" In-Reply-To: <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> 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: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 27 Apr 2015 15:25:10 -0000 --=-=-= Content-Type: text/plain I read draft-ietf-ipsecme-chacha20-poly1305 on Friday last, and then found that I needed to further review draft-nir-cfrg-chacha20-poly1305-06 to better understand the questions in para 2 of the security considerations, the question about the uniqueness the nonce, so my initial reading, being mostly ignorant about ChaCha and Poly1305 was very confusing. (In preparing this email, I was also using the -05 document, which I see is new. I think that I read -03 on Friday. -04 seems to have been skipped?) I had not yet read any of the discussion on the list (intentionally) so as to judge whether I understood the document on it's own. {in preparing this email, I read the thread afterwards, and I now see that some discussion was previously about IV being derived from replay counter, a notion which I think has been removed from the ID. I don't think that I have any new questions; I think that after having read the document well, that I can implement from the documents as they are} I don't understand: > As the ChaCha20 block function is not applied directly to the > plaintext, no padding should be necessary. However, in keeping with could this be a typo ChaCha20 vs Poly1305? If the encryption algorithm is now applied directly, then what is? Or is meant that the block function for ChaCha20 used only to generate bits for a stream cipher, and the XOR is what is "applied directly"? > The same key and nonce, along with a block counter of zero are passed > to the ChaCha20 block function, and the top 256 bits of the result > are used as the Poly1305 key. The nonce passed to the block > function here is the same nonce that is used in ChaCha20, including the 32-bit > Salt, and the key passed is the same as the encryption key. I think that if I have a block encryption function, that I need to encrypt something to get an output. I don't know what that is here.... Later I understood from reading cfrg-chacha20 that the ChaCha20 block function acts as a prng, and that's why this is a stream ciper, not a block cipher. The use of the term "block function" here was confusing to me. At first, I understand the nonce, was going to be the IV. Was there some discussion/options in a previous version of the draft? I initially understood that the the 32-bit block counter would be taken from the replay counter, but now I see that this is incorrect, that it's unrelated to the replay counter, and that I misunderstood at first. So the Salt is really part of the key material. We have a 36-byte key. It matters to people debugging things with a tool like TCPDUMP, that they know they should expect 36-bytes. Is this diagram correct: keymat: iv: ctr: +-----------------------+----+ +--------+ +----+ |01234567890123456789012|0123| |abcdefgh| |0001| +-----------------------+----+ +--------+ +----+ | | | | | | | | | | | | key: V nonce: V block V +-----------------------+ +------------+ ctr:+----+ |01234567890123456789012| |0123abcdefgh| |00xx| +-----------------------+ +------------+ +----+ words: 4-11 words: 13-15 word 12 \-----\ /------------\ /-----------------------------/ \/ \ / | ctr=0 \/ 64-byte chunks prng | || | |^^xor^ --< plaintext+padding+NH | replay# || | spi# +----------+ | | | cipher | | | /--<--| text | | | | +----------+ | | | | | | | | V V V | /----------\ | | Poly1305 | | | algo | | \----------/ | V V +----+ |MIC | +----+ I am very very very happy that cfrg-chacha20 has so many examples in it. That's really awesome. It wasn't until I read all of cfrg-chacha20 that I understood that the Poly1305 needs to seeded for *each* packet. I also think that the Poly1305 is not used in an HMAC construction. I think that the IANA considerations of ipsecme-chacha20-poly1305 should say something like, "According to cfrg-chacha20, Poly-1305 is not suitable for use as a PRF for IKEv2, and this specification explicitely does not allocate a code point for that." ===== -- 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) iQEVAwUBVT5U0ICLcPvd0N1lAQJGKAf+MpfWygFHp88bgNO4jG/WWZxE6KtSLD7m 91UCalReq0Gd5937SyWrRLkOTQa9KROAWCJuGHbuM09RokJRYG4CFV5qgFi8HUO3 vFhVgSJs4qG7Pvf8CCG/hKp7Jhk7cdLC6UGt/dC5m7/lwV0fEez5RlARYlssfZmT YA0Pik6Jmh5/HsHaR0WFTLjl+Rf/a8IVErQY7ewRS2cPydC+VL+LKAkR44lrcBK4 FdDYgnvIXWmp/ySMIwE3bKmrDk9sxpXc6yUD9Rpneb9p2STGu4Tzdr7zQESEM1cX jcUrU3ewLT2kdGGoLc/FOWmoxCHDQxQ2yzJNA8FonQ4A5HPILzqruQ== =n3bf -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 27 14:12: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 72C541A8ADB for ; Mon, 27 Apr 2015 14:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 moK9_Pahg4sD for ; Mon, 27 Apr 2015 14:12:10 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 F3D6E1A8A9D for ; Mon, 27 Apr 2015 14:11:55 -0700 (PDT) Received: by wgin8 with SMTP id n8so129806068wgi.0 for ; Mon, 27 Apr 2015 14:11:54 -0700 (PDT) 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=RNU9bijwwkkoEcgpXx0lWUEF95W/8RX37FRSxzQ+K4Y=; b=slFIMAapY+0m8w8t3YBdVhb3lIS/dHlYk4kUjNXzNlXXsZCJgg0ei/WzVwF7Y8qiP5 kj/qHM9L8sHc64Gm6ZnWn2EB5DYauhruy6gTxtpfAlihAueOCRlgGUPQu3xM2Tq9Wdeh ES2R2E4xNvr6QJHheGM45Udys6Analzs1nE0D+FhT7tGzWcuUvIxM1jb2wCN/PRr5Fsz fFoFaC6Cy82BSVn1p/V3jPMBQfQWASG8VHjfc+gplBY22OAFZwXW5GmQ9oqvcHwZXjMi z58PS1HTVo1wtTV6AFz2xjZqcVBBPM3JUYjkEAYWhgdhZwzu9hvmuKu8EnR1/mqRg/kz Vhsg== X-Received: by 10.194.60.173 with SMTP id i13mr25642777wjr.124.1430169114720; Mon, 27 Apr 2015 14:11:54 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id 16sm31064814wjs.41.2015.04.27.14.11.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 14:11:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Tue, 28 Apr 2015 00:11:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <71DFC483-03B2-4E2D-BA4D-BFED374AA61E@gmail.com> References: To: "Doyle, Stephen" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 27 Apr 2015 21:12:14 -0000 Thanks. I=E2=80=99ve fixed this in my working draft of -06, which = should be published soon. Yoav > On Apr 27, 2015, at 1:05 PM, Doyle, Stephen = wrote: >=20 > In the ESP Example in Appendix A, the 'Next Header' field is missing = from the ESP Trailer portion of the plaintext. >=20 > Regards, > Steve > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County = Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare >=20 > This e-mail and any attachments may contain confidential material for = the sole use of the intended recipient(s). Any review or distribution by = others is strictly prohibited. If you are not the intended recipient, = please contact the sender and delete all copies. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 27 14:27: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 2637F1A8AD7 for ; Mon, 27 Apr 2015 14:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 m9B1K1narJmF for ; Mon, 27 Apr 2015 14:27:31 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 6AFE01A8AAD for ; Mon, 27 Apr 2015 14:27:31 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so93744953wic.1 for ; Mon, 27 Apr 2015 14:27:30 -0700 (PDT) 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=Vt5v3zx3/bU+qOPOMHezxp426DjCPhWiRxj+rJL9nfA=; b=s7d4zuBH7nAbUUwARdI8N8WlAIDs9310CE+bGuTKNUnR+fhk63mpEGXNQPzAt/p4I8 m/WROmkueNUXqqQO7y9CyyoqfE+0idFoI4KxjsulynmeBUQy2ft/ODzCVworpGZCf+JF sfWaF5gf5OugaDinBgf7+CvjI1vlAeWFBogy/sdlGoyOtmgd4VfcQfH1pxqg3Rqd6AyZ mLmK/IbjLKQRBkg8MPV/ZjBc1APEbD+YcgR/9xFeStLEB0Lsz3g6axNVbxY/Enq9AEZH Y+NQX0aE45Dr3BuG48hFaKqSOIAFBlL1TRWD/bg+u8fv2o+T7txcXs4BRWRjPyXP+8u9 0Xcg== X-Received: by 10.194.47.231 with SMTP id g7mr25695632wjn.140.1430170050114; Mon, 27 Apr 2015 14:27:30 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id u3sm25165566wjq.36.2015.04.27.14.27.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 14:27:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <1430132572.3173.49.camel@martin> Date: Tue, 28 Apr 2015 00:27:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> <17580688-772E-45A0-8107-50014FA425D3@gmail.com> <1430132572.3173.49.camel@martin> To: Martin Willi X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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, 27 Apr 2015 21:27:33 -0000 Hi, Martin. See inline. > On Apr 27, 2015, at 2:02 PM, Martin Willi = wrote: >=20 > Yoav, >=20 >> Oh, and one more thing: I=E2=80=99d really appreciate it if somebody = checked my >> examples. All I can be sure of is that they work in my code. >=20 > I've hit two issues when verifying the IKEv2 example in our code: >=20 >=20 > =46rom appendix B: >=20 >> Padding as required by RFC 7296 is 4 bytes long. >=20 > Do we have such a padding requirement for IKEv2? For ChaCha20 we have = no > requirement for input lengths, so no padding is needed. While we have = 4 > byte padding in ESP, I don't think this is true for IKEv2 Encrypted > Payloads, is it? >=20 > =46rom RFC 7296 3.14: >=20 >> o Padding MAY contain any value chosen by the sender, and MUST = have >> a length that makes the combination of the payloads, the = Padding, >> and the Pad Length to be a multiple of the encryption block = size. >> This field is encrypted with the negotiated cipher. >>=20 >> o Pad Length is the length of the Padding field. The sender = SHOULD >> set the Pad Length to the minimum value that makes the = combination >> of the payloads, the Padding, and the Pad Length a multiple of = the >> block size, but the recipient MUST accept any length that = results >> in proper alignment. This field is encrypted with the = negotiated >> cipher. >=20 > So while the used padding is not invalid, it is not what we SHOULD = use, > and if so probably not a good example. Maybe we should also add a note > about IKEv2 padding to section 3? This is actually quite unfortunate text. Fields must be aligned to block = size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to = 64 bytes would be totally arbitrary, yet that is what the MUST = requirement in the first bullet seems to be saying. I don=E2=80=99t even = know what =E2=80=9Cproper alignment=E2=80=9D means for a cipher such as = this. If anything is proper alignment, then the value that fulfills the = SHOULD requirement is zero (with no padding bytes). For section 3, I = could add a text that echoes the second bullet: The sender SHOULD include no padding and set the Pad Length field to = zero. The receiver MUST accept any length of padding. Sounds good? >=20 >=20 >=20 > The other issue I've seen is about the Next Payload: >=20 >> Encrypted Payload: >> 000 00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70 = ...,........a..p >=20 > The Next Payload field in the Encrypted Payload is 0. However, RFC = 7296 > defines: >=20 >> Next Payload - The payload type of the first embedded payload. >=20 > So I think Next Payload should be Notify (0x29). Yes, you=E2=80=99re right. I=E2=80=99ve fixed this in my working draft. = I should publish again in a day or two. Thanks. Yoav From nobody Mon Apr 27 15:00: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 125B31A8A4C for ; Mon, 27 Apr 2015 15:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 UyWaojZBFySr for ; Mon, 27 Apr 2015 15:00:24 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 0F7A41A88A3 for ; Mon, 27 Apr 2015 15:00:24 -0700 (PDT) Received: by wgin8 with SMTP id n8so130871659wgi.0 for ; Mon, 27 Apr 2015 15:00:22 -0700 (PDT) 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=cPtDwaM4JXFcPdFqPBURa0U3fkZ80dPE4iun+C6wesQ=; b=tpwTmspvb9kCogahqob59UhZzlkhRVHgvjPMNiFhWuU/DPQYfqWR5isTO6A06OrA34 5y0BJ4QUPQFx23P4hvyAtAqJJYN2ATtWebwE/kLkvdsMxsl42Yh4h6jOpiRNy7c5pt1R PhJ+4sUT769sSTqAvLIXshiECcOu/zn3p4WRDnASi3dg3HhqafOghIqRl6TiVIV1a5E1 94phQKo//89C4ae6vHnLWv2BnDdX7oIf+CBkDNOkOS3dfnXSIS/s+7uGLzE3HBzK3jRK kWj6R6+jh2xbDS73Rq+qPlhanHBvEqOcjEBmZZknHVdRAsWrcH/ov/gSuGbtbrTn77Gw pfIw== X-Received: by 10.195.11.202 with SMTP id ek10mr25810144wjd.12.1430172022836; Mon, 27 Apr 2015 15:00:22 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id z12sm31178059wjq.12.2015.04.27.15.00.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 15:00:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <553E0398.4080502@gmail.com> Date: Tue, 28 Apr 2015 01:00:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <553DE94D.9050708@gmail.com> <553E0398.4080502@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11 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, 27 Apr 2015 22:00:26 -0000 OK. Make those changes. I=E2=80=99ll post a new version tomorrow. Yoav > On Apr 27, 2015, at 12:38 PM, Yaron Sheffer = wrote: >=20 > Clearly we need to mention that the IV is included, despite the text = of RFC 7296. >=20 > You are right about SK_ei/er. The second bullet in Sec. 3 should not = mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er. >=20 > Thanks, > Yaron >=20 > On 04/27/2015 11:38 AM, Yoav Nir wrote: >>=20 >>> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer = wrote: >>>=20 >>> I am still a bit confused about Sec. 3 (use in IKEv2): >>>=20 >>> - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) = that the IV is included explicitly, and where exactly it should go? >>=20 >> It says that the IV is 64-bit, same as in section 2, and RFC 7296 = section 3.14 says that the IV is explicit. Although in honesty, it also = says that the size of the IV is equal to block length, which would make = it 512 bits here? Anyway, RFC 7296 does say that this is true only for = CBC. >>=20 >>> - In the bullet that describes the IV, I would add text that the IKE = Message ID is not an option, and why. >>=20 >> The whole idea of using sequence number as IV is now gone from the = draft. If we want to add some path-not-taken text, it should probably go = in the Security Considerations or maybe another appendix. I don=E2=80=99t = really think it is relevant. >>=20 >>> - How do we make sure that the key/IV combination is unique between = Initiator and Responder? >>=20 >> PRF+ generates a bitstring with separate SK_ei and SK_er for the = initiator and responder respectively. Each is 36 octets (288 bits). = While we don=E2=80=99t explicitly prevent PRF+ from generating the same = 36 bytes twice, good PRFs hardly ever will. The same is not true for = IKEv1 (RFC 2409) where the same SKEYID_e is used by both. >>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 04/27/2015 01:44 AM, Paul Hoffman wrote: >>>> Greetings again. This begins the two-week WG Last Call on = draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would = love to hear from people in either of two groups: >>>>=20 >>>> - Those who have already reviewed an earlier version of this draft. = Please re-read the draft now, and let us know if it is perfect, or if = there anything else you want added or changed. This includes Yaron, = PaulW, Tero, ScottF, and Valery. >>>>=20 >>>> - Those who have *not* yet reviewed this draft, but want to help = the IETF create good standards in this area. If you are an IPsec = implementer, or know one at your organization, reviewing this draft and = sending any comments to the list (even just "seems fine" or "I liked it = except this one thing") is useful to all of us. >>>>=20 >>>> It seems very likely that this new algorithm combination will = appear in IKEv2 and ESP soon, and having folks give a bit more review = will help prevent whoopsies in the future. >>>>=20 >>>> --Paul Hoffman >>>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 From nobody Mon Apr 27 15:52: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 34A131A9168 for ; Mon, 27 Apr 2015 15:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 tGY3cIzd5BaB for ; Mon, 27 Apr 2015 15:52:12 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 673061AC3AB for ; Mon, 27 Apr 2015 15:52:12 -0700 (PDT) Received: by wiun10 with SMTP id n10so7995426wiu.1 for ; Mon, 27 Apr 2015 15:52:11 -0700 (PDT) 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=se/ebgOZ05lQJcCVU5ahRA38j9xe/jZOvrErzvCpwbk=; b=AbMNTlVcMbykrNxK3WW2OBRFcjKe3KG5PBFIHPPvv11xz4lBbT5DGJTFYzwTJv27Mw 9MQpHap+zib2Cs9FiTjQCQEVxreYBmSwWOihfJ+pl2AesgCLPo2kLJ2ewcCJtfeXEBQV V7wSMTyGV5B1VZBsd6IglT+IB5eMWmYylBEprVoU5hp0zHCWWTztca4rAZUOOZKxe6xZ mEqoKHOywOpSBvJ2vYQzjTNl758kYcZYnvGOhDLMvwvKb66KyXfqXm7nsOAniiCTVYHY 8D+WSgZQctg0Lh502hqC/qQBwWGeW7msiCSLRuwb8kAtPqK+goDARUvi3Mjv6RN0rFf1 GFEg== X-Received: by 10.194.90.47 with SMTP id bt15mr27224482wjb.41.1430175131140; Mon, 27 Apr 2015 15:52:11 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id m1sm13559176wiw.7.2015.04.27.15.52.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 15:52:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <22826.1430148304@sandelman.ca> Date: Tue, 28 Apr 2015 01:52:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8B5A864D-C045-43AA-81C8-286FD8AE265E@gmail.com> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <22826.1430148304@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 27 Apr 2015 22:52:17 -0000 > On Apr 27, 2015, at 6:25 PM, Michael Richardson = wrote: >=20 >=20 > I read draft-ietf-ipsecme-chacha20-poly1305 on Friday last, and then = found > that I needed to further review draft-nir-cfrg-chacha20-poly1305-06 to = better > understand the questions in para 2 of the security considerations, the > question about the uniqueness the nonce, so my initial reading, being > mostly ignorant about ChaCha and Poly1305 was very confusing. >=20 > (In preparing this email, I was also using the -05 document, which I = see is > new. I think that I read -03 on Friday. -04 seems to have been = skipped?) >=20 > I had not yet read any of the discussion on the list (intentionally) = so as > to judge whether I understood the document on it's own. >=20 > {in preparing this email, I read the thread afterwards, and I now see = that > some discussion was previously about IV being derived from replay = counter, a > notion which I think has been removed from the ID. I don't think that = I have > any new questions; I think that after having read the document well, = that > I can implement from the documents as they are} >=20 > I don't understand: >> As the ChaCha20 block function is not applied directly to the >> plaintext, no padding should be necessary. However, in keeping with >=20 > could this be a typo ChaCha20 vs Poly1305? > If the encryption algorithm is now applied directly, then what is? > Or is meant that the block function for ChaCha20 used only to generate > bits for a stream cipher, and the XOR is what is "applied directly=E2=80= =9D? Yeah, perhaps I didn=E2=80=99t phrase it the best way. If you=E2=80=99re = using AES and you have a 19-byte plaintext and you=E2=80=99re using ECB = (or CBC) you can encrypt the first 16-byte block of the plaintext, but = for the second block you only have 3 bytes, whereas AES requires 16. So = you need to pad. With CTR, CCM, GCM you encrypt a counter, which is = always 16 bytes, Since you=E2=80=99re not applying AES to the plaintext = (but to a counter) you don=E2=80=99t need to pad the plaintext - you = just throw away the extra bytes of XOR mask that you created. ChaCha20 is the same: you generate a 64-byte block from a key, a nonce = and a counter, and you XOR as much of it as you need with the plaintext = - so no pad is needed. >> The same key and nonce, along with a block counter of zero are = passed >> to the ChaCha20 block function, and the top 256 bits of the result >> are used as the Poly1305 key. The nonce passed to the block >> function here is the same nonce that is used in ChaCha20, including = the 32-bit >> Salt, and the key passed is the same as the encryption key. >=20 > I think that if I have a block encryption function, that I need to = encrypt > something to get an output. I don't know what that is here.... > Later I understood from reading cfrg-chacha20 that the ChaCha20 block > function acts as a prng, and that's why this is a stream ciper, not a = block > cipher. The use of the term "block function" here was confusing to = me. It=E2=80=99s not that different from AES-GCM. With AES-GCM (or just CTR) = you have a 128-bit counter (actually it=E2=80=99s just a 32-bit counter = as 96-bits are the per-packet nonce). You encrypt the counter and get a = 16-byte block that you XOR with the plaintext. With ChaCha20-Poly1305 you also have a 128-bit counter with 96 fixed = bits. You run the ChaCha20 block function to generate a 64-byte block = that you XOR with the plaintext. The only difference is that the size of the counter is not the same as = the size of the output block. This is different from a real stream cipher where a single key with no = nonce can generate an arbitrary length byte stream. ChaCha20 can only = produce 64 bytes from a single value of the nonce. > At first, I understand the nonce, was going to be the IV. Was there = some > discussion/options in a previous version of the draft? > I initially understood that the the 32-bit block counter would be = taken from > the replay counter, but now I see that this is incorrect, that it's = unrelated > to the replay counter, and that I misunderstood at first. >=20 > So the Salt is really part of the key material. We have a 36-byte = key. It > matters to people debugging things with a tool like TCPDUMP, that they = know they > should expect 36-bytes. >=20 > Is this diagram correct: >=20 > keymat: iv: ctr: > +-----------------------+----+ +--------+ +----+ > |01234567890123456789012|0123| |abcdefgh| |0001| > +-----------------------+----+ +--------+ +----+ > | | | | > | | | | > | | | | > key: V nonce: V block V > +-----------------------+ +------------+ ctr:+----+ > |01234567890123456789012| |0123abcdefgh| |00xx| > +-----------------------+ +------------+ +----+ > words: 4-11 words: 13-15 word 12 >=20 > \-----\ /------------\ /-----------------------------/ > \/ \ / > | ctr=3D0 \/ 64-byte chunks prng > | || > | |^^xor^ --< plaintext+padding+NH > | replay# || > | spi# +----------+ > | | | cipher | > | | /--<--| text | > | | | +----------+ > | | | | > | | | | > V V V | > /----------\ | > | Poly1305 | | > | algo | | > \----------/ | > V V > +----+ > |MIC | > +----+ >=20 >=20 > I am very very very happy that cfrg-chacha20 has so many examples in = it. > That's really awesome. >=20 > It wasn't until I read all of cfrg-chacha20 that I understood that the > Poly1305 needs to seeded for *each* packet. I also think that the = Poly1305 > is not used in an HMAC construction. >=20 > I think that the IANA considerations of ipsecme-chacha20-poly1305 = should say > something like, > "According to cfrg-chacha20, Poly-1305 is not suitable for > use as a PRF for IKEv2, and this specification explicitely > does not allocate a code point for that.=E2=80=9D That=E2=80=99s kind of a weird thing to write. We don=E2=80=99t allocate = an ICMPv6 type number either. It=E2=80=99s kind of sad because while = Poly1305 is not a good PRF, ChaCha20 is. But unfortunately it=E2=80=99s = not a good PRF for IKEv2 as it requires a constant-size key, and RFC = 7296 requires that all PRFs support any size key. Of course we could add = the blake2 hash function to convert any non-256-bit key to a 256-bit = key, and blake2 is based on the ChaCha20 block function. But we chose = not to do this. At least not yet. Yoav From nobody Mon Apr 27 16:49: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 7B3B51ACD61 for ; Mon, 27 Apr 2015 16:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM14uY9dK3O6 for ; Mon, 27 Apr 2015 16:49:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DE91ACD5C for ; Mon, 27 Apr 2015 16:49:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lbNB62pztz471; Tue, 28 Apr 2015 01:49:34 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=UR7dDvbB 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 L6zNrD844lAO; Tue, 28 Apr 2015 01:49:33 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Apr 2015 01:49:33 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 54500807D4; Mon, 27 Apr 2015 19:49:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1430178572; bh=lPsscw1IJzyPwPIQJbcvnQ1qQM8LGeax02ELcJ8ke5E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UR7dDvbB6Upw7fIlIGgo0n1ypB01kvR6mPMebBQ8nccb5WeqKEip+MRJfGM5PPD0K 0GAwOH6cF7E9IUj5zg32BwzXlc4M9lkjoWokvTdBdsr/8qxGg4k27uHhJUbWlvn8mA bXsKj9u170Xm1k3Vktj7sinkuV0EAIcd6/s94uxY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t3RNnVAC025864; Mon, 27 Apr 2015 19:49:31 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 27 Apr 2015 19:49:31 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> <17580688-772E-45A0-8107-50014FA425D3@gmail.com> <1430132572.3173.49.camel@martin> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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, 27 Apr 2015 23:49:40 -0000 On Tue, 28 Apr 2015, Yoav Nir wrote: > This is actually quite unfortunate text. Fields must be aligned to block size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 bytes would be totally arbitrary, yet that is what the MUST requirement in the first bullet seems to be saying. I don’t even know what “proper alignment” means for a cipher such as this. If anything is proper alignment, then the value that fulfills the SHOULD requirement is zero (with no padding bytes). For section 3, I could add a text that echoes the second bullet: > > The sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding. > > Sounds good? Not really? Choices like that make me nervous that an attacker can tweak the padding option. Who knows what oracle that can become in the future. There MUST only be one way to do things. So I would rather see: The sender MUST NOT include padding and set the Pad Length field to zero. The receiver MUST reject a non-zero Pad Length field. Paul From nobody Mon Apr 27 20:51: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 960F41ACE56 for ; Mon, 27 Apr 2015 20:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Zbnv6_GzbFGs for ; Mon, 27 Apr 2015 20:51:50 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 31A5F1ACE55 for ; Mon, 27 Apr 2015 20:51:50 -0700 (PDT) Received: by widdi4 with SMTP id di4so13255962wid.0 for ; Mon, 27 Apr 2015 20:51:49 -0700 (PDT) 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=n9INcM32juKfVXRumOlXLT53VPmVLgH8jaxi+Tr+Tho=; b=v5WxIgxd3+HoSYNZuvAwpgxhL6qEDcPPMj9V9u184HXIApOn6whowIxWS4yFazX7YJ NpUl+UAPUGeSf16w4NVVge6nrt9puS4hjDgw5vPEMVlWCTi/Fp/FdO7bMroMgxeKdtGW QURaoGT0gBXJEpzPcjTvXKb8sz7a23ZQhACLylRCBaj0tuMj6uy0J4VroSQlgb7fwF3y n90wuMysMBwILksxvl7U3w8HtbLmMR+XnS9ihL/ciMXWmYsD4fRc4PnhpFm9Rrul930y EIsbHJS7B46JSlgYTr1wgNDnpe8GyqhVyPdD2kE2koip+h2eWsUKnoTFqo0ul4l9iWJZ u1Eg== X-Received: by 10.194.234.38 with SMTP id ub6mr28778390wjc.9.1430193108985; Mon, 27 Apr 2015 20:51:48 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id e10sm14294922wij.11.2015.04.27.20.51.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 20:51:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Tue, 28 Apr 2015 06:51:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> <17580688-772E-45A0-8107-50014FA425D3@gmail.com> <1430132572.3173.49.camel@martin> To: Paul Wouters X-Mailer: Apple Mail (2.2098) Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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, 28 Apr 2015 03:51:57 -0000 > On Apr 28, 2015, at 2:49 AM, Paul Wouters wrote: >=20 > On Tue, 28 Apr 2015, Yoav Nir wrote: >=20 >> This is actually quite unfortunate text. Fields must be aligned to = block size only for CBC. Aligning AES-GCM to 16 bytes and = ChaCha20-Poly1305 to 64 bytes would be totally arbitrary, yet that is = what the MUST requirement in the first bullet seems to be saying. I = don=E2=80=99t even know what =E2=80=9Cproper alignment=E2=80=9D means = for a cipher such as this. If anything is proper alignment, then the = value that fulfills the SHOULD requirement is zero (with no padding = bytes). For section 3, I could add a text that echoes the second bullet: >>=20 >> The sender SHOULD include no padding and set the Pad Length field to = zero. The receiver MUST accept any length of padding. >>=20 >> Sounds good? >=20 > Not really? >=20 > Choices like that make me nervous that an attacker can tweak the = padding > option. Who knows what oracle that can become in the future. There = MUST > only be one way to do things. So I would rather see: >=20 > The sender MUST NOT include padding and set the Pad Length field = to > zero. The receiver MUST reject a non-zero Pad Length field. I=E2=80=99m OK with that as well, (though I would phrase it in the = positive =E2=80=9CThe sender MUST include no padding and set =E2=80=A6=E2=80= =9D), but that goes against RFC 7296. Specifically your second sentence = turns a =E2=80=9CMUST accept=E2=80=9D into a =E2=80=9CMUST reject=E2=80=9D= . Yoav From nobody Tue Apr 28 00:04:01 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 6B5E31A09C9; Tue, 28 Apr 2015 00:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ImMQeKIJ9KeL; Tue, 28 Apr 2015 00:03:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 508AD1A047A; Tue, 28 Apr 2015 00:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150428070358.24672.1254.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 00:03:58 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-06.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: Tue, 28 Apr 2015 07:03:59 -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 : ChaCha20, Poly1305 and their use in IKE & IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-06.txt Pages : 11 Date : 2015-04-28 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange protocol (IKEv2) and for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-06 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 28 00:14: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 42E621A1A04 for ; Tue, 28 Apr 2015 00:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 s5WIkNZQ_5Y1 for ; Tue, 28 Apr 2015 00:14:42 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 4D9871A1A11 for ; Tue, 28 Apr 2015 00:14:42 -0700 (PDT) Received: by wgin8 with SMTP id n8so140420397wgi.0 for ; Tue, 28 Apr 2015 00:14:41 -0700 (PDT) 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=k8LeR5iRCW8G7aCxaxzYGClN/A2wew0XIyIg9ob78UQ=; b=Jp9FG9N/aJNYBCE74ZtK2/9mVhX1RPwNnCk+Nn4Ubgkd4gSmTxGXVGpGZvUxytBjK2 Xtdo1EmxY9lnXzxW+IOuvKIlp1FW+WoOLkUN8DEd8EBq4VDulId8glhTgBcvFUHJViys Sfny4ccb8PMdU+QPHPfulnWWi28Sqc4/PzhQHCm/tvsixjtsaXdcw89asTge27c6l91W xPd35KfkjmwkjvvSI5USQVsooDlfgrsaSyFZljXVes36ji8BUk7TZB6qjI1cQNZ5vuOB 3DSig+5zP3yWQ74gmWQaDCxlh3b1CuVDePjGXuXJcwomZTbqh66DmviGofju5GGidWAs E3bw== X-Received: by 10.194.171.199 with SMTP id aw7mr28773486wjc.64.1430205280986; Tue, 28 Apr 2015 00:14:40 -0700 (PDT) Received: from [172.24.248.247] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id cf12sm32686316wjb.10.2015.04.28.00.14.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 00:14:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <20150428070358.24672.1254.idtracker@ietfa.amsl.com> Date: Tue, 28 Apr 2015 10:14:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7C3AA02F-9BF1-4A28-97D4-D47E9B771037@gmail.com> References: <20150428070358.24672.1254.idtracker@ietfa.amsl.com> To: IPsecME WG X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-06.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, 28 Apr 2015 07:14:44 -0000 Hi Changes include: - Clarified keying material derivation for IKE - Calrified that IV is included in the Encrypted payload - Fixed the requirements for padding in the Encrypted payload so as not = to require padding bytes. - Added a paragraph on the (non-)secrecy of the Salt based on = discussion in the TLS mailing list - Fixed some errors in the examples (thanks to Steve Doyle and Martin = Willi) Those examples are all synthetic, generated by calling the same ChaCha20 = / Poly1305 implementation that I made for creating the examples in the = CFRG draft. They were not created with an IKE daemon or a IPsec driver, = so they are prone to such errors. I did *not* include the suggestion by Paul Wouters to tighten up the = requirements for generating and parsing padding in the IKEv2 encrypted = payload, as this changes the SHOULD in RFC 7296 to a MUST for the = sender, and a =E2=80=9CMUST accept any=E2=80=9D to =E2=80=9CMUST NOT = accept any except=E2=80=9D for the receiver. I don=E2=80=99t want to = make such a change without the WG telling me to. Yoav > On Apr 28, 2015, at 10:03 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IKE & = IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-06.txt > Pages : 11 > Date : 2015-04-28 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > the Internet Key Exchange protocol (IKEv2) and for IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-06 >=20 > A diff from the previous version is available at: > = https:https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-chacha20-poly= 1305-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Apr 28 01:00: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 677231A1A48 for ; Tue, 28 Apr 2015 01:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_NONE=-0.0001] 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 FJOch24JAg7l for ; Tue, 28 Apr 2015 01:00:15 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4091A1A4B for ; Tue, 28 Apr 2015 01:00:13 -0700 (PDT) Received: from [192.168.1.118] (143.204.173.83.static.wline.lns.sme.cust.swisscom.ch [83.173.204.143]) by mail.strongswan.org (Postfix) with ESMTPSA id 0D0D4400D8; Tue, 28 Apr 2015 10:00:37 +0200 (CEST) Message-ID: <1430208010.3107.16.camel@martin> From: Martin Willi To: Yoav Nir Date: Tue, 28 Apr 2015 10:00:10 +0200 In-Reply-To: References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> <17580688-772E-45A0-8107-50014FA425D3@gmail.com> <1430132572.3173.49.camel@martin> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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, 28 Apr 2015 08:00:16 -0000 Hi Yoav, > I don’t even know what “proper alignment” means for a cipher such as > this. If anything is proper alignment, then the value that fulfills the > SHOULD requirement is zero (with no padding bytes). For section 3, I > could add a text that echoes the second bullet: > > The sender SHOULD include no padding and set the Pad Length field to > zero. The receiver MUST accept any length of padding. I agree, and think that text is fine. > > So I think Next Payload should be Notify (0x29). > > Yes, you’re right. I’ve fixed this in my working draft. I should > publish again in a day or two. Great. I can confirm that both the ESP and the IKEv2 examples in -06 now match the output of my test cases. I think the draft looks fine now, and I support to go on with it. Kind regards Martin From nobody Tue Apr 28 06:09:53 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 AD1231A9116 for ; Tue, 28 Apr 2015 06:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5kXJOgwpmXG0 for ; Tue, 28 Apr 2015 06:09:50 -0700 (PDT) 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 05D4F1A9105 for ; Tue, 28 Apr 2015 06:09:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D2F72002A; Tue, 28 Apr 2015 09:21:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 808E763B86; Tue, 28 Apr 2015 09:09:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 65E4C63784; Tue, 28 Apr 2015 09:09:48 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <8B5A864D-C045-43AA-81C8-286FD8AE265E@gmail.com> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <22826.1430148304@sandelman.ca> <8B5A864D-C045-43AA-81C8-286FD8AE265E@gmail.com> 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: Cc: IPsecME WG Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 28 Apr 2015 13:09:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: >> Is this diagram correct: some comment on the accuracy of my diagram would be appreciated :-) >> I think that the IANA considerations of ipsecme-chacha20-poly1305 >> should say >> something like, >> "According to cfrg-chacha20, Poly-1305 is not suitable for >> use as a PRF for IKEv2, and this specification explicitely >> does not allocate a code point for that.=E2=80=9D > That=E2=80=99s kind of a weird thing to write. We don=E2=80=99t alloc= ate an ICMPv6 type > number either. It=E2=80=99s kind of sad because while Poly1305 is not= a good > PRF, ChaCha20 is. But unfortunately it=E2=80=99s not a good PRF for I= KEv2 as it > requires a constant-size key, and RFC 7296 requires that all PRFs > support any size key. Of course we could add the blake2 hash function > to convert any non-256-bit key to a 256-bit key, and blake2 is based = on > the ChaCha20 block function. But we chose not to do this. At least n= ot > yet. I predict that in two years, there will be a stream of queries from @gmail/@hotmail accounts asking in broken english why there isn't a PRF number. I'll bet we even get an Errata filed :-) The bit about ChaCha also being wrong would be useful to write down somewhere. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVT+GnICLcPvd0N1lAQL0bQgAkOefXg/Hi3k5El+MEfszzVkHRtZ5gYwo Ir/Frgry4Z0cIt7QMKWKkHU7v/W8vsWsqfdSqCr9v2nlx20fZ94ux1mP7pmI75kw D4D7ohXmLQ+yy9oomr6ft7O+BIF21nWYG2lyxwz5SR/7wikDs1sFzlPxFXzCmaCt Hj8z3UHtxWTAQadmrUUsWR9kgNDNlpYkKS/KMDEijyze7ohwFNTuN9Sbo4lsel73 BIkQeO0QjSO9EqjpxmxI06hbGMLaX/GgpnbFscevp8EpIGG9NB0+P73z19LBdzF+ 93N4IlZqZsoSndvpMF3fkX7mAvJ8m+29xsdeEIVOYXAo22bLRKIH0A== =yfhm -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 08:17:15 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 21B7B1A8792 for ; Tue, 28 Apr 2015 08:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KOYw9EU2hguI for ; Tue, 28 Apr 2015 08:17:09 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0BB1A875E for ; Tue, 28 Apr 2015 08:17:09 -0700 (PDT) Received: by widdi4 with SMTP id di4so144577636wid.0 for ; Tue, 28 Apr 2015 08:17:08 -0700 (PDT) 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=nD3LhjQxjtp3c3V/4t7YZ9SfynUD/XaT0y9mwdAX3Ak=; b=sVrtpJiCJP1r8Xaku21xjdPIDgkmJJCqVa5Hmi6q9X3fy3ScVqZXzmnIh7diufAgFE 8h3OUjerXx7gYmw0Z733W/guSIOsm/brg/G2RLoNPrtzr5K9dBg4pADC0V4B6o4ad4IL lMn55T1O91sZYQ+drKd+G209LawFeOdB20OEqL/WpaSkX+qZR32qtCuGvhFqsJs31I4Q zog6nwmpQBstzqJd4lwRd4H+dmxhXuJ4oVs5rloV2FoOeZQM1xffc8Ijv1o9QA47S8Rc w9ipQy6mRsHLeI3EI1rNbn/GzXN9ZxXjyY/4tOB1GPKDxRISCqh3Zhaun35ZiDCdC+x5 BO4A== X-Received: by 10.180.8.34 with SMTP id o2mr90582wia.18.1430234228039; Tue, 28 Apr 2015 08:17:08 -0700 (PDT) Received: from [172.24.248.247] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id w5sm16869925wiz.11.2015.04.28.08.17.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 08:17:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <2738.1430226588@sandelman.ca> Date: Tue, 28 Apr 2015 18:17:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1DC0A81B-6F62-4283-AA6E-273927B5DF36@gmail.com> References: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> <74CD54CA4B3441EC829DB0116C7CDB6E@buildpc> <22826.1430148304@sandelman.ca> <8B5A864D-C045-43AA-81C8-286FD8AE265E@gmail.com> <2738.1430226588@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 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, 28 Apr 2015 15:17:14 -0000 > On Apr 28, 2015, at 4:09 PM, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >>> Is this diagram correct: >=20 > some comment on the accuracy of my diagram would be appreciated :-) I=E2=80=99ll get to that later. >=20 >>> I think that the IANA considerations of ipsecme-chacha20-poly1305 >>> should say >>> something like, >>> "According to cfrg-chacha20, Poly-1305 is not suitable for >>> use as a PRF for IKEv2, and this specification explicitely >>> does not allocate a code point for that.=E2=80=9D >=20 >> That=E2=80=99s kind of a weird thing to write. We don=E2=80=99t = allocate an ICMPv6 type >> number either. It=E2=80=99s kind of sad because while Poly1305 is not = a good >> PRF, ChaCha20 is. But unfortunately it=E2=80=99s not a good PRF for = IKEv2 as it >> requires a constant-size key, and RFC 7296 requires that all PRFs >> support any size key. Of course we could add the blake2 hash function >> to convert any non-256-bit key to a 256-bit key, and blake2 is based = on >> the ChaCha20 block function. But we chose not to do this. At least = not >> yet. >=20 > I predict that in two years, there will be a stream of queries from > @gmail/@hotmail accounts asking in broken english why there isn't a = PRF > number. I'll bet we even get an Errata filed :-) But we=E2=80=99re not even creating an AUTH entry=E2=80=A6 > The bit about ChaCha also being wrong would be useful to write down > somewhere. = https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10#section-2= .7 Yoav From nobody Tue Apr 28 08:53:00 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 5C5271A88A4 for ; Tue, 28 Apr 2015 08:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rGzM4vjPdJUk for ; Tue, 28 Apr 2015 08:52:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F76D1ACED6 for ; Tue, 28 Apr 2015 08:52:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 41FD02016A; Tue, 28 Apr 2015 12:04:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B5F2863B86; Tue, 28 Apr 2015 11:52:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9EA7263784; Tue, 28 Apr 2015 11:52:19 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <7C3AA02F-9BF1-4A28-97D4-D47E9B771037@gmail.com> References: <20150428070358.24672.1254.idtracker@ietfa.amsl.com> <7C3AA02F-9BF1-4A28-97D4-D47E9B771037@gmail.com> 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: Cc: IPsecME WG Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-06.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, 28 Apr 2015 15:52:58 -0000 Yoav Nir wrote: > Changes include: > - Clarified keying material derivation for IKE > - Calrified that IV is included in the Encrypted payload > - Fixed the requirements for padding in the Encrypted payload so as not to require padding bytes. > - Added a paragraph on the (non-)secrecy of the Salt based on discussion in the TLS mailing list > - Fixed some errors in the examples (thanks to Steve Doyle and Martin Willi) > Those examples are all synthetic, generated by calling the same > ChaCha20 / Poly1305 implementation that I made for creating the > examples in the CFRG draft. They were not created with an IKE daemon or > a IPsec driver, so they are prone to such errors. I read the diffs, and find they all make sense. From nobody Thu Apr 30 08:06: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 137921A1B5C for ; Thu, 30 Apr 2015 08:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RUcgIKjsGmUN for ; Thu, 30 Apr 2015 08:06:55 -0700 (PDT) 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 B37041B2CC6 for ; Thu, 30 Apr 2015 08:05:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 578D9203AF for ; Thu, 30 Apr 2015 11:17:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E87A963B86; Thu, 30 Apr 2015 11:05:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D4DC763784 for ; Thu, 30 Apr 2015 11:05:31 -0400 (EDT) From: Michael Richardson To: ipsec In-Reply-To: References: <20150426204834.30917.7546.idtracker@ietfa.amsl.com> <17580688-772E-45A0-8107-50014FA425D3@gmail.com> <1430132572.3173.49.camel@martin> 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: Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.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: Thu, 30 Apr 2015 15:06:57 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > Choices like that make me nervous that an attacker can tweak the padding > option. Who knows what oracle that can become in the future. There MUST > only be one way to do things. So I would rather see: > The sender MUST NOT include padding and set the Pad Length field to > zero. The receiver MUST reject a non-zero Pad Length field. No, the sender should be able to add as much padding as they want whenever they want. And "reject" is the wrong operation (that implies an ICMP or other messages). If you want to say something, the correct operation is ignore (=silently drop). If the attacker can tweak the padding, they must be inside of the sender, IPsec has the padding inside the encryption and authentication, unlike some other algorithms. This is necessary to defeat traffic analysis where one looks at timing of very short packets (which might be keystrokes). It also lets the sender send a NH=0 chaff packet with a bunch of padding so that it looks like a real data. -- 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) iQEVAwUBVUJEu4CLcPvd0N1lAQIceggAtW9pIb7HPqZslRx+NhY6IJU73+r4q0+t WWqDafYv8jzZn9mm/WMjTswQ2uLwg/jaG2UEdHCWG7Qk+Kjfpft3Aw71L8r+0CDe tAPe7N86oYQNGKeDajbIcMtKsLf16ZTIE3dz2aVsUs7ZhG2RmlTe24AhRQ8ld7wI qiCvSW3mktUo/PW3l9wzLbrRL2UF+JFECo3gPW+/EDa4rbQGpl5zkHsf9fh6lRZU JqBneSyiLNLg2+4xM1qFhiINcX2KSJqVcjmf9K/BvUOYAfFWhsJsNmd2ioM1cE2A +xldwKgf5mbJIVXPORsJeuBqglw/C34zUzexbSz7EOsOczeiQBEGzA== =rRKo -----END PGP SIGNATURE----- --=-=-=--