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

Eric Mill <eric@konklone.com> Thu, 03 December 2015 01:55 UTC

Return-Path: <eric@konklone.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6EB1B2B62 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 17:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAyO9j5eAk3l for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 17:55:38 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp0.int.icgroup.com [208.72.237.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE81D1B2B2C for <tls@ietf.org>; Wed, 2 Dec 2015 17:55:37 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 3AC3C30AC9 for <tls@ietf.org>; Wed, 2 Dec 2015 20:55:37 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=z1kIFSK/CQssOimy+rECefu6F48=; b=lBqFsB HImjuwzh8JSmfANS0Q5CtxkUjIvyN5036ADvuUxio+Ze9PnW5dr7mapzEOn4YJTH 2QLj5xbn43ca4lJ1sMS/yjEKqEAaj/agbhXP97IrVCHk7O5i7DGfZasmcj5qGJer 06AX96CwjlQVKH1E+0Osvz/KaTyhT285nXqho=
Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 33BBD30AC8 for <tls@ietf.org>; Wed, 2 Dec 2015 20:55:37 -0500 (EST)
Received: from mail-ig0-f174.google.com (unknown [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id A645830AC4 for <tls@ietf.org>; Wed, 2 Dec 2015 20:55:36 -0500 (EST)
Received: by igcto18 with SMTP id to18so1934304igc.0 for <tls@ietf.org>; Wed, 02 Dec 2015 17:55:34 -0800 (PST)
X-Received: by 10.50.57.44 with SMTP id f12mr34054359igq.29.1449107734650; Wed, 02 Dec 2015 17:55:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.2.70 with HTTP; Wed, 2 Dec 2015 17:54:54 -0800 (PST)
In-Reply-To: <CAFggDF24hhrXS95kONb_N6XHrO+11wFsAkHOpYZ_uu5RvyV+Kg@mail.gmail.com>
References: <CAFggDF3HP5u0YP0UP_HrrZnrTnzc-CD1EG0grZBcb5sB7A2fAA@mail.gmail.com> <20151202160837.6016A1A39B@ld9781.wdf.sap.corp> <CAFggDF0D3Rgav-4xg-11u0igMyMXvAWT+JNt2r1xyQnpvm08Qw@mail.gmail.com> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com> <CAFggDF119jxPSXUAe2E4y_TQds4P3K1eTGM3sZHSa=NoeMOV-A@mail.gmail.com> <1b5cf52ca90e45bd82f5247ca675dead@usma1ex-dag1mb1.msg.corp.akamai.com> <CAFggDF24hhrXS95kONb_N6XHrO+11wFsAkHOpYZ_uu5RvyV+Kg@mail.gmail.com>
From: Eric Mill <eric@konklone.com>
Date: Wed, 02 Dec 2015 20:54:54 -0500
X-Gmail-Original-Message-ID: <CANBOYLXJX_gjuC8Rp0Z9YqzNYsbr0x1WeL4AeRUxFtMaM+U5wQ@mail.gmail.com>
Message-ID: <CANBOYLXJX_gjuC8Rp0Z9YqzNYsbr0x1WeL4AeRUxFtMaM+U5wQ@mail.gmail.com>
To: Jacob Appelbaum <jacob@appelbaum.net>
Content-Type: multipart/alternative; boundary="e89a8ff24d9dc3e4b80525f4afeb"
X-Pobox-Relay-ID: F25FB6DE-9960-11E5-AD22-6BD26AB36C07-82875391!pb-smtp0.pobox.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FF19t_rcMZoK4_5BisNMW-RP4YE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2015 01:55:39 -0000

On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:

> On 12/2/15, Salz, Rich <rsalz@akamai.com> wrote:
> >> it seems blindingly obvious to me that we want it
> >
> > Few things, particularly in the security arena, are blindingly obvious.
> If
> > it actually provides no true protection, then it's just as bad as the
> > security theater in US airports.
>
> It provides protection. Specifically it provides confidentially.
>
> It doesn't solve the fact that the DNS is a privacy violating
> nightmare. It doesn't change the fact that the NSA breaks the rules.
>

And what Don and Rich's analysis is trying to isolate is how much real
protection you get from that level of confidentiality, so that a decision
that weighs all available factors can be made, including the complexity
cost.

It's not just a collective action problem because DNS isn't encrypted too.
Their analysis also looks at what you get when both are encrypted. And
regardless of DNS being encrypted, rainbow-table style reverse lookups of
IP to DNS name are always possible. That doesn't mean encrypted SNI isn't
worth it -- it clearly provides a security attribute (confidentiality) to
an important piece of information.

But it's not enough to drive ahead and say that some attribute outweighs
every other consideration. For example, HSTS' persistence of memory can be
abused as a tracking device:

http://zyan.scripts.mit.edu/sniffly/

And this was known at the time the spec was finalized:

https://tools.ietf.org/html/rfc6797#section-14.9

But HSTS creates security benefits that are well worth the cost of that
tracking potential (which can also be mitigated through preloading). There
are a lot of browsers and communities which use and advocate for HSTS that
might generally balk at creating tracking devices.

I'm not advocating a strong stance on whether encrypted SNI is worth
pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But
it's useful to keep the debate framed in its full context, rather than
narrowing it to a black-and-white discussion over whether a generally good
attribute is good or not.

-- Eric