Re: [TLS] Confirming Consensus on supporting only AEAD ciphers

Michael StJohns <> Tue, 29 April 2014 17:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 84CE21A0933 for <>; Tue, 29 Apr 2014 10:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q04a5XtZrf8j for <>; Tue, 29 Apr 2014 10:46:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 413C01A0927 for <>; Tue, 29 Apr 2014 10:46:02 -0700 (PDT)
Received: by with SMTP id a108so616318qge.4 for <>; Tue, 29 Apr 2014 10:46:00 -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 :content-transfer-encoding; bh=5pVD/sSAN2FXrVtrojZVlThVqI6Df+EPHatnj+m3fnQ=; b=QdYZdvMyJAiKNQ5dTULUereL0wcneXBWMz9rpqwpvA2WpOdOsSiq4S8fKp4+obXQIv t0mDrez5ltxxjNkjFz9HlVePBFDP48nMC+UlTnLw1zxsqbcY6GZ6qLeazX1X6TKSwpX0 kCosC20k9vz/E83uU/xETJi+qPte8Aw932Ka86vnBvJVLAhoerZqCDF9EO+rolt6yJ2c Fvq9mPf+lpjf2NM2UPRFFc3uUqmiGH2jakZpsPnIKzO27m9E0VI7gnZyfEXGaPk2kBB5 qcgY55VBDiHvORFiOpj/A53uBkTyzL2a0GenKBh5Vbg40Jj8WeP8sXJCXMehCvcyVsS+ EEbw==
X-Gm-Message-State: ALoCoQkHxmuF/OIoFWeruX0z8PdGQTdymcHfzDdE977OhoUUFY/kMgu8w5zmgx89KGuQiM30AEKk
X-Received: by with SMTP id gz10mr1114193qcb.19.1398793560718; Tue, 29 Apr 2014 10:46:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id o16sm4735496qax.23.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 10:45:59 -0700 (PDT)
Message-ID: <>
Date: Tue, 29 Apr 2014 13:46:00 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers
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, 29 Apr 2014 17:46:07 -0000

On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote:
> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github.

Sorry - I'm coming late here.  Does this also imply the complete 
elimination of the integrity only cipher suites?

With respect to the AEAD approach and with respect to composited AEAD 
cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman 
for example), does this also imply that the key expansion phase will 
never be used to generate MAC keys, and that the cipher suite has to 
provide whatever mechanisms that are required to split the AEAD key into 
underlying encryption/integrity keys if required?

Next (reading from the commited editors copy), this refers to 5116 which 
uses a one-size fits all approach that doesn't really fit all sizes, 
especially for composited AEAD.  E.g.  the draft describes this 
generally as an incrementing value.  For AEAD suites that comply with 
5116, that should be part of the suite specification - not TLS.  For 
TLS, this just needs to be an normatively opaque, per-message field.    
Instead,  place an Informative section which recommends how to do this 
with AEAD suites that currently exist.

  And finally, as I've noted many times before, deriving IV/nonce 
material from the master_secret at the same time as deriving keys is not 
securely supportable in hardware.

> Joe
> [For the chairs]
> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <> wrote:
>> TLS has supported a number of different cipher types for protecting the record layer.   In TLS 1.3 these include Stream Cipher, CBC Block Cipher and AEAD Cipher.  The construction of the CBC mode within TLS has been shown to be flawed and stream ciphers are not generally applicable to DTLS. Using a single mechanism for cryptographic transforms would make security analysis easier.   AEAD ciphers can be constructed from stream ciphers and block ciphers and are defined as protocol independent transforms.  The consensus in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014.
>> Thanks,
>> Joe
>> [Speaking for the TLS chairs]
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list