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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 188941A1B1E for <>; Wed, 18 Mar 2015 08:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kl66dN6p-dOP for <>; Wed, 18 Mar 2015 08:48:38 -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 04FEC1A1ADD for <>; Wed, 18 Mar 2015 08:48:38 -0700 (PDT)
Received: by qcbjx9 with SMTP id jx9so2836401qcb.0 for <>; Wed, 18 Mar 2015 08:48:37 -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; bh=QDzUaqvoHZUSM6xg1AYRuxxsKkrGOCCsVXp5kbu8Taw=; b=Ey66OVF6tBSxx8XGDMS8Nb/YOqghPgoAqg13onm8+XkapXvEd4kFUby5FIv+8kh+Fk 5JhTxqCW/gwx/OtrxlUL45MMtyj5Ic+5+zL7Zl1FDTUDcsAIWnK924r9qYcLQA9ZDPt2 BGrjoKtJkutN4l5C/K6YZwHlJe3lYvYSGOmIq5t4/efSzzp4gfAMoFzmjQROS/TgVQO1 /qEYT1IVbBUwFdApOg1q3AOxJIQMLC302i3Scm82KlVkh5LYQbj7IiEWKEbfpzVEcNZL 4Yh9aTeLkj7YPeFEsTyXrT1KWMXj2sflouZo0Vuxd3ZsHTojvQDOnhWtPPxiis/tnz0I K5Ew==
X-Gm-Message-State: ALoCoQkNsgihE9osd7/NmUIBl03uF1qFmqohO6IBfH7U7pZpo75IorXLi2X0rWK5eIPQ6vayinzP
X-Received: by with SMTP id i83mr98820139qkh.28.1426693717223; Wed, 18 Mar 2015 08:48:37 -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 d135sm11121717qhc.7.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 08:48:36 -0700 (PDT)
Message-ID: <>
Date: Wed, 18 Mar 2015 11:48:39 -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: Eric Rescorla <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050000020400050109020306"
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:48:41 -0000

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.

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.

So being clearer - using Session Nonce for the value that's the same 
with all messages and using IV (which is also a per-message Nonce for 
CCM and GCM and should be described as such) for the value used to 
initialize the per-message encryption/decryption/sign/verify would 
probably make things clearer rather than trying to figure out *which* 
Nonce we're talking about.

>     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.

Yup.  Forgot about that.  Mainly because I thought implementers were 
interpreting the "

The nonce_explicit MAY be the 64-bit sequence number." as if the GCMNonce package/explicit IV could be omitted.  Didn't actually make sense not to do it that way.

For this you're going to set the "SALT" to all zeroes instead of getting them from the IV field of the master secret expansion  - correct?

>     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.


> -Ekr
>     Mike
>     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 list
>>  <>
>     _______________________________________________
>     TLS mailing list
> <>