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

Michael StJohns <> Tue, 17 March 2015 18:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DC0751A87EC for <>; Tue, 17 Mar 2015 11:06:54 -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 yW3R4AxzzbuF for <>; Tue, 17 Mar 2015 11:06:52 -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 31CE51A87DB for <>; Tue, 17 Mar 2015 11:06:52 -0700 (PDT)
Received: by qcbkw5 with SMTP id kw5so16347100qcb.2 for <>; Tue, 17 Mar 2015 11:06:51 -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 :subject:references:in-reply-to:content-type; bh=78fzrsexSCmvDeFkVpND+HBqmbgdDamh4wtlVOSeXvQ=; b=Mtz+BagCEiMzsFmG5WUzCaWL78bHga6eEEJwCc6kF80M1qbvt/AoAQBU45BRvhhpNd LQ42N3EjRRVmzUMeRZwMTzorIwxzpgHgIKwyLyc0SGqpkYZAcx3IdFImh/YIX2NYEawY EE6h3np59rSCMetrTWHVrNHxs+4vLJoMQcCK++2dFUAkrJRRqeI1Y2dozu31lAExiKRL 0H1xFoMG4aNXZNkcRomjrR2ugzHO4PTn6JAYFrdqA1BND94p/hyKTgRUZsauB9RhrkWS DQwVTXZ8OwwCgFqThFAiQMbdPe21IMoCnln01aNGVrDfrlJrQZtZNdEOlX3WFDLOhhTM VgtA==
X-Gm-Message-State: ALoCoQmyZfPEe6Kk7iiirTcBIMaFg6PDcFf3Cil2Y9JcH2vB2JmbGxCZvMlcTKHck7q5zvJCQvVc
X-Received: by with SMTP id t22mr83633987qge.9.1426615611364; Tue, 17 Mar 2015 11:06:51 -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 b74sm10127167qga.40.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 11:06:50 -0700 (PDT)
Message-ID: <>
Date: Tue, 17 Mar 2015 14:06:52 -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
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------000207030406010306070407"
Archived-At: <>
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:06:55 -0000

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?

In original TLS, the IV produced during session setup was actually not 
"the" IV, but "an" IV used for the first message.  Then McGrew's AEAD 
modes repurposed the IV data produced as a nonce for the AEAD modes.

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 

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.


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