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

Jacob Appelbaum <> Tue, 01 December 2015 01:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 06EF71B35FE for <>; Mon, 30 Nov 2015 17:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EMKWexk8wypv for <>; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C787C1B35F9 for <>; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
Received: by ioir85 with SMTP id r85so194480779ioi.1 for <>; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zLveUSTRX6u8JQvwWyT96NHuRO7xvK0P6IXEbdg0XSw=; b=XcO2E/iCBmKlLtPsd6fWUphvd66Pc/vHttGguVDS/1ouWGRrqMFLP/c5FlITUqJS9L BZVwU0uJZrh16/nRwxxD+6tb0fRB/9h6PIbXPg3cjjDpGodVoZsPvxLSTudbCbz1TNFI KfMMjU+9h02Jne6aBFNygDgxMmceb5DSIGtW/8JIlyMjKsSjhFhHBM+mPCOF/e1zm0Co Wdx6wQsVq6VhkjBPxVvTDOlzwAD0OL869MHj4vvhmYimzMK3co6nMauvW538nGEKTpci hlnYpzvFu115wTgdugbwEuDzJ0QICyxS+cS6RnCBrap0oFSS6+IpY9UHD3ceimMT2Do2 AjPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zLveUSTRX6u8JQvwWyT96NHuRO7xvK0P6IXEbdg0XSw=; b=XAJxWWLKfo3Tuc5/JhdBoVHZrOpsYrXCQT4d4FgynXRkymQvBrbrt9bD9ee1rXnfst Z23RjTcUgahA17lqtEUG6wRnRg1JCRFTpwyg38kvlapi2+h+ubEI+t9LbJhQmbPK3bMc 5z16NLfIAdVnY/9zJlTkUx+Fed+PN5lK3g8K8QecSM/x6PSyz64h9LnbVssIbyhYDj18 o2JkQNpYyfGb3GSh3FI2NIXY7TPnoXqnockp6Zh4g27t/az6NzdljCKlPFgDZs1TVl3h hpzClv5L+psTljxv70ZlLoL3ll71qBDSu9Tb1U4kdPDhx6P9KdVWQkSCivB1UL9mzMui zTyg==
X-Gm-Message-State: ALoCoQmLJZajq+zm864RXIYFPdTFz3mQxVoBf/C75bfLLIRfz/C3RRetnE/K9P8/mk8q3l1SP/Zd
MIME-Version: 1.0
X-Received: by with SMTP id l19mr54263852iod.138.1448933787043; Mon, 30 Nov 2015 17:36:27 -0800 (PST)
Received: by with HTTP; Mon, 30 Nov 2015 17:36:26 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 01 Dec 2015 01:36:26 +0000
Message-ID: <>
From: Jacob Appelbaum <>
Content-Type: text/plain; charset="UTF-8"
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 01:36:29 -0000

On 12/1/15, Viktor Dukhovni <> wrote:
> 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
>> 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.

That doesn't change with Bryan's suggestion, I think.

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

Which would those be? And what is the definition of capital-intensive
for those watching on the sidelines?

> 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.

This seems borderline absurd. The TLS protocol is doing a major
version revision.

> 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.

I don't think it will hinder interoperability and not one person has
even named a single device that would have issues with it. I think the
only thing that comes close is when I've named a classified US
government surveillance program (XKeyscore) that would probably have
trouble with it.

We should add Bryan's feature and not pander to non-specific concerns
about middleboxes that should be considered as adversaries.

> 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.

That is part of what is happening in Bryan's suggestion. He found a
reasonably practical way to encrypt record headers. His suggestion
will make TLS more secure. His suggestion includes a review of a part
of the previous state of TLS 1.3 with a proposed improvement.

No one is debating it on the cryptographic merits which is surprising.

All the best,