IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Wed, 09 March 2011 14:30 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 6D4353A69FB; Wed, 9 Mar 2011 06:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[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 bFyoufuZifte; Wed, 9 Mar 2011 06:30:49 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 036AD3A69E4; Wed, 9 Mar 2011 06:30:48 -0800 (PST)
Received: by gwb20 with SMTP id 20so26962gwb.31 for <multiple recipients>; Wed, 09 Mar 2011 06:32:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.164.199 with SMTP id h7mr8397594icy.165.1299681124999; Wed, 09 Mar 2011 06:32:04 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 06:32:04 -0800 (PST)
In-Reply-To: <E1PxG9B-0007K0-FK@login01.fos.auckland.ac.nz>
References: <AANLkTinvuvh_OBBzzNxTku0RmZ8eibTmRQJvfdJW-Oyw@mail.gmail.com> <E1PxG9B-0007K0-FK@login01.fos.auckland.ac.nz>
Date: Wed, 09 Mar 2011 06:32:04 -0800
Message-ID: <AANLkTi=pUxtg0TYGDGJX44_U31NuXJJeOFqvx0u2uKo_@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org, 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: Wed, 09 Mar 2011 14:30:50 -0000

Overflowing by another 32 bits is hardly the same as "there was only room for"

-Ekr


On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Eric Rescorla <ekr@rtfm.com> writes:
>
>>Can you please point to where in IP there is a limit that requires a MAC no
>>greater than 96 bits.
>
> The AH had room for exactly 96 bits of MAC value, any more and it'd have to
> overflow to another 32 bits worth (the size of the non-MAC data is 96 bits and
> the MAC data adds the other 96 bits), see RFC 2402.  The original AH used a
> 64-bit data field (RFC 1826) and didn't truncate MD5 (RFC 1828), so it was
> also 192 bits long.  With the expansion of the non-MAC data to 96 bits, it was
> necessary to truncate the MAC to keep the same overall size.
>
> Peter.
>

v2.23.0 | Report a Bug | By Email