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

Jacob Appelbaum <> Wed, 02 December 2015 11:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 643F81A8700 for <>; Wed, 2 Dec 2015 03:38:45 -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 WjCckFO_DdIl for <>; Wed, 2 Dec 2015 03:38:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAF3D1A6F9C for <>; Wed, 2 Dec 2015 03:38:43 -0800 (PST)
Received: by iofh3 with SMTP id h3so42349693iof.3 for <>; Wed, 02 Dec 2015 03:38:43 -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 :cc:content-type:content-transfer-encoding; bh=g/6wSLEUOTFEUOHS06zk0eZ8KFlp3UAAJX1qdWVB368=; b=iHQK+NomNQDxpRlKm5JT017tWTabMe2NsC9nb9NQb3kvFZzj9FJNrd/UP02YWoe21K hllu5sLALD5Zk0pH0XlYx5MRUsWHH04WilRg70K7PEX09Uh1jgTTHwlOGKKuefJzhHBi yYIMEpPhcu3/p7gy6HOswGYJB53IuUx1gqVxV0p+pmmv3G0hy2Qsva92Vejw9TUJhrs6 YOdDRzkfEaVlFp9D3jgYqNEXRS+9J4qBwzfeWcj5rO7XEgyxjk8gAdfgpXgBq/8aAo2n wLlVGzdlnrdpeS3l1wlO6XvT+Gvg1zsAIzQkJZhUqbOeZNJdTOEseQSJQC8r0xT215/y DRPA==
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:cc:content-type :content-transfer-encoding; bh=g/6wSLEUOTFEUOHS06zk0eZ8KFlp3UAAJX1qdWVB368=; b=Dq6BELwKWRDgL/3TBM1Xx7ojQMjcqrU6I8viwEGXaJZf0SJCeW/oTNC7z+UU0NE4RC 576cW/tXFdLbQdbrsudE4MjsIFqA0qtA2Tmi7YYnYlrlGrXTLBDoaI+oWKWHlXwa9brE slhrk1SKrVe79usx19e+STc+QIbQvSoJxMOvQBkfA5Tkf5uy8WthDdxTjxKyAscaehoZ 9fgrx1N8SPuFAAd0lOJqNXzbZmFI6Qe2+r5Ze4/ggvdo8MZWAOKddWG7fWf+ufNlZt75 cPrHyFLvUV8ZHaQW0baEGlkXhtkeTqS2cNDJ/4YpowgszVaD/SaCaQ/YAkVdRuHybgmx 91Bg==
X-Gm-Message-State: ALoCoQmFvtF68AtpFxRm6BaTVeAiTPDf2i1HuYNYeAf3vNJPCHwRtoLtrXgmWXeIFrsj4LVT8eSj
MIME-Version: 1.0
X-Received: by with SMTP id m28mr3738977iod.24.1449056323218; Wed, 02 Dec 2015 03:38:43 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 03:38:42 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 02 Dec 2015 11:38:42 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Yoav Nir <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 02 Dec 2015 11:38:45 -0000

On 12/1/15, Yoav Nir <> wrote:
>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <> wrote:
>> 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
>>>> 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.
>> 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?
> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on
> protocols to make sure that the stuff going over TCP port 443 is really
> HTTPS rather than an attempt at tunneling.  There are some attacks such the
> the code that protects against them needs to follow TLS record sizes. For
> the most part these are not-so-interesting attacks, causing certain versions
> of certain browsers to hang, and they are expensive for the firewall to
> protect against, so for the most part these protections are turned off. But
> it’s not everywhere.

Could you be more specific? Which devices are we saying will break? Do
you have model numbers? Are those vendors on this list? Do they agree
that this will break and do we agree that they are a relevant
stakeholder who has a user's security in mind?

For example, do we really care what sandvine or xkeyscore or narus or
similar vendors think? I think the answer is no. They're still going
to do extremely powerful traffic analysis and the more information TLS
leaks, the more they will use it to degrade the security of TLS for
all users. It may be that they will be full, on path, attackers and
yes, in some cases, they can do different more powerful attacks.
Again, we should treat that as a negative thing and make it as hard as
is possible.

> If enough middleboxes block TLS 1.3, the browsers will implement a downgrade
> dance. If they do that, attackers will be able to exploit the downgrade
> dance. I don’t think the net effect is better security. We’d be far better
> off writing a separate document on how to use the padding feature that is
> already in 1.3 to mitigate traffic analysis without actually flooding your
> Internet connection. Splitting records and padding a few can be more
> effective than masking the length bits.

Censors are going to perform surveillance and then censor; TLS 1.3
should treat surveillance as a security issue and censorship as an
attack. It may be that we can't stop certain kinds of on path attacks
but man on the side seems nearly entirely do-able. I mean aside from
the TCP reset issues do to layer violation concerns. At least we'll
have DTLS, which won't suffer from such a trivial denial of service...

All the best,