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

Michael StJohns <> Wed, 18 March 2015 15:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC5DA1A1AE3 for <>; Wed, 18 Mar 2015 08:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d92tjisZEhG7 for <>; Wed, 18 Mar 2015 08:31:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 091CA1A00B2 for <>; Wed, 18 Mar 2015 08:31:43 -0700 (PDT)
Received: by qgh62 with SMTP id 62so39973884qgh.1 for <>; Wed, 18 Mar 2015 08:31:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 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 with ESMTPSA id d85sm11994571qkh.45.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 08:31:41 -0700 (PDT)
Message-ID: <>
Date: Wed, 18 Mar 2015 11:31:44 -0400
From: Michael StJohns <>
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 <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> <> 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 end up 
in TLS cipher suites at some point?  Of these, which require per-message 
IVs that can't be generated as above?

> Cheers