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

Michael StJohns <> Tue, 06 May 2014 16:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85B821A0148 for <>; Tue, 6 May 2014 09:18:21 -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 4FTOpFuLfzRs for <>; Tue, 6 May 2014 09:18:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 77C0F1A00ED for <>; Tue, 6 May 2014 09:18:15 -0700 (PDT)
Received: by with SMTP id l6so5059740qcy.31 for <>; Tue, 06 May 2014 09:18:11 -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 :cc:subject:references:in-reply-to:content-type; bh=mJK9fazX8uyZUq4Gh/bPdoRJpU36WmY3GaWoF0FEiNc=; b=HdqjRk+98gplv/QQTGa2IM9om1+tmUtbBTtakpXuTibjsPoAZnlB2zNCXZHX2QcjiZ cJaFWh1qJMrF184TbeTH1LA798+7nle2d9DlfkQSd6EMkoCgUIrD0lQz3b3tdwO7a1Zy s/XN/+ffGl7Ai28W6AtjEXAGKCaZn1/UJAFSoq6ezlz7n8jVMkebge6+WzweucZBaxLW 0M3d4A2DjZpOP8a1furVdliRLoU7p0Iq8Z9Ink+5+J406WjbaTQGEHsE5AHSI7kKFmti cYgDbhyHZsw+bcool5KtaOs3jTLH1FLjg0TyNjSINBs1dN8Is4IwOW0qbb1J7c1UHIQV P1Bw==
X-Gm-Message-State: ALoCoQlJBFTMiYZ1Kjo03O4uMIcec//9GoBdTzf1EfqBSePf0T+MTkMi6/3g/XnJRV5jn3lOBays
X-Received: by with SMTP id q5mr52439413qgd.43.1399393091412; Tue, 06 May 2014 09:18:11 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j7sm24289349qab.27.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 09:18:10 -0700 (PDT)
Message-ID: <>
Date: Tue, 06 May 2014 12:18:19 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070709000600090405040106"
Cc: "" <>
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, 06 May 2014 16:18:21 -0000

In line

On 5/6/2014 1:32 AM, Joseph Salowey (jsalowey) wrote:
> On Apr 29, 2014, at 10:46 AM, Michael StJohns <> wrote:
>> 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?
> [Joe] Its possible to have AEAD modes that provide only authentication, however I don't think that the currently defined AEAD ciphers support authentication only so its possible that some modification may need to be made to support this.

Actually, both CCM and GCM support authentication only.  Simply provide 
AAD and no plain or cipher text.

But what I probably should have asked was whether we were obsoleting all 
of the current integrity only suites (and I think from what I read in 
other responses the answer is yes), and if so what we were going to 
replace them with?

I don't know that CCM and GCM will be able to fill the existing niches, 
and I don't know that the composited AEAD functions make sense for this use.

>> 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?
> [Joe] Yes, the cipher suite would be responsible for deriving the appropriate keys from the key material it is given.

Note for action:  Provide a generic method for use with composited 
functions that's related to the way session keys are derived. 
Rationale:  KDFs are *hard* to get right.

>> 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.
> [Joe] I think I'm missing your point here. I thought the existing cipher suites did define how the nonce is generated and the TLS document just provides some guidance on nonce generation.

 From the document :

> AEAD ciphers take as input a single key, a nonce, a plaintext, and 
> "additional data" to be included in the authentication check, as 
> described in Section 2.1 of [RFC5116] 
> <>. 

It's unclear to me that a composited AEAD function will always take a 
nonce.  And that the IV from one message to the next will be a simple 
increment of an IV field (e.g. if the underlying encryption mode for a 
composited AEAD function is something like CBC then the IV really needs 
to be more random).

The section in the editors draft uses RFC5116 as its definition 
of how an AEAD cipher needs to look, and that was fine as long as there 
were other ways of looking at ciphers (stream, block), but its unclear 
this section is generic enough to deal with anything except CCM and GCM 
style AEAD ciphers.

My point with this section is to remove 5116 language, and abstract the 
hell out of the AEAD interface into something that will work with more 
than just CCM and GCM.  Or at least I believe this has to be done if all 
but AEAD ciphers are being removed.

>> 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]  So currently with AES-GCM and AES-CCM then nonce is  partially derived from the Client and Server IV.   If I remember correctly the TLS derivation by splitting up the derived key material into secret keys and IVs is problematic.  Can this part of the problem be solved by changing the way TLS derives keys and IVs?

Yup.  I've got a current draft on that.  The issue here is mostly about 
how the IV/nonce is generated as a keyed PRNG approach is problematic in 
a number of ways.

>>> Joe