Re: [TLS] Consensus call on Implicit IV for AEAD

Brian Smith <> Sat, 04 April 2015 03:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 08C371A892F for <>; Fri, 3 Apr 2015 20:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4tE7xDDKZbhJ for <>; Fri, 3 Apr 2015 20:17:05 -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 9A53C1A892E for <>; Fri, 3 Apr 2015 20:17:05 -0700 (PDT)
Received: by obbfy7 with SMTP id fy7so106064070obb.2 for <>; Fri, 03 Apr 2015 20:17:05 -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:date :message-id:subject:from:to:cc:content-type; bh=YJqpKfI4IbHuRoHlhUJ1Q6BKSzVJR0D+OUlkOXvCD/Q=; b=UUrl3Rdlw5BcdoX5UMPJdJQqFeEKBalokI9gLcY6MBw32l9blBpG9lTevLCG2I+OkT p/ZsgkPinkNXEkKFS6L5MeY1vv221zvSW6fvJSTfVc3+Y52k9juObmAe863v5q2DvDJr 3905o7Dr7zO0P92V6mwDqYj78gOmLw2P2k4lZr0sy53Ob/5ynEUT7LT+UeE4w/lB0qKL 8kEmTHDh/gTURQqGTwdnIZbZhDb7BfXuBLKPIHs3ICnbjl7ik/MqyGeSywsXFGpAr8Kf tNzf5I+u7ZgflgenzMxASfb6mc83Whz34hxhevBbqndhyWTl5JBufWDMA0axEJck/W/x KMyw==
X-Gm-Message-State: ALoCoQnJHiMiDfVK9KVmtKcnNdDvzBjOujngivAuz1qn7DiM5PaNEmatordtmbt1nu36O4ng+54i
MIME-Version: 1.0
X-Received: by with SMTP id w10mr6290915obf.9.1428117425040; Fri, 03 Apr 2015 20:17:05 -0700 (PDT)
Received: by with HTTP; Fri, 3 Apr 2015 20:17:04 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 03 Apr 2015 17:17:04 -1000
Message-ID: <>
From: Brian Smith <>
To: Joseph Salowey <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Consensus call on Implicit IV for AEAD
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: Sat, 04 Apr 2015 03:17:07 -0000

Joseph Salowey <> wrote:
> In the interim meeting we had consensus to use an implicit IV for AEAD.  The
> proposal was to use the record sequence number and pad with zeros as
> described in pull request 155
> (  This was also
> discussed in the IETF-92 meeting in Dallas along with options to change the
> offset.  The consensus was to stay with the original proposal.  We are
> posting to the mailing list to confirm this consensus. If you have comments,
> please reply by April 17, 2015.

Right now, based on my reading of the draft minutes, it doesn't look
like there was a complete, reasoned discussion of the issue during
IETF 92, nor is it clear to what extent any kind of consensus or
agreement was expressed during the meeting. Perhaps the draft minutes
are incomplete, but the statement that there was a consensus to stay
with the original proposal doesn't seem consistent with draft minutes.

Conversely, there is a clear record of my objection to the
zero-padding mechanism on the mailing list, and there seems to be at
least some mild support for my suggested alternative of deriving the
initial nonce from the keyblock. I think I provided a good
justification for moving to the randomized initial nonce. I think that
the concerns about it being more work to support a randomized nonce in
crypto modules that attempt to enforce a cryptographic boundary are
valid,m but those concerns outweigh the security benefits of starting
with a randomized nonce. I would be happy to work with the people who
expressed that concern to show that a randomized initial nonce can
work well and isn't unreasonably burdensome even in such products.

I've also thought of another reason why it seems useful to start with
a randomized initial nonce: As mentioned previously on this list, in
reality many AES-GCM implementations are far from being constant-time.
As far as I can reason, AES-GCM with predictable nonces, combined with
predictable plaintext and/or chosen plaintext, seem more likely to
attack via side channel attacks than AES-GCM with randomized nonces.
This is another significant advantage of randomization.

Finally, Ilari Liusvaara noted in the previous thread on the topic
that SSH already does exactly what I'm proposing, or very similar.
And, he also noted that IPSEC partially randomizes the nonce, as does
TLS 1.2. It seems like zero padding would be a regression from what
TLS 1.2 does, in terms of security. I find that concerning.

Here's exactly what Ilari Liusvaara wrote in [1]:
> As to what other protocols do with GCM, both SSH and IPSec do derive
> initial nonce out of key block (like TLS 1.2 does).
> As to what other protocols do with GCM, SSH derives a full block and
> increments that. IPSec derives just a prefix (like TLS 1.2).