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

"David Leon Gil" <> Mon, 06 April 2015 01:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 153F01A1B40 for <>; Sun, 5 Apr 2015 18:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.895
X-Spam-Level: *
X-Spam-Status: No, score=1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_WORD2_END_DOLLAR=3.294, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QhWJYEKXjfmc for <>; Sun, 5 Apr 2015 18:35:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BB631A1B47 for <>; Sun, 5 Apr 2015 18:35:15 -0700 (PDT)
Received: by qcyk17 with SMTP id k17so5334045qcy.1 for <>; Sun, 05 Apr 2015 18:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=lHbcfCNJ8Glb/BrunmULDZMBsoX2tfTFtoUC3LANF/M=; b=bUGQxklbh6Obmn+keAyyxtD9pziyT88yRAX1b30dSBNACOkePvNbzhlhC/LUwpmd7M HhrjagGN0C1dT82Vrj4UkPpE3j0NSBRyBWpKpj7r9cOAFrhcWIlVHtxUnPU9P4lvDnDe 2fsNenC6CUsz0c8YN4lU52McfPvNhXVBl45RA3lJ0RjTXkIVaU0MyUzpL2FcixQiJQQq QQtETJRUMKQllNHwSsAW2deKkXz4cCk5FlWne2WlwKdU5A+XWZZ1RvQfgpRKbcBfK2CA 7p3d/3NfIfBTxnqzF+iRNcDofQg+9Fnc0/wR5xwsH/JtnDezyOQ090oIt8A5Sxf/yGX5 iKRw==
X-Received: by with SMTP id i134mr15309992qhc.70.1428284114406; Sun, 05 Apr 2015 18:35:14 -0700 (PDT)
Received: from ( []) by with ESMTPSA id k126sm2190656qhc.42.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Apr 2015 18:35:13 -0700 (PDT)
Date: Sun, 05 Apr 2015 18:35:13 -0700
X-Google-Original-Date: Mon, 06 Apr 2015 01:35:13 GMT
MIME-Version: 1.0
X-Mailer: Nodemailer (0.5.0; +
Message-Id: <1428284113031.414dc341@Nodemailer>
In-Reply-To: <>
References: <>
X-Orchestra-Oid: 1C577474-8A60-441B-B607-A1EB4E50FFAF
X-Orchestra-Sig: 2db57d4dd6a5b45002135bf16e49a20e21fa35bc
X-Orchestra-Thrid: TA0A48A94-F93D-4145-9A0F-E0395A71098E_1497464329329387742
X-Orchestra-Thrid-Sig: 3c3c4fd84f7707b3f19f44ea5bb4465efcd084a5
X-Orchestra-Account: e93509845f7aebbaaed96e49ec387c71ff04dfac
From: David Leon Gil <>
To: Tom Ritter <>
Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1428284113404"
Archived-At: <>
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: Mon, 06 Apr 2015 01:35:17 -0000

In support of Tom, I would note that Namprempre et al.'s EUROCRYPT paper 'Reconsidering Generic Composition' is relevant:

They define a nonce-based AEAD (nAE) scheme as a function (inputs and outputs are bitstrings):

    (n, ad, p) \rarrow (c, t)

and requires that the resulting scheme be IND-CCA$ (?) iff

     $\forall m, \nexist m', = m'.ad \wedge m.n = m'.n \wedge m.p \nea m'.p$

I would strongly suggest that the TLS 1.3 recommendation impose this requirement for any AEAD suites specified in future.


Or, more simply: IVs must be indistinguishable from random bytes. Nonces must simply be unique.

Assuming that the 'IV' input to the TLS AEAD functions is predictable, it isn't an IV. It's a nonce. Please call it that, and disallow ivAE schemes.

Sent using alpine: an Alternatively Licensed Program for Internet News and Email

On Sun, Apr 5, 2015 at 6:10 PM, Tom Ritter <> wrote:

> On 3 April 2015 at 15:34, 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.
> I apologize if I'm mistaken or this has been raised previously, but I
> feel compelled to speak up and not assume it has.
> The record sequence number is predictable. It's not in the clear on
> the wire, but it begins at 0 and increments with every record.
> (Right?)
> This will result in a predictable IV for the AEAD mode.  We have two
> AEAD modes today:
>  - GCM - IV must be unique, being predictable doesn't matter (Right?)
>  - poly1305 - IV/Nonce must be unique, being predictable doesn't matter (Right?)
> But we also don't know what AEAD modes we will add in the future.  I'm
> far from being 'up' on the CAESER competition, but I skimmed the first
> ~10 entries, and one, CMCC  is based on CBC mode. It seems like a
> predictable IV = BEAST.  Am I right in thinking we will be
> pigeonholing ourselves into only allowing AEAD modes that do _not_
> require an unpredictable IV?
> -tom
> _______________________________________________
> TLS mailing list