Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

Eric Rescorla <ekr@rtfm.com> Wed, 09 March 2011 15:43 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC173A68C1; Wed, 9 Mar 2011 07:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.927
X-Spam-Level:
X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXJwnOyrKvYM; Wed, 9 Mar 2011 07:43:33 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 46B463A67C1; Wed, 9 Mar 2011 07:43:33 -0800 (PST)
Received: by iyj8 with SMTP id 8so798925iyj.31 for <multiple recipients>; Wed, 09 Mar 2011 07:44:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.57.131 with SMTP id wg3mr8327136icb.299.1299685489220; Wed, 09 Mar 2011 07:44:49 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 07:44:49 -0800 (PST)
In-Reply-To: <AANLkTimBMwV-SBQrG9OdLauQWHbYKqSHAtprQpGvHM41@mail.gmail.com>
References: <AANLkTik07Zte5ERfG_+GHd_ag9o3UguzCE6gEzjnSHKe@mail.gmail.com> <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp> <AANLkTim=g981ne+Y-ZdgATdimRmgfjyM81YEuPAhyhCV@mail.gmail.com> <AANLkTimJzVoobdBTLEKbBdm2SLMaoRC3XLKQxXDZZ7tQ@mail.gmail.com> <AANLkTin0D7KYn-c4OfnoY_SPD7jDZThpjKLrrEZBU7h3@mail.gmail.com> <AANLkTimBMwV-SBQrG9OdLauQWHbYKqSHAtprQpGvHM41@mail.gmail.com>
Date: Wed, 09 Mar 2011 07:44:49 -0800
Message-ID: <AANLkTi=10FnMqxnDao0_breDP2T4Zbhu=MRQUiNjB-E6@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Wed, 09 Mar 2011 15:43:34 -0000

On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>> I'm not a specialist in MAC algorithms but by checking
>>> the ECRYPT II[0] report of 2009-2010, I can try making some points.
>>> A MAC has a security level that depends on the size of the MAC
>>> and the size of the key. That is a 12-byte MAC has security level of
>>> MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
>>> As I understand the addition of SHA-384 as PRF was to increase
>>> the security margin of TLS comparing to the SHA-1 PRF. This
>>> is not occuring now because a MAC based on algorithm that
>>> returns 384-bits and truncates it  to 96 can offer nothing more
>>> than an algorithm that outputs 160 bits and are trucated to 96.
>>> Hence there is no significant difference than SHA-1 or SHA-384
>>> in that case, so why define SHA-384 anyway?
>> If you recall, the reason why TLS 1.2 was done was not primarily because
>> of concerns about SHA-1's 160-bit output being large enough but because
>> people started developing analytic attacks on MD5 and SHA-1 that brought
>> it's security level down below the nominal level.
>> In other words, there are many applications where 80 bits of security is
>> fine, but people don't want to use SHA-1 because they don't trust it.
>
> Such things should be explicit then. In any case I think there is a mistake
> here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as
> PRF, and the AES-128 ciphersuites with SHA-256, thus there was
> intention to match the security strength of the cipher with the size
> of the hash.
>
> If this wasn't the intention, then it is pretty much misleading, and should
> be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it
> is being truncated in 96 bits. The choice for SHA-384 was because .....

I'm not one of the authors of that draft, but I imagine for the usual
reason of tiling
the space of algorithms (not that I consider it a great reason.)

-Ekr