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

Martin Rex <mrex@sap.com> Mon, 14 March 2011 22:48 UTC

Return-Path: <mrex@sap.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 4C73B3A6BEE; Mon, 14 Mar 2011 15:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.221
X-Spam-Level:
X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 1oZmcwpEYRPt; Mon, 14 Mar 2011 15:48:27 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CB0803A6BED; Mon, 14 Mar 2011 15:48:26 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2EMnGQm000883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Mar 2011 23:49:16 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp>
To: nmav@gnutls.org
Date: Mon, 14 Mar 2011 23:49:15 +0100
In-Reply-To: <4D7E7AF9.7070409@gnutls.org> from "Nikos Mavrogiannopoulos" at Mar 14, 11 09:30:49 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org, ietf@ietf.org, kent@bbn.com
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
Reply-To: mrex@sap.com
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: Mon, 14 Mar 2011 22:48:28 -0000

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