Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

Yoav Nir <ynir.ietf@gmail.com> Wed, 08 July 2015 05:37 UTC

Return-Path: <ynir.ietf@gmail.com>
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 883171B30BA; Tue, 7 Jul 2015 22:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RpkVvlYvtqeU; Tue, 7 Jul 2015 22:37:10 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 B97C71B30B9; Tue, 7 Jul 2015 22:37:03 -0700 (PDT)
Received: by wgjx7 with SMTP id x7so185289513wgj.2; Tue, 07 Jul 2015 22:37:02 -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=a0BMse6hGNaGPfZtHghbV3BgVUGwcu0rLHDM2n1dTcU=; b=a1ugDfcTfivQ8jyqkEEQ1dvbge5H/ubDVonHKRsbg0KnsO2GqLZzBD9EHNIANh3DzV I8uB/ShvBfK+wmmSxTt9+/N4CD5X/zxDQpy5uRA2aGijCxFrSIjrFKMygbQyPdjW+q8p c4yUHotPrB/ddl6wJFBOozBSaysE74PzfH7JxbvqXUBJ2Zy0eg9xggsp3AczsEbonO97 mgC/hebjgcBEOMQg3MwvGnSM8Q8vIMBafZJ6UXATZJuqdDf16YtlurGkbtBMtdCFJbvL HWUpKEWNGGSWZe/pRU5GLwEXuDSa5Otr6ksoMhvvr3orVJbNXOasPXcyoIQzT2NjIjyz 4vlQ==
X-Received: by 10.180.24.40 with SMTP id r8mr73162982wif.24.1436333822579; Tue, 07 Jul 2015 22:37:02 -0700 (PDT)
Received: from yoavs-mbp.mshome.net ([176.12.138.59]) by smtp.gmail.com with ESMTPSA id d3sm1307594wic.1.2015.07.07.22.36.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jul 2015 22:37:01 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20150707231501.2664.3995.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jul 2015 08:36:56 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7841E74-01F5-4E8F-A74F-3408F78DF10A@gmail.com>
References: <20150707231501.2664.3995.idtracker@ietfa.amsl.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/SvM5b-exA4ad89NwdXJxp8Wd9IQ>
Cc: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-chacha20-poly1305@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, ipsec@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-ipsecme-chacha20-poly1305.ad@ietf.org, draft-ietf-ipsecme-chacha20-poly1305.shepherd@ietf.org
Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2015 05:37:11 -0000

Hi, Stephen.

See below.

> On Jul 8, 2015, at 2:15 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> intro: "gold standard" is being a bit too keen IMO, I'd say
> toning the language down a bit would be better.

AES is what I get when I’m using IPsec, TLS (at least in browsers and SMTP) and SSH with normal tools. It’s what disk encryption schemes use and what S/Mime uses. Even the DICE profile names AES as the MTI algorithm. Same for the current TLS 1.3 draft and HTTP/2 RFC. When Intel was looking to add a cryptographic algorithm to the general-purpose CPUs, they chose AES. IBM did the same with mainframe CPUs. Any paper describing a new algorithm compares the new algorithms to AES. Even here at the IETF we tend to call anything else “vanity crypto”. I think “gold standard” is appropriate. I guess I could rephrase it as “has become the go-to algorithm for encryption”, although that might be too American an idiom.

> intro: 3DES may be the "only other widely supported" cipher
> for IPsec, but that's not true more generally.

Well, this is a document about IPsec. It’s also true for TLS and SSH. There’s also the occasional Blowfish and Camelia, but 3DES is more common than any of them. There is RC4 and it’s fast, but (1) you can’t use that in IPsec, and (2) you don’t want to use that in TLS and SSH anyway.

> section 2 says: "As the ChaCha20 block function is not applied
> directly to the plaintext, no padding should be necessary."
> That "should" could be confusing as written if a reader thinks
> it means their code doesn't have to do padding. It might be
> better to e.g. say something like "In theory no padding is
> needed for this cipher, however, in keeping with…" 

I take the point, but I don’t like using “in theory”. How about:
   As the ChaCha20 block function is not applied directly to the
   plaintext, the algorithm does not require any padding. However,

> section 3: Is "SHOULD inlude no padding" really right?  I'd
> have thought a MAY was better there.  "MUST accept any length"
> is also a bit odd - what if I (try:-) add loads of padding?

This pretty much follows the text in RFC 7296:
   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.
Since there is no proper alignment requirements for this algorithm, I take that to mean “no padding” but “MUST accept any length”. It’s true that with a single-octet byte length you can’t insert more than 255 octets of padding, but I don’t thin this has to be spelled out.

> Appendices: thanks for those - I assume someone checked them
> for you? (I didn't:-)

Martin Willi (implementer of StrongSwan) did, and pointed out a mistake in a previous version.

Yoav