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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 15 March 2011 14:50 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 3B15B3A6D9F; Tue, 15 Mar 2011 07:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 Te3kLRru6MwK; Tue, 15 Mar 2011 07:50:49 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C987C3A6D9B; Tue, 15 Mar 2011 07:50:48 -0700 (PDT)
Received: by qwg5 with SMTP id 5so598400qwg.31 for <multiple recipients>; Tue, 15 Mar 2011 07:52:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+ZjHtIv8beyrnxirWE3a7kAMGaisRJjEJfkFkUjlRII=; b=njjZlFqYm2Qf/7P34XdlC7oVJnM8rReWJg3ZwCQ1XnhgwbkcTZCFCME/slww/Iz9Vr X8aSet0Kc0iTl2fQzuA4m5qkHG/Ba3uMAQdBVWa0CTjSNUwab1gmFJPVj4RXCRsV89+B 6W+vZft9HnfjKVEk1U7QKzi9/sbX3UWV+KCPE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BYP1igLh+XWAK/GaYMkZu2wR2/TtNyo4a6W0I+QCO6xNLBUCGQQ517UVMZPCtbd5sr CQGTPkriwEm9LCnFZyQaEFz12HNYvSL/2cMG0kPSN2RAwbeLczO9AbwywF9FK8vAzpDq RES1ECMctD8evzSxrE0IOhoQ0YiLj/oLQClII=
MIME-Version: 1.0
Received: by 10.224.217.134 with SMTP id hm6mr12707255qab.172.1300200733303; Tue, 15 Mar 2011 07:52:13 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.220.140 with HTTP; Tue, 15 Mar 2011 07:52:13 -0700 (PDT)
In-Reply-To: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp>
References: <4D7E7AF9.7070409@gnutls.org> <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp>
Date: Tue, 15 Mar 2011 15:52:13 +0100
X-Google-Sender-Auth: HGr0TaTaBKdySR1mz-NRTPbxgZQ
Message-ID: <AANLkTi=K=fSgpxAU_aLn_xiaOK=KtuGCSPN9D+n+4W2w@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: mrex@sap.com, tls@ietf.org, ietf@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: bart.preneel@esat.kuleuven.be
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: Tue, 15 Mar 2011 14:50:51 -0000

Hello,
 I had some discussion with Bart Preneel[0] on the use of a 96-bit
MAC for the Finished messages. His comments were:

"My general advice to IETF was to keep half the bits of the internal
state of the hash function. For HMAC-MD5 this would be 64 bits, for
HMAC-SHA-1 this would be
80 bits and for HMAC-SHA-256 this would be 128 bits.

We now have key recovery attacks on HMAC-MD4 and HMAC-MD5; these
attacks become somewhat harder if the output is truncated (so
I believe that I was right ;-)
NO forgery attacks have been found that exploit the truncation.

In practice, it is better to output the same MAC length for alignment.
64 bits seemed reasonable in 1996.  It turned out that 96 bits gave
better alignment properties than 64 bits.

I believe that a 64-bit MAC is sufficient for most applications, and
a 96-bit MAC is more than enough. I can't see a reason to use a 128-bit MAC."

That said, he suggested against decoupling data authentication from
the security level of the cipher-suites:
"If you are paranoid about security (which you are of you use AES-256)
you should output half the bits of the internal state, so 128 for
SHA-256."

My comments on that is that the discussion on MAC truncation should
apply both to the handshake MAC and the record MAC. If recovering the
master secret was an issue for the handshake MAC, recover of the session
MAC key, should also be an issue, especially since chosen-message
attacks should be considered possible during application data exchange.

To extend it further I think TLS cipher-suites should have a target security
level (e.g. 96 bits, 128 bits) and this should include the TLS Finished
messages MAC as well. Otherwise we end up with combinations of AES-256
and SHA-384 as MAC truncated to 96-bits for the finished messages but
the full 384 bits for the record messages, that IMO does not make much sense.

regards,
Nikos

[0]. http://homes.esat.kuleuven.be/~preneel/

On Mon, Mar 14, 2011 at 11:49 PM, Martin Rex <mrex@sap.com> wrote:
> Nikos Mavrogiannopoulos wrote:
>>
>> On 03/14/2011 06:28 PM, Martin Rex wrote:
>> >
>> > That was, what I assume, the fear, based on the second part of this
>> > message from Dan Simon
>> >    http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html
>> > and the second part of this message from Hugo Krawczyk
>> >    http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html
>> >
>> > Since the TLSv1.0 finished message was defined based on the output
>> > of the TLS PRF (a function with indefinite output length),
>> > defining a truncation was inevitable.  :)
>>
>> Indeed. It seems the messages you list summarize that design decision
>> in a nice way. The concerns for the one-wayness of the MAC used lead
>> to that truncation. That way one-wayness is ensured by discarding data
>> at the cost of having a weaker MAC. I don't know if the current
>> construction can be extended for a longer size without implications.
>
> The concern with the one-wayness of the hashes was about >SSLv3<
> and how it computed its Finished message:
>
>     enum { client(0x434C4E54), server(0x53525652) } Sender;
>
>     struct {
>         opaque md5_hash[16];
>         opaque sha_hash[20];
>     } Finished;
>
>     md5_hash       MD5(master_secret + pad2 +
>                        MD5(handshake_messages + Sender +
>                            master_secret + pad1));
>     sha_hash        SHA(master_secret + pad2 +
>                         SHA(handshake_messages + Sender +
>                             master_secret + pad1));
>
>     handshake_messages    All of the data from all handshake messages
>                           up to but not including this message.  This
>                           is only data visible at the handshake layer
>                           and does not include record layer headers.
>
>
> Personally, I'm having difficulties to see how exactly it would leak the
> master_secret if MD5 was found to be fully invertable.
>
> The MD5 output is 128 bits = 16 bytes, and the input is *MUCH* larger
> than 128 bits.  The master_secret should is 48 bytes alone.  Even if one is
> successful at inverting MD5, one can not undo the collisions from
> the Finished computation caused by the compression of a much larger
> input into a 128 bit output value.
>
> Anyhow, I do see the new Finished computation algorithm in TLSv1.0 as a
> sensible change in the TLS design.
>
>
> -Martin
>