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

Eric Rescorla <ekr@rtfm.com> Wed, 09 March 2011 14:33 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 0402E3A69F2; Wed, 9 Mar 2011 06:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.93
X-Spam-Level:
X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=0.047, 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 lphQHSSej5zV; Wed, 9 Mar 2011 06:33:38 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0C5043A69EC; Wed, 9 Mar 2011 06:33:37 -0800 (PST)
Received: by iwl42 with SMTP id 42so726048iwl.31 for <multiple recipients>; Wed, 09 Mar 2011 06:34:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.74.71 with SMTP id v7mr8404229icj.232.1299681294424; Wed, 09 Mar 2011 06:34:54 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 06:34:54 -0800 (PST)
In-Reply-To: <AANLkTimJzVoobdBTLEKbBdm2SLMaoRC3XLKQxXDZZ7tQ@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>
Date: Wed, 09 Mar 2011 06:34:54 -0800
Message-ID: <AANLkTin0D7KYn-c4OfnoY_SPD7jDZThpjKLrrEZBU7h3@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 14:33:39 -0000

On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>> Perhaps, but this isn't a digest but rather a MAC, and so the attack
>>>> model is different.
>>> You seem to be forgetting that the finished messages have been reused
>>> for other purposes already:
>> No, I'm not forgetting that. That doesn't change the fact that the
>> computation is
>> a MAC.
>
> 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.


> For me the ciphersuites defined in TLS should have a uniform
> security level. I.E. why use AES-256 with security level of 2^256
> but use a MAC for a handshake of 2^96 bits?

Because the attack model for MACs is not the same as the attack model
for encryption. The encryption is susceptible to offline attack, whereas
with a MAC all you need to do is get the guessing probability sufficiently
low because *any* failed forgery causes connection termination.

-Ekr