Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Viktor Dukhovni <> Tue, 01 December 2015 00:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09D521B34ED for <>; Mon, 30 Nov 2015 16:56:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OY5oVTtxGJtx for <>; Mon, 30 Nov 2015 16:56:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E4211B34F3 for <>; Mon, 30 Nov 2015 16:56:11 -0800 (PST)
Received: by (Postfix, from userid 1034) id 919B1284E37; Tue, 1 Dec 2015 00:56:09 +0000 (UTC)
Date: Tue, 01 Dec 2015 00:56:09 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Dec 2015 00:56:14 -0000

On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote:

> Bryan A Ford <> writes:
> >It would work just as well and in exactly the same way if the AEAD is
> >replaced with the traditional Encrypt-then-MAC construction, for example.
> No it wouldn't, unless the encrypt part is a stream cipher.  You're still
> locked into using an AEAD stream cipher or the equivalent of an AEAD stream
> cipher built with encrypt+MAC.  It won't work with, for example, the OCB AEAD
> mode, or CBC + MAC.

I think we should focus on what would get TLS 1.3 to be adopted:

    * Reasonably implementable in libraries that support older
      versions alongside TLS 1.3.

    * Interoperable in the field with various capital-intensive
      middle boxen.

This suggests focusing on solidifying the core protocol, and a
healthy dose of skepticism around bells and whistles.  If the
protocol is overloaded with too many (alright even more) incompatible
innovations, the net effect is likely less security due to
substantially delayed deployment of the key improvements.

Encrypting message lengths looks rather marginal from this perspective,
and quite likely to hinder interoperability and delay both
implementation and upgrades.  However cool an idea this might be,
this does not look to me like the right time to add this feature
to TLS.

At this point, TLS 1.3 is rather feature rich, and it is I think
time to focus on reviewing the already agreed changes (maybe even
drop some if they look inessential).  Make it solid, trim the fat,
get it out the door in a usable form.