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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 093561ACDD3 for <>; Wed, 2 Dec 2015 10:11:54 -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 0phPDUhSLPMD for <>; Wed, 2 Dec 2015 10:11:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 229AA1ACDDC for <>; Wed, 2 Dec 2015 10:11:52 -0800 (PST)
Received: by igvg19 with SMTP id g19so123797421igv.1 for <>; Wed, 02 Dec 2015 10:11:51 -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=0oHwmb3vLm72Bz2qN3KoSe5E8LSUUhVQKVl5Yov5nMg=; b=xbhDxAw8AtoAiNMvOQec7U98xY+bhh9EaEQgDr2+xw9LrnjOO5kPLrhRdW8jYWmivc 7qes58X3cLJ80aiQRe1lwKBS3KHLnxqT2uwHmQ5ZYu2LxLw9gVIoMaX6hWrBbxRUBbhQ L8LSbhmNTjdtBuJTPj9OFdXNK7r4dqTN2oe+6MhX/bqIW+0hwzT/8GYwAeDgBgbgclfr cn3/9lqUWb72RZeLG8F/1UupqpXyqGrosq1hARk7yKo5pT4vLripifVMS+6kTb5wRMcN xYOv7OsObq2E9bT7x6rl8g03Ay4UvuRBYF5IJ/rWIjwEGjP05NjQ9G0BUhQvounRn+oP 4EMA==
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=0oHwmb3vLm72Bz2qN3KoSe5E8LSUUhVQKVl5Yov5nMg=; b=ZkA0PyDzZCemkcfOY6ASHEhFAD/hXasJM/mH8NmTeHqDcoVZxC7W2QexaC9QrmA1GW lziiTT516P139z92qoXVaJuCD2268aEpTP3EA43GtBHUm4ASgGAzwQtpncHh+KyNsizG 2U5F8dqfD0tQe2uuiUR1o9XQ7CvhUsybd+C4+f55yrX/Tg9vHMb9iKQ8qt/KeAr5zhuJ ngGHyLLry8jPlJT68RDLDcAELT4GRKlQmeSfyWgtFnjtbJhZNJA+bf+iymPymkOHJAbk sF4pjtVqGX8VjA1HT4bug0VJUzE0g2q3vn8Wbg5m31oi3Bmx9j1OHK9XpiZ9Y9Q+3GB8 2Trw==
X-Gm-Message-State: ALoCoQlgJgsJeC5ZAb3O0MFAV1FmbMVJAQ2is7N95KXGMT0r/yKvaOGbd/J7sGqo3BcWn9hjomAa
MIME-Version: 1.0
X-Received: by with SMTP id c18mr8550604igr.82.1449079911433; Wed, 02 Dec 2015 10:11:51 -0800 (PST)
Received: by with HTTP; Wed, 2 Dec 2015 10:11:51 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 02 Dec 2015 18:11:51 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: "Salz, Rich" <>
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: Wed, 02 Dec 2015 18:11:54 -0000

On 12/2/15, Salz, Rich <> wrote:
>> I think that is false. One could easily use the "cleartext" SNI field and
>> insert an encrypted value. A hash of the name would be a simple example
>> but not a secure example, of course.
> Encrypted SNI doesn't give you the kind of protection you think that it
> does.  We (me and a colleague) did a pretty thorough analysis that showed
> this.  It was not a conclusion we expected, or wanted, to reach.   It was
> presented at the TLS Interim before the IETF in Toronto.  Slides should be
> online.  (For example, the adversary will know the IP address or might not
> care about false positives, etc.)

Without a concrete proposal, I don't think we have any protection. My
thoughts were more about the idea that we would *want* protection of
SNI data - it seems blindingly obvious to me that we want it as we
know SNI is used for attacks in addition to multi-homing tricks.

I'm aware that layer issues make for many layers of selectors for
attack. If we can avoid adding them in TLS, we can also work on
improving things on every level. IP address blocking has the
"collateral freedom" problem, of course.

> In spite of this, another colleague (Brian Sniffen) came up with a way to do
> it at the tail end of the Seattle interim.  Encrypt the "true" SNI in the
> semi-static DH key of a "fronting" site.  And then the front decrypts the
> true SNI and forwards to the obscured site. Ekr and dkg presented it in
> Yokohama, but not very well. :)  They're presumably working on something
> better.

I'm certainly interested in reviewing any cryptographic details for a
possible SNI protection scheme. It sounds interesting and am looking
forward to learning more.

All the best,