[TLS] (offline note) Re: Confirming Consensus on supporting only AEAD ciphers

Rene Struik <rstruik.ext@gmail.com> Tue, 06 May 2014 12:52 UTC

Return-Path: <rstruik.ext@gmail.com>
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 2AE121A02FE for <tls@ietfa.amsl.com>; Tue, 6 May 2014 05:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 AeEhlimAiY-G for <tls@ietfa.amsl.com>; Tue, 6 May 2014 05:52:09 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2541A02F0 for <tls@ietf.org>; Tue, 6 May 2014 05:52:09 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id hl10so6195426igb.17 for <tls@ietf.org>; Tue, 06 May 2014 05:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/9of7c8MnhYWNVqXKPCuXF3n1ZfLlnrQQzWS+3tKxzk=; b=Az7xVEuArk0Iwx6LaC8IXKl3Vu0ZdEQ4J49jdMFgQFqiha+HknHwT/ksm2CyA/nD2P v4Gm+MPhKHdWHhMvZMYc/bRURD0q19qDDuHJI9X41+MN7VOVjZ69pwp81CkepTqrlwgt NP8NoklRij50dafQwDNag8Qyt226kDNsvTIc+AHTfmEq2ByqRNNDI1i3A7ZtB60iXChl C/bv2aM4m9e42CFpKvYA0cRA9VkTZ7UCSiJ/y7rjfh14EjyUGQIabZaJxZHa/pU+wM29 hcyClW3EhbvisdeebvJCjDtLgQGHTfe215IflNU0NOz8qNFGBgtxBf646Ev/jnR0WKWS 2O2g==
X-Received: by 10.50.153.49 with SMTP id vd17mr32373700igb.40.1399380725222; Tue, 06 May 2014 05:52:05 -0700 (PDT)
Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id vc5sm38595692igb.3.2014.05.06.05.52.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 05:52:04 -0700 (PDT)
Message-ID: <5368DAED.3020000@gmail.com>
Date: Tue, 06 May 2014 08:51:57 -0400
From: Rene Struik <rstruik.ext@gmail.com>
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)" <jsalowey@cisco.com>, Michael StJohns <msj@nthpermutation.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>
In-Reply-To: <C7763F74-94D4-4E18-86FC-F0E70488B5BD@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iSd4Sx--qVXr8oi_AiIQxe3ClMM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] (offline note) Re: 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 12:52:11 -0000

Hi Joe:

In general, an AEAD mode takes as input two strings a and m and a key k, 
and authenticates a and m, while encrypting m. If m is the empty string, 
this results in an authentication-only mode.

Thus, AEAD modes can be used to provide suitable combinations of 
authentication and/or encryption. Examples hereof include the GCM mode 
and CCM mode.

Best regards, Rene

On 5/6/2014 1:32 AM, Joseph Salowey (jsalowey) wrote:
> On Apr 29, 2014, at 10:46 AM, Michael StJohns <msj@nthpermutation.com> 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.
>
>> 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.
>
>
>> 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.
>
>
>> 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?
>
>>> Joe
>>> [For the chairs]
>>> On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> 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@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363