Re: [TLS] Record header size?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 19 November 2015 02:17 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 2A4C81B37DE for <tls@ietfa.amsl.com>; Wed, 18 Nov 2015 18:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 uBnBV6Trj5-4 for <tls@ietfa.amsl.com>; Wed, 18 Nov 2015 18:17:26 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3EF1B37DB for <tls@ietf.org>; Wed, 18 Nov 2015 18:17:26 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7D06928494E; Thu, 19 Nov 2015 02:17:25 +0000 (UTC)
Date: Thu, 19 Nov 2015 02:17:25 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20151119021725.GH18315@mournblade.imrryr.org>
References: <B79F7446-0BBF-4006-A448-E81FF5E7ECD4@gmail.com> <20151118205229.E58841A380@ld9781.wdf.sap.corp> <201511190207.tAJ2796g023242@d23av04.au.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201511190207.tAJ2796g023242@d23av04.au.ibm.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/73gKB0AKUl2n7Aop9DqC8wPa3ps>
Subject: Re: [TLS] Record header size?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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: Thu, 19 Nov 2015 02:17:29 -0000

On Thu, Nov 19, 2015 at 12:05:55PM +1000, Michael Gray wrote:

> > With several TLS implementations it is possible to completely seperate
> > network communication (of the application) from the processing of
> > TLS records (performed by the TLS protocol stack).  For some TLS
> > implementations (e.g. Microsoft SChannel) this seems to be the only
> > possible mode of operation.
> 
> We have the same kind of IO separation and I have observed a few times that
> some products either interleave/multiplex TLS records with other
> application data flow or route/buffer TLS traffic based on TLS record
> header checking.  Padding the header to 8 bytes, as above, would probably
> be OK.

Before we seriously consider going there, we should make sure that
this really addresses the problems that the hardware vendors
reputedly have.

Is it enough to pad just the application-data records (effectively
prepend 3-nul bytes to every application data record, and think of
it as either a longer record header, or initial data padding)?  Or
do the vendors in question need alignment of the handshake packets
too?  My guess is that changing the alignment of the handshake
packets would not be as useful, and would reduce interoperability
(confuse more middle-boxes).  But this guess could be wrong.

Can anyone definitively confirm the actual requirements?

-- 
	Viktor.