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

Manuel Pégourié-Gonnard <mpg@polarssl.org> Tue, 06 May 2014 17:27 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435B21A0269 for <tls@ietfa.amsl.com>; Tue, 6 May 2014 10:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.394
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUQAmQwAGNLl for <tls@ietfa.amsl.com>; Tue, 6 May 2014 10:27:37 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0BC1A0268 for <tls@ietf.org>; Tue, 6 May 2014 10:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; 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 thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Whj8k-0002j2-Cu; Tue, 06 May 2014 19:26:52 +0200
Message-ID: <53691B7B.3070100@polarssl.org>
Date: Tue, 06 May 2014 19:27:23 +0200
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@polarssl.org>
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 <msj@nthpermutation.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535FE558.2090306@nthpermutation.com> <C7763F74-94D4-4E18-86FC-F0E70488B5BD@cisco.com> <53690B4B.5060507@nthpermutation.com>
In-Reply-To: <53690B4B.5060507@nthpermutation.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WOrjhXDEXzrsir3zvBmY_pHMfG8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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] 
>> <http://tlswg.github.io/tls13-spec/#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.

Manuel.