Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Jacob Appelbaum <> Fri, 04 December 2015 15:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D21AF1A87E1 for <>; Fri, 4 Dec 2015 07:39:20 -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 wvYE6kfKfkqx for <>; Fri, 4 Dec 2015 07:39:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC9FC1A87EF for <>; Fri, 4 Dec 2015 07:39:13 -0800 (PST)
Received: by igl9 with SMTP id 9so35274265igl.0 for <>; Fri, 04 Dec 2015 07:39:13 -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; bh=KPVmW4mfj80mrs8OpIXAPp0PdJLV3RtC/5HY3u6NLqU=; b=V+O8N9spU0DACx/1Qgev2tJb935Utnl4KLaCxlevfjBH/R6e1Eta1i/2HjsgNJgSkb SmNAML0GCirDnoeHLCssUG99b3EySjiaFHoeYjngNBmBdaozFnkD1mvdHcdkgj33APM4 af1TVxgKigRzfL8O4OW3t47bX7thkyhEiSaivLjM/tVMFhiUNFrw76jIUe+SSksw/e3z 0gZ70YCjy1RW+JKSmjKpl7bVQLsrCmafeben1c6zwsSiuAF+PTUjr44HeWzKfK7f5q5I RiHc3cjknKlWxS8yFw02pmK7ctdqrxm6v1RAa6uLAvc8/b/vRXUtK+ux9Zsl+U0NRQSK 0WLA==
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; bh=KPVmW4mfj80mrs8OpIXAPp0PdJLV3RtC/5HY3u6NLqU=; b=V9eW0tQ2fl69CcKDMBwz17x8T4aFycUSO/LVdqQMrf9KSWG1pShJ/F9OowcsnHWK4j OcgQ6YQN0+4OUXLITJX2Lazewcw+sJ2TzHbIVBJi8ia9fTxPg/S2XVhxQOumSjytwtQJ oPgB3SU0uWGTBpeDuLt9FTriPbXbhWfvGSyHS8GK9HlYw/wg9GFLgMSyWieM6Gifo+D5 iJHbr682dUvkLEKWG/JVE8Bo2Xydb7vZrg4JCm9bxJ7FF5kJEyY2jmvzbWXROAcyPPJU zp7nn45jENzNJxXYbalqR7XftfLZyA9wCXuMYHR82LhKLEvetL6+7CMLPbjwB1Qm+e2h 67Jw==
X-Gm-Message-State: ALoCoQk1jExiTnd28IRVihpaV2/gGAf6bnJuzti+5AW4b8DgQrD6qR3Mq2H4YGdwZRJ3b+/40VuD
MIME-Version: 1.0
X-Received: by with SMTP id vu9mr4815061igb.89.1449243553239; Fri, 04 Dec 2015 07:39:13 -0800 (PST)
Received: by with HTTP; Fri, 4 Dec 2015 07:39:13 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Fri, 04 Dec 2015 15:39:13 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Watson Ladd <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: 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: Fri, 04 Dec 2015 15:39:21 -0000

On 12/2/15, Watson Ladd <> wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <>
>> I think that it eliminates all static distinguisher in the protocol
>> for all data covered by the encryption. That is a fantastically
>> wonderful benefit.
> What's a "static distinguisher"? Padding solves this problem as well,
> but it also solves problems resulting from TCP segmentation down the
> stack, which header encryption doesn't. What does header encryption
> offer that padding does not?

Fixed parts of a protocol are often considered as static
distinguishers - most are unavoidable unless you take the Scramblesuit
design approach and have a keyexchanged out of band. Elligator is
another useful design in this direction.

In the case of TLS, we've seen a specific Oakley group used as the
distinguisher that selected all related (TCP) flows for disruption.
Changing that to a (well formed) randomly selected value allowed
traffic to flow freely again. Other static values like a site specific
plaintext name are used much more commonly.

I could imagine for example that all records with a given length can
be selected and dropped, for example. Common VoIP applications that
use fixed lengths are thus even easier to censor with an exposed
length field. With that value hidden and with *random* padding, I
think the ease of selecting specific flows would be reduced and the
cost would be much higher. No everyone needs padding but many people
will want that value hidden without a useful way to do it unless the
protocol supports it by default.

All the best,