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

Bryan Ford <> Wed, 02 December 2015 09:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE32B1A6FE5 for <>; Wed, 2 Dec 2015 01:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d0fzKOCK7CAi for <>; Wed, 2 Dec 2015 01:51:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4F2C1A6FDC for <>; Wed, 2 Dec 2015 01:51:58 -0800 (PST)
Received: by wmww144 with SMTP id w144so49125005wmw.0 for <>; Wed, 02 Dec 2015 01:51:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=25NdJIJYqp/c3BrHshjXjyERYD5M9XxQuC1GrVrYxfQ=; b=hSYMt0Q33NU4B7/Yf8pg/sSNWKvn596MUlXH/SKp3IFvZWmgUjDs4qHKDqqY/FxXCx /nmMelJ0z/tK2vQjZ8tGXJ6JG7/qg0eFUEj43NdV+Lz9AMuCszwvud5Sac8hIJhdhJnJ kUKMyAjoy15w8fxoUNqcVDNl8H6IzOzVlmLviYDjhKsYTEY2cWyqj43FPTAfynhB/8Vv kfpQHEWAmeRmVvMTN5kJA6+MTKjJXf2Mvlp43VLgRnKoUDWsdxPWU6wTEWP4uIz7nX5m Dgpr3Qg1XMY9L/HoIgQ2Gy8TxTh6HjUtwHwTz2h3+CumINbkcmMAh7Q1SWgYMws88lEL +OSg==
X-Received: by with SMTP id gy6mr3596654wjc.173.1449049917480; Wed, 02 Dec 2015 01:51:57 -0800 (PST)
Received: from ( []) by with ESMTPSA id h189sm30146179wme.1.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 01:51:56 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AC36E91B-075A-4556-B367-8D422F19D759"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Bryan Ford <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 10:51:55 +0100
Message-Id: <>
References: <> <> <> <>
To: Fabrice Gautier <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: "" <>
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: Wed, 02 Dec 2015 09:52:02 -0000

On 02 Dec 2015, at 00:54, Fabrice Gautier <> wrote:
> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford < <>> wrote:
>> On 12/1/15 4:02 AM, Fabrice Gautier wrote:
>>> 1) What would be the implications of this for DTLS? (Knowing that one difference between TLS and DTLS is the record header)
>> Good question.  Fortunately my proposal should be fairly easy to adapt
>> to DTLS, with one small trick. […]
> Hum.... I wouldn't qualify this as a "fairly simple" solution.

A reasonable but subjective position, which I think we should further discuss later if/when this (or some) WG actually revisits DTLS. :)

>>> 2) In some implementations the record framing/parsing and encryption/decryption are down at different layers. Would this proposal make this type of implementation impossible?
>> Not that I'm aware of, but I might need more information about the
>> specific layering approaches you're thinking of and how "strongly
>> enforced" that layering might be.
> For example:
>  A TLS library might be logically separated into two main parts:
> 1) A record parsing block, that just take a stream of bytes as in
> input (eg: from a socket) and output a series a record.
> 2) A decrypt function, that take as input full encrypted record and
> output a decrypted one.
> There may be various reason to do this: flexibility, clean layering,
> maintainability, testability, etc...
> Another reason, maybe performance. For example, a network stack might
> not want to send partial records to the application to decrypt. Having
> a simple way for a network stack to implement TLS framing maybe
> beneficial. Currently it would be fairly simple to implement TLS
> record parsing in a TCP stack. But with your proposal it seems it
> would mean the parsing layer would need to get keys and do crypto.

In my first proposal, with headers encrypted with a stream cipher (or AEAD used as one), I think this kind of layering should still be quite feasible, with the one caveat that the TLS record parsing layer does indeed need to make one new “call” into the crypto-related code (to get the header) in addition to the one it already does (to pass the body and header to the crypto code for body-decryption and integrity-check).  And only on the receive path; the send path seems pretty much unaffected.  This doesn’t seem like a big layering problem to me, but again subjective opinions may vary.

In my second proposal, with headers fully encrypted and integrity-checked along with the body, I think the opportunity for the clean layering you propose comes back and perhaps gets even better: it’s just that the record writing/parsing now happens *inside* rather than outside the encryption boundary.  In other words, their order is reversed: the sender invokes the record-writing code first, then the AEAD encryption code to encrypt everything (header and data) at once; the receiver flow invokes the AEAD decryption code first to decrypt everything, then invokes the separately-modularized record parsing code on the already fully decrypted and integrity-checked record content.  This seems even cleaner to me than the current approach, where the record parsing code has to do some (very careful!) parsing of the record before it’s been authenticated, then invoke decryption, then do some more internal parsing on the decrypted AEAD body (e.g., the encrypted content-type within).