Re: [TLS] Pull Request: Removing the AEAD explicit IV

Yoav Nir <ynir.ietf@gmail.com> Tue, 17 March 2015 20:19 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768B21A88E0 for <tls@ietfa.amsl.com>; Tue, 17 Mar 2015 13:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 23C_cqW6UGma for <tls@ietfa.amsl.com>; Tue, 17 Mar 2015 13:19:58 -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 A34621A88DE for <tls@ietf.org>; Tue, 17 Mar 2015 13:19:57 -0700 (PDT)
Received: by wixw10 with SMTP id w10so21026575wix.0 for <tls@ietf.org>; Tue, 17 Mar 2015 13:19:56 -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=744jaDWuYdf+b2mZa2CYI8RYxZ8eJjasEV+g2LyyxOM=; b=jxizks1D4OXLhnTwVws3yF5kHOb+Ckfi9l67+uNv2Zj6ljQtrMMQNscyNIf+VTAKa8 cT1nyZ4M80xEroo7Pnw0yyrDNNr/HsUDB6IA2XNb4ljQrsRuGWfKA4HIuF0eR3zblWjM I6fNyu8Ys3kaqsOSkSeaNyTn04U/QgKmwOQtJltXOKlUIekzbyLUV4Le1g2JCUGrathd D2b0JFDvggX91TDIQaq1oUld4RVifs5a4Iko4LlYQkEZssZy4HD1eXfBn9t478c9MOEi PaGtekdzGuQaJnTfPBHLgCs5y+4YXfJNgKVd8MqubKpB3ld5uT4LTKst/Z4lgkws4XRj JJxg==
X-Received: by 10.194.94.1 with SMTP id cy1mr132883554wjb.127.1426623596400; Tue, 17 Mar 2015 13:19:56 -0700 (PDT)
Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id q6sm119298wix.3.2015.03.17.13.19.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 13:19:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAMfhd9VetS=bNeyBeBasRGr9nE8yoRqU7jajKrsOimPqMayWYA@mail.gmail.com>
Date: Tue, 17 Mar 2015 22:19:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E19E2DF5-8ACB-46E8-9A99-DFC2ABA2D288@gmail.com>
References: <CABcZeBPfasM5HmJaATLUHQKRgiSGCreJt1T=UoDBGCbcuzyW8Q@mail.gmail.com> <55086D3C.5090605@nthpermutation.com> <CAMfhd9VetS=bNeyBeBasRGr9nE8yoRqU7jajKrsOimPqMayWYA@mail.gmail.com>
To: Adam Langley <agl@imperialviolet.org>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Cnamtio4NnjFgBaCGZYDjL9HEBM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2015 20:19:59 -0000

> On Mar 17, 2015, at 8:21 PM, Adam Langley <agl@imperialviolet.org>; wrote:
> 
> On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns
> <msj@nthpermutation.com>; wrote:
>> That works for the currently defined pure AEAD modes (CCM/GCM at least,
>> haven't looked at chacha).   Will that work in all cases for constructed
>> AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode and
>> an integrity mode and derive the E and I keys from a single key internal to
>> the constructed mode - say  AES-CBC with CMAC for example).  Short answer is
>> probably not.
> 
> I believe that it will, although I welcome counterexamples.
> 
> The AEAD interface requires only an nonce (i.e. unique, but not
> unpredictable) and, under this proposal, that's all that TLS will
> provide.
> 
> CBC modes require an IV (i.e. unpredictable). If you wished to make an
> AES-CBC-HMAC-SHA256 AEAD, for example, then you would do something
> like this:
> 
> Define the key length to be twice as large as the AES key and split it
> internally into a CBC key and an IV key. For each record, generate the
> IV by AES(key = IV_key, block = nonce) then encrypt the plaintext
> using CBC with that IV and the CBC key. (And you might need extra key
> bytes for the HMAC too, but that's beside the point here.) Basically
> you can generate the IVs using AES-CTR as a PRNG.

Right. Or you could do like in https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 , generate the IV randomly and locally and call it part of the ciphertext (see appendix A). The AEAD interface has no requirement that the ciphertext have the same length as the plaintext. In fact CBC requires padding, so the ciphertext is larger anyway.

I do like your way better, but it requires a larger state on both client and server. 

I’m also wondering if we can mass convert all the existing CBC ciphersuites for TLS 1.3, so that ciphersuite 0x00,0x0a could be TLS_RSA_WITH_3DES_EDE_CBC_SHA in TLS 1.2, but transform into one of these AEAD constructions for TLS 1.3 without having to allocate new identifiers.

Yoav