[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