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

Jacob Appelbaum <> Thu, 03 December 2015 04:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 516D11B2F70 for <>; Wed, 2 Dec 2015 20:02:00 -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 8w6zpNtg3I38 for <>; Wed, 2 Dec 2015 20:01:59 -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 689D81B2F5F for <>; Wed, 2 Dec 2015 20:01:59 -0800 (PST)
Received: by igcmv3 with SMTP id mv3so4872449igc.0 for <>; Wed, 02 Dec 2015 20:01:58 -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=B8RQPKo80ZYJuEw5Ibesl8PHViHy0+F+xRrtE0UCdZE=; b=H9RhPpHhStI0ONEFmJ6iZOrdng9+3/KBuUudbFt+9gioEIIeqQ/52ZfKGO5i/o98jI /QAJeL6WhvjY0SoiIdPlbqmTsUnA2PLAZVAKDfv7sFiQQL36MNiZrpc43u5XGM6S7ZJo SfF2VeKHFjPBq/b1qB3dJU4EV2vNOl/5a80+WQEw6W/l1YGu4tmzfOg+jA2Sz0l/degO fJx+dBBKOZmx+kSAAhFSV1mABSlbN79mrp+CujxjLo3h5m+NtgHQ6QUPusHLjL0cHhGL 06Jkh/5JVL8VFb4DzmiUSo9+4YE94+iz4kX69GIwCyJEPtwu3OSw+SCE+c4p5GsDnp6l cb0w==
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=B8RQPKo80ZYJuEw5Ibesl8PHViHy0+F+xRrtE0UCdZE=; b=AXVkilkhoWDcbpeHWpadS//PNUQqGOr2zVist+6KksDGCKTVUcxibarPhagzqV+jke PrChD4ZmaeD3wVBiw5cq+XSrL8G37gzbSJfXQBx+dDzPim1FSVRho05JztNbu9jVPUTI U5dYa91Ol1d5IDXJGgsHTPO56mItTMkT4MsBPgScQeGJErNA4E3qKHXRUQG2F6S/l9AV M0+yKXSSWuSeSl2os04tqV1XO5+JHeKnBhsdoF2Q7m4mSjzkSUZ2s8Cl5AKLn8RDfA+2 YGMGP7qIUqF8Dr2BU/I81P0iQCdKI4EYBeOL17JYf2O+fYaCIvUMGG0cAiU5eWjb+qFn Z4Ug==
X-Gm-Message-State: ALoCoQn85PqJJRtHjK9s+BCSaFbTAtFoxU1J2Fu1rrZ+umfTJDe/cbsMdDkyNOXXvMAYhX9sUpH3
MIME-Version: 1.0
X-Received: by with SMTP id c18mr10543929igr.82.1449115318777; Wed, 02 Dec 2015 20:01:58 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 20:01:58 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 03 Dec 2015 04:01:58 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Martin Thomson <>
Content-Type: text/plain; charset="UTF-8"
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: Thu, 03 Dec 2015 04:02:00 -0000

On 12/3/15, Martin Thomson <> wrote:
> There are a lot of inaccuracies in that presentation, so I wouldn't
> pin too much on it.

I'm not pinning too much on it and I was surprised by the amount it
was suggested would win me over. I actually went in thinking that I'd
be crushed and concede; imagine my surprise!

> In any case, before we all get too excited about this, there are some
> solutions, I've seen a write-up of one of them, but it was a little
> hard to follow first time around.  Some of the things that are
> described as impossible aren't that hard to fix.  On the flip site, it
> doesn't provide a fully general solution.

The question up for debate seems to be if we should bother and I think
that yes, we should bother. I spent some time today thinking about
solutions for encrypting not only SNI but also other headers. It isn't
entirely clear how to solve this problem in a few cases - but
especially in the case of a repeated visit or a site that has an HSTS
entry, I can see a few ways to protect the information.

> Expect to see something very soon.  Until then, I don't think that an
> in-depth on what isn't even at a straw-man level of detail is that
> helpful.  We need details before we can say whether the cost-benefit
> makes sense.

Where is the design actually happening? I know a few cryptographers
who are interested in the design process.

All the best,