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

Manuel Pégourié-Gonnard <> Tue, 06 May 2014 17:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 435B21A0269 for <>; Tue, 6 May 2014 10:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.394
X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uUQAmQwAGNLl for <>; Tue, 6 May 2014 10:27:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C0BC1A0268 for <>; Tue, 6 May 2014 10:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=rxVc9ivBcQvDLAYyebq3TsWjR/AO39aQgfb99xw9D5U=; b=FnqBcWY/4jILGNRo52wHJgQ3lvQhQskEbADrg28RWjUVEIV94ZJ21QMRx3ytivuanEGh9y2D3/HVykuMd8oWovQx16dpKjP6A5BoTdk2MjXF7hf7sbjG1aQQTG1ZKW6TRQJFQLoVute/Rl/CI+EsGXB/FORIN7oGuJHp5CVJPXI=;
Received: from ([] helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1Whj8k-0002j2-Cu; Tue, 06 May 2014 19:26:52 +0200
Message-ID: <>
Date: Tue, 06 May 2014 19:27:23 +0200
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Michael StJohns <>, "Joseph Salowey (jsalowey)" <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on
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 17:27:38 -0000

On 06/05/2014 18:18, Michael StJohns wrote:
> 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.
It seems to me there should be no problem defining new functions
NULL-HMAC-SHAXXX fitting the the AEAD interface (though the "E" would not really
mean encryption) that would do exactly the same as the current NULL ciphersuites.

Am I missing something?

>  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.

Not taking a nonce can probably be seen as taking a nonce of length zero. So,
AEAD constructs without nonces would define SecurityParameters.record_iv_length
and SecurityParameters.fixed_iv_length as 0.

>  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).
I may be misunderstanding the document, but I'm under the impression that
incrementing the IV (or a field inside it) is only a suggestion. More precisely:

> Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD
> operation is constructed,

seems to imply an AEAD suite can specify another method.

> 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.
I agree that we should really make sure that the AEAD interface used covers all
the constructs one might want to use. But right now I don't see where more
generality would be needed.