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

Eric Rescorla <ekr@rtfm.com> Fri, 11 March 2011 14:48 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 0A8D13A6948; Fri, 11 Mar 2011 06:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.931
X-Spam-Level:
X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.046, 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 jTKP+LosramX; Fri, 11 Mar 2011 06:48:34 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 001D43A68FE; Fri, 11 Mar 2011 06:48:33 -0800 (PST)
Received: by iwl42 with SMTP id 42so3354679iwl.31 for <multiple recipients>; Fri, 11 Mar 2011 06:49:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.45.137 with SMTP id uk9mr12328874icb.31.1299854993187; Fri, 11 Mar 2011 06:49:53 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Fri, 11 Mar 2011 06:49:53 -0800 (PST)
In-Reply-To: <4D79CD5B.4030002@gnutls.org>
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> <4D79CD5B.4030002@gnutls.org>
Date: Fri, 11 Mar 2011 06:49:53 -0800
Message-ID: <AANLkTimOHxPWoUJ9ssc5g=qnF2K3dT34Dcu2RBiEn--d@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, Stephen Kent <kent@bbn.com>, tls@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 14:48:35 -0000

If your question is why did the TLS WG decide to do this back in like
1996 or so?

If so, it would require a real archive search to get a definitive
answer, but my vague
memory is that (a) it was suggested by one of the cryptographers in
the group, e.g.
Hugo Krawczyk or Ran Canetti and (b) it was motivatated by the desire to
limit the amount of information disclosed about the MS (remember that it used to
be 36 bits!). I don't recall why 12 bytes rather than 16 bytes or 20 was chosen.

Best,
-Ekr


On Thu, Mar 10, 2011 at 11:20 PM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> 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
>