Re: [TLS] Record header size?

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 17 November 2015 15:41 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FEB1ACCFB for <tls@ietfa.amsl.com>; Tue, 17 Nov 2015 07:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.785
X-Spam-Level:
X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylbd1I_gf68p for <tls@ietfa.amsl.com>; Tue, 17 Nov 2015 07:41:06 -0800 (PST)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E091ACC87 for <tls@ietf.org>; Tue, 17 Nov 2015 07:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447774866; x=1479310866; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rlN0fbeuN2jLcODzcV7to4rGAc7rJFEdyaSQOqPjStE=; b=OzKX1smEnmNZpbecXnATcGgjRevjDKSbv3dZEIMCsusmxm7K7d2Rxchl hZJgw3VoM7l8NJirz61oK5HRdxRTLxYQJdLCn0F7DYaG/DdUYTx+mamU2 2Iw1mTFp3wUiDl4I2YqoT51IBgphpmEJRKvPdHDdpOKvZMbiwrks9Zx53 5b2pC0teh8M9J0PILvnvb1GarA1YwL7ZfwuWU/Bx7ZNMYHlxM4zkTp03u uc/HlAv3f5lDYwZBoC0OoqLrgyCkLx+UnjQUozQytXBMwXGlQ+w3I6rPN 9RYUrn7ovgikv7x3amaVJydvxwml/ix/jMPVf4hElDXkzZk3t9xfKidQO A==;
X-IronPort-AV: E=Sophos;i="5.20,308,1444647600"; d="scan'208";a="54627423"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Nov 2015 04:40:57 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 18 Nov 2015 04:40:56 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "Short, Todd" <tshort@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Record header size?
Thread-Index: AQHRIUwqo2PzkmG0m02LaFyKO+3dU56gWSPK
Date: Tue, 17 Nov 2015 15:40:56 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B66D1F@uxcn10-5.UoA.auckland.ac.nz>
References: <C5F506DC-F814-4C0B-AFAA-86CF790817A7@akamai.com>
In-Reply-To: <C5F506DC-F814-4C0B-AFAA-86CF790817A7@akamai.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/jk-uEQRLCRAfYg7zl4ShW0549vY>
Subject: Re: [TLS] Record header size?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 17 Nov 2015 15:41:12 -0000

Short, Todd <tshort@akamai.com> writes:

>Has there been any consideration to changing the record header for encrypted
>traffic to be 4 bytes (i.e. 32-bits)? 5 bytes is a very awkward size, and
>some processors do not handle odd byte offsets well (it was a complaint I
>heard from Cisco router/switch engineers).

Not just Cisco, other hardware people have run into it as well.  You don't
need the version field at all because it's been negotiated in the handshake,
for the remainder of the session it's just wasted bytes.  So having a 1-byte
type and 3-byte length for a combined 32-bit field would work fine.

Peter.