IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Tue, 08 March 2011 18:49 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 B27863A693A; Tue, 8 Mar 2011 10:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.921
X-Spam-Level:
X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.056, 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 j-Syz+yThibb; Tue, 8 Mar 2011 10:49:51 -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 E7ECF3A68AF; Tue, 8 Mar 2011 10:49:50 -0800 (PST)
Received: by iyj8 with SMTP id 8so6383731iyj.31 for <multiple recipients>; Tue, 08 Mar 2011 10:51:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.58.135 with SMTP id wk7mr6796871icb.433.1299610265989; Tue, 08 Mar 2011 10:51:05 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Tue, 8 Mar 2011 10:51:05 -0800 (PST)
In-Reply-To: <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp>
References: <AANLkTik07Zte5ERfG_+GHd_ag9o3UguzCE6gEzjnSHKe@mail.gmail.com> <201103081845.p28IjCY0007292@fs4113.wdf.sap.corp>
Date: Tue, 08 Mar 2011 10:51:05 -0800
Message-ID: <AANLkTim=g981ne+Y-ZdgATdimRmgfjyM81YEuPAhyhCV@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: mrex@sap.com
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: Tue, 08 Mar 2011 18:49:51 -0000

On Tue, Mar 8, 2011 at 10:45 AM, Martin Rex <mrex@sap.com> wrote:
> Eric Rescorla wrote:
>>
>> Marsh Ray wrote:
>> >
>> > I think he's arguing that anything cut down to 96 bits represents a lousy
>> > hash function allowing practical collisions on today's hardware.
>>
>> 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.


>   RFC-5929 TLS Channel Bindings
>   RFC-5746 TLS extension Renegotiation indication
>
>
> I'm sorry, but I think it is a bad idea to use a flawed design for
> the TLS finished message by subverting the collision resistence
> of stronger secure hash functions that are used for the PRF.

Yes, I realize you think that, but until you offer a cryptographic
argument for that
opinion I guess we're just going to have to disagree.

-Ekr

v2.23.0 | Report a Bug | By Email