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

Dave Garrett <davemgarrett@gmail.com> Wed, 02 December 2015 20:13 UTC

Return-Path: <davemgarrett@gmail.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 0CF3C1B2C8B for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 12:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 avX0Jg8kSh54 for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 12:13:52 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FFC1B2C84 for <tls@ietf.org>; Wed, 2 Dec 2015 12:13:52 -0800 (PST)
Received: by qgec40 with SMTP id c40so43099523qge.2 for <tls@ietf.org>; Wed, 02 Dec 2015 12:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=+viA8VNQTQfYLGiBZdVa5okqWxHJQq83X/0oOxrpVMc=; b=zttygfWUi6jT7lGy9rloxwbqRiWoMt26ota5NGgAyLiL7d/Gkxy6B09XQ0ubBtg5nR Su2ApqVs6prURE4psvmqXz+eb9pp/cnYQnWW31Am5JovQTd4qLRzlO5ahDN/IJd9p1sr yN3yMBKlXrj4wNveRr6SuOZ3LBxqcaO/EYdBHbBo1f8xKp53JSxTrNRXUAlYITCjg/Rf PXvq5ZNTsfgo4fQSSCRDJtv1B6UnJjMpkbAg9/bYvxSAiabaoEruVcCqXeNbDkeiAdXb MJzHwWEInHq9ukbJuRP3fTez0owUcz6i5ZV6t7PMoKRUzk8mL6MY1pvB2ZsXkTKqdYmh vfAQ==
X-Received: by 10.140.155.75 with SMTP id b72mr6583986qhb.29.1449087231662; Wed, 02 Dec 2015 12:13:51 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id q133sm1863820qhq.20.2015.12.02.12.13.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 02 Dec 2015 12:13:51 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Wed, 02 Dec 2015 15:13:49 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAFggDF3HP5u0YP0UP_HrrZnrTnzc-CD1EG0grZBcb5sB7A2fAA@mail.gmail.com> <CAFggDF0D3Rgav-4xg-11u0igMyMXvAWT+JNt2r1xyQnpvm08Qw@mail.gmail.com> <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <0ba184c45d44474e961a2aaac82fec0e@usma1ex-dag1mb1.msg.corp.akamai.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201512021513.49894.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/j3Cxwe0uCAoosC0pjecRRnHX0fU>
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: Wed, 02 Dec 2015 20:13:54 -0000

On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
> 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.)

URL from Rich's previous email citing this:
https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view

Please don't brush this argument off in favor of the "obvious" answer that encrypted SNI is helpful. The sad truth is that it's a lot of effort with a lot of risk for virtually no gain. I was quite in favor of encrypted SNI before reading it, and I had to concede the point after. If we can come up with a way to do it easily, ok, but it's not an avenue worth spending too much time on.


Dave