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

Michael StJohns <msj@nthpermutation.com> Wed, 18 March 2015 15:31 UTC

Return-Path: <msj@nthpermutation.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 AC5DA1A1AE3 for <tls@ietfa.amsl.com>; Wed, 18 Mar 2015 08:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 d92tjisZEhG7 for <tls@ietfa.amsl.com>; Wed, 18 Mar 2015 08:31:43 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 091CA1A00B2 for <tls@ietf.org>; Wed, 18 Mar 2015 08:31:43 -0700 (PDT)
Received: by qgh62 with SMTP id 62so39973884qgh.1 for <tls@ietf.org>; Wed, 18 Mar 2015 08:31:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ly+q3Xi7z25E4Qnyo/PqZwukoEKJ45cHh2Vdr02O39w=; b=nE6lPlG7CSHmgXoCQPsesucFOQDebX3Rt4EKGoJILh3IFrettgyZ5Fjyev0SLLWy6p 7l/a6XTkwK/j1zLFTLd1myyHeD9vfPBGY13u1gI0OW31ubtbPzOAgg7Tk6nR0HHUO6oD tv3OQQBwgTcsSQZGjGvwP14h1n0k+RPYUAK9rT2Ipo8NV+LPaFr25FA4YOYj42vpbaDr uBgSLGGDuA246iI9sz99AuC2fFU/x107Fv69PDo7UCXnWWeIvnqi2wsYy23L8dUcOYo3 XoIoZblpdYG6r6G715yB1Z0eGwihpNbO6ePOwve6KirfOYrUIlQd7nZHzgpLR/10lnbN iPFQ==
X-Gm-Message-State: ALoCoQniDJgRrXb8YucaC3rlC73ayL6Z1EZYj9BD289SUuxzcGcdEYtjaqfr7iP7Vim9sfUcnto0
X-Received: by 10.140.150.19 with SMTP id 19mr43987469qhw.69.1426692702291; Wed, 18 Mar 2015 08:31:42 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:381:1ca7:409d:c366:febf? ([2601:a:2a00:381:1ca7:409d:c366:febf]) by mx.google.com with ESMTPSA id d85sm11994571qkh.45.2015.03.18.08.31.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 08:31:41 -0700 (PDT)
Message-ID: <55099A60.5020709@nthpermutation.com>
Date: Wed, 18 Mar 2015 11:31:44 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>
References: <CABcZeBPfasM5HmJaATLUHQKRgiSGCreJt1T=UoDBGCbcuzyW8Q@mail.gmail.com> <55086D3C.5090605@nthpermutation.com> <CAMfhd9VetS=bNeyBeBasRGr9nE8yoRqU7jajKrsOimPqMayWYA@mail.gmail.com>
In-Reply-To: <CAMfhd9VetS=bNeyBeBasRGr9nE8yoRqU7jajKrsOimPqMayWYA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/lhb16sEU8tYN6y36kkpTfKAlQ2Y>
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: Wed, 18 Mar 2015 15:31:45 -0000

On 3/17/2015 2:21 PM, Adam Langley 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.

I wouldn't use AES-CTR to generate IVs for AES-CBC, but I take your 
point.    I was actually asking about more than CBC.  See below.


This is what I got from SP800-38A appendix C
> For the CBC and CFB modes, the IVs must be unpredictable. In 
> particular, for any given plaintext, it must not be possible to 
> predict the IV that will be associated to the plaintext in advance of 
> the generation of the IV.

> There are two recommended methods for generating unpredictable IVs. 
> The first method is to apply the forward cipher function, under the 
> same key that is used for the encryption of the plaintext, to a nonce. 
> The nonce must be a data block that is unique to each execution of the 
> encryption operation. For example, the nonce may be a counter, as 
> described in Appendix B, or a message number. The second method is to 
> generate a random data block using a FIPS-approved random number 
> generator.

But that's what's defined for CBC and will work with the per-session 
nonce with per-message sequence number as described above.

While at this time we've only got defined cipher suites for CBC, CCM and 
GCM, (and I should have stated my comment more to this point), will 
there never be other potential modes that provide some desired security 
characteristics not currently present that also require explicit 
per-message IVs?

Eliminating the message-wrapping down to the AEAD construct is one thing 
as you can build AEAD modes out of other modes.  I wonder that we're 
constraining the protocol so much that other, useful, modes might be 
excluded in the future.   E.g. will any of the modes on this list 
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html end up 
in TLS cipher suites at some point?  Of these, which require per-message 
IVs that can't be generated as above?

>
>
> Cheers
>
> AGL
>
>