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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 11 March 2011 07:19 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 146173A687D; Thu, 10 Mar 2011 23:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.682
X-Spam-Level:
X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, 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 W6+GDUvhpbbw; Thu, 10 Mar 2011 23:19:45 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 7C9293A680D; Thu, 10 Mar 2011 23:19:44 -0800 (PST)
Received: by ewy19 with SMTP id 19so988076ewy.31 for <multiple recipients>; Thu, 10 Mar 2011 23:21:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=lDQIHOdZJUve71K92RPaBmpXuNYgtCkEcn0kMbr7Pc8=; b=Ht08NSDm3szPlNX2Gyi3ZCv/HOlKcARtSJfhXHcetQG2a95NV3ytXM7lBxQ+x1sLhF bSe/5Qh5Y2ZcMP3+RIesrPeZ4aHZl3l9J30Xz+PiWcdaZX51ggZ66rWm6qxoSr8XCvn7 DeswB+rrBDJ9sF3xUZeZspq9FKm9p3DWT/1xA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=v3gb+CivvIaYq0I9gLTsoGyXtp78pbm1RWXVVmYjXOtgSHxzgfQb7nXd6TYm2WdAUB kYapZDTGfMUSplRhgVeYNJGfudynXd860Tj3yqeS8ieFcqqe5YGTpRKeMlK2RCb45yHr pgU1vvfi7SBxZ27t836JGyfLkbNkHY7HVXrmY=
Received: by 10.14.11.31 with SMTP id 31mr3277859eew.15.1299828062311; Thu, 10 Mar 2011 23:21:02 -0800 (PST)
Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id w59sm3183682eeh.21.2011.03.10.23.20.59 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 23:21:00 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4D79CD5B.4030002@gnutls.org>
Date: Fri, 11 Mar 2011 08:20:59 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <201103081923.p28JNl08009539@fs4113.wdf.sap.corp> <E1Px6k6-0001We-0G@login01.fos.auckland.ac.nz> <AANLkTinvuvh_OBBzzNxTku0RmZ8eibTmRQJvfdJW-Oyw@mail.gmail.com> <p06240800c99f0ea95db8@[10.84.130.113]>
In-Reply-To: <p06240800c99f0ea95db8@[10.84.130.113]>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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: Fri, 11 Mar 2011 07:19:46 -0000

On 03/11/2011 12:28 AM, Stephen Kent wrote:

>>> It wasn't any "may have become first popular", there was only
>>> room for 96 bits of MAC data in the IP packet, so MD5 was
>>> truncated to that size.
>> 
>> This is an odd claim, since:
>> 
>> (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally
>> specified not HMAC but a keyed MD5 variant with a 128-bit output. 
>> (b) The document that Martin points to has MACs > 96 bits long.
>> 
>> Can you please point to where in IP there is a limit that requires
>> a MAC no greater than 96 bits.
>> 
>> -Ekr
> 
> What Peter probably meant to say was that IPsec chose to truncate the
> HMAC value to 96 bits because that preserved IPv4 and IPv6
> byte-alignment for the payload.  Also, as others have noted, the hash
> function used here is part of an HMAC calculation, and any collisions
> have to be real-time exploitable to be of use to an attacker.  Thus
> 96 buts was viewed as sufficient.

This sounds pretty awkward decision because HMAC per record is full
(e.g. 160-bits on SHA-1), but the MAC on the handshake message
"signature" is truncated to 96-bits. Why wasn't the record MAC
truncated as well? In any case saving few bytes per handshake
is much less of value than saving few bytes per record. Was
there any other rationale for truncation?

regards,
Nikos