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

Marsh Ray <marsh@extendedsubset.com> Mon, 14 March 2011 23:52 UTC

Return-Path: <marsh@extendedsubset.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 C84BC3A6E40; Mon, 14 Mar 2011 16:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
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 ddH-JGl7r2vN; Mon, 14 Mar 2011 16:52:09 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id ECF993A6B8B; Mon, 14 Mar 2011 16:52:08 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1PzHGs-00010F-0Q; Mon, 14 Mar 2011 23:33:54 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 31AD9606B; Mon, 14 Mar 2011 23:53:14 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18M6nvtk7miJj1ZADN2pkcAhYYpWVJpNTI=
Message-ID: <4D7EAA67.70702@extendedsubset.com>
Date: Mon, 14 Mar 2011 18:53:11 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: mrex@sap.com
References: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp>
In-Reply-To: <201103142249.p2EMnFWG009158@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kent@bbn.com, 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: Mon, 14 Mar 2011 23:52:09 -0000

On 03/14/2011 05:49 PM, Martin Rex wrote:
>
> 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.

You could accumulate multiple samples, perhaps even with session 
resumption where the Finished message is sent by the server without the 
chance to authenticate the client first.

Normally you even don't get to see the Finished.verify_data without 
breaking the encryption or downgrading to no encryption. But 40-bit 
encryption and "integrity only" connections were fully supported use 
cases back in those days.

If they had really wanted to leverage the 16 or 20 byte bottleneck of 
MD5 and SHA-1, they should have padded the master_secret from 384 to 512 
bits (the input block size) before putting it into the hash function.

- Marsh