[TLS] In support of encrypting SNI
Dan Blah <dan@blah.is> Wed, 14 May 2014 19:33 UTC
Return-Path: <dan@blah.is>
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 DA7881A0168 for <tls@ietfa.amsl.com>; Wed, 14 May 2014 12:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 3y6toN5qpYU2 for <tls@ietfa.amsl.com>; Wed, 14 May 2014 12:33:19 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F81A00D5 for <tls@ietf.org>; Wed, 14 May 2014 12:33:19 -0700 (PDT)
Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id E380453FBC; Wed, 14 May 2014 12:33:12 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: blah@fruiteater.riseup.net) with ESMTPSA id 59139BFF
Message-ID: <5373C4F3.3010602@blah.is>
Date: Wed, 14 May 2014 20:33:07 +0100
From: Dan Blah <dan@blah.is>
User-Agent: Postbox 3.0.9 (Macintosh/20140129)
MIME-Version: 1.0
To: ietf tls <tls@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vr7zvdx5YqpqTWAHahZm69nupWk
Subject: [TLS] In support of encrypting SNI
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: <http://www.ietf.org/mail-archive/web/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, 14 May 2014 19:37:50 -0000
Heya all, To start, I really appreciate what you all are up to here. In particular, the discussions with outcomes having an indirect or direct impact on Internet freedom and technology that advance human rights broadly. I'm writing in both my personal and professional capacity as managing director of the Open Technology Fund. We offer direct and in-kind support to global individuals and organizations confronting the many threats to Internet freedom globally. It's likely you're familiar with some of the 30 odd projects we provide direct support to including Tor, Open Whisper Systems, and Cryptocat. You may know we offer in-kind security and privacy audits to a much broader set of efforts we don't support directly such as TrueCrypt or OpenPGP.js. You may not know we offer in-kind access to secure cloud infrastructure and maintain support for an Internet freedom Digital Emergency Response Team. You don't know about the 30+ websites and numerous individuals we support who work to maintain an inch of free expression from inside countries with repressive regimes that restrict access to online freedom. Many of the discussions and subsequent decisions that move forward here are incredibly important to OTF's work. As such, I wanted to toss in our support for the coming version of TLS 1.3 to "Encrypt as much of the handshake as possible". This should include all of the metadata and TLS-layer routing information. We think by default is important for those threatened users we work closely with. We know this is just a start of a solution and only one aspect of it. We know that significant work needs to be done elsewhere to prevent passive or active tracking, censorship based on DNS, difficult website fingerprinting techniques, and other key threats to Internet freedom. Even those all addressed, in some situations we will fall short of aggressive censors. Despite that, it's a start, it's forward movement, and omitting these features in TLS 1.3 will make it that much easier for censors to silence the voice of journalists, human rights defenders, NGOs, activists, and bloggers around the world. Censorship is real, and we should fight against it where we can. If you smarter folks than I make these changes in TLS 1.3, valid recipients of the online data will be able to handle incoming traffic however they wish, but the networks or repressive governments in-between should not be able to block or degrade service based on plaintext metadata. Daily, we are witness to censorship occurring at the service level in every corner of the world. The effects are felt by small website hosts to Google and Facebook. Leaving some of this information in plaintext may seem insignificant to many here but it's of significant value to those who would suppress free expression online. Surely any crucial increase of free expression we here can give others out weighs technicalities. Thanks in advance! -- Dan Blah pgp 0x36377134
- [TLS] In support of encrypting SNI Dan Blah
- Re: [TLS] In support of encrypting SNI Salz, Rich
- Re: [TLS] In support of encrypting SNI Seth David Schoen
- Re: [TLS] In support of encrypting SNI Stephen Farrell
- Re: [TLS] In support of encrypting SNI Watson Ladd
- Re: [TLS] In support of encrypting SNI Michael Carbone
- Re: [TLS] In support of encrypting SNI Fabrice
- Re: [TLS] In support of encrypting SNI Christian Huitema
- Re: [TLS] In support of encrypting SNI Daniel Kahn Gillmor
- Re: [TLS] In support of encrypting SNI Robert Ransom
- Re: [TLS] In support of encrypting SNI Stephen Farrell
- Re: [TLS] In support of encrypting SNI Marsh Ray
- Re: [TLS] In support of encrypting SNI Watson Ladd
- Re: [TLS] In support of encrypting SNI Martin Rex
- Re: [TLS] In support of encrypting SNI Watson Ladd
- Re: [TLS] In support of encrypting SNI Martin Rex
- Re: [TLS] In support of encrypting SNI (off-topic) S Moonesamy
- Re: [TLS] In support of encrypting SNI (off-topic) Michael Carbone
- Re: [TLS] In support of encrypting SNI (off-topic) S Moonesamy