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

Eric Rescorla <> Tue, 17 March 2015 18:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 266681A1BB9 for <>; Tue, 17 Mar 2015 11:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nVGliuvR3-HU for <>; Tue, 17 Mar 2015 11:22:51 -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 2A2DA1A1B92 for <>; Tue, 17 Mar 2015 11:22:51 -0700 (PDT)
Received: by wibdy8 with SMTP id dy8so70333967wib.0 for <>; Tue, 17 Mar 2015 11:22:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bNVB2UExLgO4Cbbplmxmao4y4SNBuudw+C4Vu8HN3OA=; b=JgQafO2Om8hkI32nIy/hGUndokAxLv62VgM1kpq5tpxxj17qXsA5d7NjJP8xDQXzav vSIzW0TNct0AkwhlypeJfjK9GNRsiAgYT4yTuxWyTPSbDlfE2WeHpGZ8bvON04snUJH9 2X9K6m6mLMO2LktshhHAK2Tn5aRHQyhRpIL7kQ19J0ImM0Av7GkVWIRhPCo/6TSqW9LK nPheaHrkTs88qirGIgaXUsnY75x24jpeaMG87XF/Gpxogd/6A0cjePIQccYtVbrrOOw4 HjzmLardfeWGxboPPkpX9s0xUAsoBb/pSDr7L+YtBSVn4FQk9QolrMV+dvb/uVyZVqMq Xa+w==
X-Gm-Message-State: ALoCoQl4tem9Kv9K0yUj4mqoRYb4ftHO4GwAEFVxVkfoNLJFKFOaR5vREeP5meUdpyNw22M7Hk7b
X-Received: by with SMTP id c9mr197064wie.10.1426616569726; Tue, 17 Mar 2015 11:22:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 17 Mar 2015 11:22:09 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Tue, 17 Mar 2015 11:22:09 -0700
Message-ID: <>
To: Michael StJohns <>
Content-Type: multipart/alternative; boundary=bcaec53d546fde9a290511800d4d
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: Tue, 17 Mar 2015 18:22:54 -0000

On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <>

>  Sorry for being pedantic but...
> The Nonce is the fixed (per connection) part of the quantity of bits that
> are encrypted to produce one block of cipher text that's XOR'd with the
> plain text to produce the encrypted message block.   The Nonce plus the
> message sequence number is the per-message initialization vector.   The
> Nonce plus the message sequence number plus the block number is the per
> block value to be encrypted.   At least for CCM and GCM.
> The Nonce is common across all messages within a session.   (*sigh* the
> more general meaning of nonce is that of a unique per-invocation value but
> given that all per-message/per-block "nonce" usages contain the
> per-connection nonce it would be useful to not overload this too much -
> among other reasons:  an IV is not always a nonce but can be, a nonce is
> not usually an IV but can be, most messages require an IV, most blocks
> don't).  So maybe we call this the "Session Nonce" for clarity?

I realize that the terminology is confusing, but I'm using the terms from
RFC 5116
section 2.1 ( In this
context, the
nonce is not per-connection but rather per AEAD function invocation:

      A nonce N.  Each nonce provided to distinct invocations of the
      Authenticated Encryption operation MUST be distinct, for any
      particular value of the key, unless each and every nonce is zero-

In this context, the AEAD function is invoked once for each TLS record

> So what you're proposing is to eliminate the determination of the Nonce as
> part of the session negotiation and make it a fixed value.  E.g., we have
> an explicit nonce which is always zero which produces a per-message IV
> based on the sequence number of '0's | <sequence counter> | <block
> counter>.  As a side effect that also eliminates the per-message IV field
> (which aren't actually used by the currently defined AEAD modes AFAICT).

AES-GCM uses this field, which is the motivation for this change.

> 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.
> Basically, this complete eliminates the ability to use CBC (or any cipher
> mode that requires an explicit per message IV) from TLS.  Not arguing for
> or against this at this point, but not clear that everyone understands the
> side effects of this decision.

As discussed at the interim, I don't believe that this is correct. See
AGL's message
for a proposed construction.


> On 3/16/2015 7:54 PM, Eric Rescorla wrote:
>  PR:
>  Target merge date: 3/21
>  Currently:
>  - AES-GCM uses a partially explicit nonce
> - The ChaCha20 draft uses the sequence number as the nonce.
>  As Stephen Kent has observed, the idea behind the explicit IV is to
> allow the
> cryptographic module implementing the AEAD algorithm to ensure non-reuse
> of the nonce. However, for ChaCha I believe we came to the conclusion that
> it
> was acceptable to use the sequence number as the nonce, as the module can
> check for sequential usage. This saves 8 octets on the wire.
>  In the interim in Seattle, we came to the conclusion that we should make
> all AEAD algorithms behave this way, which also simplifies the spec some.
> I've formatted this into a PR to verify the consensus on the list. Please
> comment
> here if you object and on the PR if you have editorial comments.
>  -Ekr
> _______________________________________________
> TLS mailing listTLS@ietf.org
> _______________________________________________
> TLS mailing list