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

Eric Rescorla <> Wed, 18 March 2015 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2700B1A1B7A for <>; Wed, 18 Mar 2015 08:59:26 -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 FmF9jZl2nT2g for <>; Wed, 18 Mar 2015 08:59:21 -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 9F4AF1A1B13 for <>; Wed, 18 Mar 2015 08:59:20 -0700 (PDT)
Received: by weop45 with SMTP id p45so35951559weo.0 for <>; Wed, 18 Mar 2015 08:59:19 -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=20MI371EFPCjEi3Dr9g6GNagMpdXj5cMU4D+14TsncM=; b=EWIRXOEz64+8MTTWZ9hL9YAQELCyTJTAQaLTS9N+KcrXmeKNSerOW5tgNQ/yEXxFHI Zi9k2B9w5/cTklu58Z1fjz3zd1kvkbVGvHX0Xyl3s5Vl8HnR1E6UDzMZK7GJmLFeIxIv 3kqiyyZUnqgMIkBH2iEOlb1MdGRW1urEcuKDZFcmBJtkQyQ6bqMx5cLRR1VBYYI4LHTn 9GxKiyuoUg8fUXsoIhcf5Fk7JMyfLbvMk/Kpm1GVS6wH8rswW8nnmVBDo5H30IeuTlLe 4HPJiEhYaXUlWQ6hIwZmXPDIkQvrDm4aU2AwsxxhkVFoeQIkqk4QFbCjHuaVJHI7HbDo hPDg==
X-Gm-Message-State: ALoCoQlQtTDpyeHs0HLeKjjNCdbPIqqrM+c7jJujjYwzy2VY+XZR6W1375rk/b8grX6bJT+Trah2
X-Received: by with SMTP id gs4mr8058529wib.39.1426694359302; Wed, 18 Mar 2015 08:59:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Mar 2015 08:58:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Wed, 18 Mar 2015 08:58:39 -0700
Message-ID: <>
To: Michael StJohns <>
Content-Type: multipart/alternative; boundary=f46d04451a117d57f40511922a59
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:59:26 -0000

On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns <>

>  On 3/17/2015 2:22 PM, Eric Rescorla wrote:
> On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <>
> wrote:
>>  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-
>       length.
>  In this context, the AEAD function is invoked once for each TLS record
> encryption.
> David used Nonce properly here, but it becomes confusing when taken to
> using the same key with multiple messages.
> Each message ALSO needs a Nonce - e.g. a unique value.  But the other term
> for a per-message nonce is generally an IV.  At the message level a nonce
> is always an IV but an IV isn't always a nonce.

The term in RFC 5116 uses for this input is "nonce". I don't think it's
to use a different term here than is used in RFC 5116. Please note that
all the ciphers here need to conform to the RFC5116 interface, so whatever
the individual ciphers call their nonce inputs is not relevant here.

We form the per-message nonce (e.g. the IV) from the per-session nonce and
> the per-message sequence number and a fixed value.  That's also the
> per-block nonce for the first block.

In this PR there is no fixed value. We simply use the sequence number and
pad to
the left as required, so I don't think there should be much room for