Re: [TLS] Consensus for AEAD IV

Michael StJohns <> Sun, 26 April 2015 03:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 87E291B34CE for <>; Sat, 25 Apr 2015 20:21:12 -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 x68PxewgynKC for <>; Sat, 25 Apr 2015 20:21:09 -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 9C22A1B34CD for <>; Sat, 25 Apr 2015 20:21:09 -0700 (PDT)
Received: by vnbg129 with SMTP id g129so8130448vnb.4 for <>; Sat, 25 Apr 2015 20:21:08 -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=K+cAeVwCePgYlXmjHgkaMrPkJA/fjJvoKJ2sdrLQW8c=; b=BCydp02kLRm7jFPw75sGP62/FZJW6OYdPwPfsO1JgLsFErMTIMv1jUuP415ViXyEQx 9zxQ0n+7HL8bhvmy+g2luRS7AeIai+4boBoR/eeYpvOiOzqSzI8uPTuI9vl9+Hee04Zh 9CFp86VSHLqtfYUoij5YwbkrsgNPb9aRza3pux4lDda9uyEc+04VrR0MaM4SN3hTyp7C MRxik711XVNqrKKtIlbhuKTTiNByu3BldlqKcJs5ybAuZU4sQMKzliGu3jxzSQdIZTNs SCRrcAb7uu6DTSBQEXuzUd1F9/iYYoe80UyajjZ6941OjQTEFplipS6d4+7XpQxxBfm7 wt2Q==
X-Gm-Message-State: ALoCoQk5pXDrprGz7sKlP3K2DIi6aqTyX20C/giRyzkptZwYIIABYE+ukUS3V/ZQHNJXJUQ3Q/+c
X-Received: by with SMTP id u6mr13235221vds.24.1430018468761; Sat, 25 Apr 2015 20:21:08 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by with ESMTPSA id wp5sm14905730vdb.18.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 20:21:08 -0700 (PDT)
Message-ID: <>
Date: Sat, 25 Apr 2015 23:21:22 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090704080308030002070500"
Archived-At: <>
Subject: Re: [TLS] Consensus for AEAD 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: Sun, 26 Apr 2015 03:21:12 -0000

On 4/24/2015 4:44 PM, Joseph Salowey wrote:
> On Fri, Apr 24, 2015 at 1:00 PM, Martin Thomson 
> < <>> wrote:
>     On 24 April 2015 at 10:10, Joseph Salowey <
>     <>> wrote:
>     > The general consensus on the list seems to prefer to derive "IV"
>     and use it
>     > to make the AEAD nonce less predictable. Most folks seemed to be
>     OK with
>     > this approach.    In Dallas, there was significant support for
>     using the
>     > derived "IV" as a per session XOR mask for the counter.  If you have
>     > objections to this approach please respond on the list by May 1,
>     2015 .
>     You aren't being particularly precise about the process here.
>     I believe that these were the two options that were most debated:
>     a)  nonce = zeroes(N_MIN) XOR counter
>     b)  nonce = HKDF(...., N_MIN) XOR counter
>     Did you mean the latter option?
> [Joe] Yes, the later where the quantity XORed with the counter is 
> derived during the handshake.

In general, APIs for hardware (and software) encryption are set up as 
init, multiple updates and finalize.  The arguments to init are 
generally a handle pointing to the key, a selection of the encryption 
mode and the initialization parameters specific to that mode.  The 
initialization parameters generally include material for the IV 
(obviously not used in ECB), and other mode specific items. For CCM, 
most implementations use the block formatting function described in 
appendix A of the NIST spec and that function uses as input to the 
initialization a "nonce" as well as information about the length of the AAD.

All of the Init data is non-secret information (note that I said handle 
to key, and not key above - the handle is non-secret, the key material 
is secret) and must be shared implicitly or explicitly between sender 
and receiver.

All of that is a long way of saying that making the nonce be some sort 
of output of the HKDF is probably a bad idea as the general use for a 
KDF is to produce secret key material.

A zero session nonce combined with the message sequence number to form 
unique per-key value is acceptable cryptographically - at least for GCM 
and CCM.    (and that's really the same thing as 0 XOR counter as far as 
I can tell).

A randomly generated session nonce concatenated with the message 
sequence number to produce a message nonce is acceptable 
cryptographically and provides no less protection than generating a long 
session nonce and xor'ing the sequence number in to produce the message 

AFAICT b) provides no additional security over a).   The security of CCM 
and GCM is NOT dependent on the secrecy of the IV/Nonce/sequence number, 
only in its uniqueness for a given key, and (b) appears to be trying to 
make the IV secret.

Doing (b) will make it difficult to implement TLS using generic HSM 
functions as there will probably need to be some way of piping the 
secret output of HKDF to be the per message IV.

So I'd prefer (a) - zero session nonce.  If a random session nonce is 
required (why?), then instead use the impedance matching function (e.g. 
the HKDF-Extract or the equivalent) against the client and server randoms:

    session_nonce = LTRUNCATE (HMAC-HASH ("0", client_random | server_ 

    message_nonce = session_nonce | sequence_number


> _______________________________________________
> TLS mailing list