Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt

Yoav Nir <ynir.ietf@gmail.com> Tue, 07 October 2014 16:49 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0C1ACE24 for <cfrg@ietfa.amsl.com>; Tue, 7 Oct 2014 09:49:13 -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 Ge2jF4hRgeje for <cfrg@ietfa.amsl.com>; Tue, 7 Oct 2014 09:49:12 -0700 (PDT)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526291ACDA0 for <cfrg@irtf.org>; Tue, 7 Oct 2014 09:49:12 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id m15so9738302wgh.4 for <cfrg@irtf.org>; Tue, 07 Oct 2014 09:49: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=NIElr6Cvae9mbZsUsQX17hi6C/a4/MejPUmcLWuAP1E=; b=nXUlnUwinvV7XjzLj7cftITvJjREqQIm5S+xTt/8c3IoDwuJRJTKannzSmBzLojmf1 9pc33jQjW2NlMPxRlcbiK5pST7dl3niKj38D6nqPtAqHEZfOm+W9MDOMS6lhOkYTDqPz 5Z0wsGfTItb8PkBTEAj6I4ZyZhsiNEkL/+xv+KHU3bfO320Co1hR7GgRxTi1IFFZ+wWj /QYupa3+30d+iKU7OCKq0YeR9u1j84hvV+bshC5tPgk6ci/K7tLEPk7qIu7EzAZo6b3i WcPcnYFePmEJUqZzvv/NRuVuTioLn2T8yrj/70/ieoIJRhvv1regwjDRZqUk4l+xLcAo EANQ==
X-Received: by 10.194.206.103 with SMTP id ln7mr6261479wjc.30.1412700550967; Tue, 07 Oct 2014 09:49:10 -0700 (PDT)
Received: from [192.168.1.104] (IGLD-84-228-54-144.inter.net.il. [84.228.54.144]) by mx.google.com with ESMTPSA id gt7sm15377846wib.18.2014.10.07.09.49.10 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 09:49:10 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <m3k34clwkt.fsf@carbon.jhcloos.org>
Date: Tue, 7 Oct 2014 19:49:08 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C2D2B7D-CB2A-4541-88B8-49B5CCC64CA8@gmail.com>
References: <542D48CD.9060404@isode.com> <m3k34clwkt.fsf@carbon.jhcloos.org>
To: James Cloos <cloos@jhcloos.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/wF1UcCVR0cy8z2De3qrTUac1aug
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-chacha20-poly1305-01.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 16:49:14 -0000

Hi, James

The 96/32 split is dictated by the recommendation in RFC 5116. While any sane use of symmetric keys will never use the same keys for either 2^96 messages or 2^64 messages, being able to safely split the range of acceptable nonces is an advantage. Neither regular IPsec nor regular TLS need this, but multi-sender IPsec (GDOI) and multi-sender DTLS can benefit.

As it is, the current TLS 1.3 draft defines AEAD ciphersuites as those described by RFC 5116. So yes, it’s possible to decide on a 64-bit nonce and state clearly in both this draft and the draft for ChaCha20-Poly1305 for TLS that we’ve decided to ignore the recommendation in 5116, but I don’t think that’s a good idea.

Yoav

On Oct 7, 2014, at 12:25 AM, James Cloos <cloos@jhcloos.com> wrote:

> [I thought I sent on this subect weeks ago, but I cannot find it in
> the archives, ... -JimC]
> 
> I have to object to defaulting to a 96/32 split.
> 
> The rfc should specify Dan's 64/64 split as default, and only offer
> 96/32 as an option.
> 
> Chacha isn't only useful for in-flight encryption.  One should not
> have to bother with multiple keys or IVs to encrypt large files.
> And 128 Gigs is not all that large for things like backups (tar,
> cpio, et cetera), disk images, some AV files and the like.
> 
> It is very reasonable to presume that larger and larger files will
> become more and more common as the storage devices sizes and demand
> for higher resolution media files each continue to escalate.
> 
> The RFC should be a valid reference for all potential uses of chacha.
> 
> Even in the IETF, OpenPGP encrypts files at rest.
> 
> Secsh should continue to use 64/64; OpenPGP and SMIME should add chacha
> with 64/64; I would prefer 64/64 for TLS.
> 
> But if IPSEC insists on 96/32, that should be an option, not the primary
> scenario.
> 
> -JimC
> -- 
> James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6
>