Subject: Re: [TLS] In support of encrypting SNI

From: Michael Carbone <[email-masked]>
Date: Thu, 15 May 2014 00:55:57 -0400

Seth Schoen writes:

>> Dan Blah writes: 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.

> I would like to add the Electronic Frontier Foundation's support to 
> this view.  We have been learning so much recently about the privacy 
> significance of communications metadata.  At the time that many basic
> Internet protocols and mechanisms were created, the cutting edge of
> privacy was providing merely optional mechanisms to protect session
> content.

Hi folks,

Access shares this view and we would like to add our strong support with
Dan at OTF and Seth at EFF for encrypting the TLS handshake by default
in TLS 1.3 --  protecting the server certificate, a client certificate
if used, and all TLS-layer metadata/routing information, such as SNI and
ALPN.

Access is an international human rights organization that uses policy,
user engagement, and direct technical support to defend and extend the
digital rights of users at-risk around the world. The global Access
community is nearly half a million strong, and we have provided
technical support to civil society organizations and human rights
defenders in over 35 countries. This direct technical support is
provided by our digital security helpline staff to individuals and
organizations in high-risk environments, helping these targeted groups
securely host content online, mitigate digital attacks such as DDoS,
secure their communications, bypass censorship, and defend against
surveillance.

In addition to helping protect the privacy of such users from
surveillance, encrypting the TLS handshake by default would better
enable the access to otherwise censored websites and services,
especially if they are served through unblocked content delivery
networks (see the "Collateral Freedom" report for further details on
this particular access strategy). As Dan and Seth have mentioned, we
recognize that such a move will not solve all access or surveillance
problems by itself (hence DNSCrypt etc), but I hope we all recognize
that it would be a tremendous step forward in enabling users to more
securely exercise their rights online, especially those most at-risk.

For us, attempting to encrypt TLS handshakes by default is part of a
broader movement of platforms, companies, and projects to rethink the
default security position they provide users. Given the ease by which
unauthorized actors can access large amounts of personal information
without any judicial process or oversight, and the lack of awareness or
control users have in the security of their online interactions, we all
need to evaluate the ways we can make encryption more accessible and
ubiquitous for users. Our Encrypt All The Things campaign
(https://encryptallthethings.net) outlines some steps designed to ensure
a minimum level of default security for users online, and we believe
supporting the IETF in its consideration of more ubiquitous default
security for internet users fits strongly into this movement.

We hope the IETF considers the needs of at-risk users as well as of all
of us targeted by pervasive monitoring in supporting encrypted TLS
handshakes by default.

Best,
Michael

-- 
Michael Carbone
Manager of Tech Policy & Programs
Access | https://www.accessnow.org

GPG: 0x81B7A13E
Fingerprint: 25EC 1D0F 2D44 C4F4 5BEF EF83 C471 AD94 81B7 A13E

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 May 2014 11:14:32 +0100

Hiya,

One more thought for this thread before the meeting (for which
I'll unfortunately be remote and distracted but I'm sure you'll
have a good one).

Considering tempora, which we know is happening, (so handshake
bytes should be considered to be recorded with probability of
approx. 1.0), even a simple hash of the SNI could have some
limited value.

Say if the client sent "hash-algId,H(tolower(SNI)||stuff)"
or similar rather than sending just "SNI" (where "stuff"
is maybe something to distinguish http vs imap perhaps).

For the real server/router that's no deal at all assuming the
router isn't dynamically routing to any old DNS name used
in SNI. (Wouldn't that be a lovely DoS vector.)

For the tempora attackers it'd mean they can no longer just
do "select * from tempora_db where sni like %victim%" (pardon
my SQL which is probably wrong;-)

Now that might just be an irritant, and not that effective
given the adversary can build up tables but I think it is
an attack that we do need to specifically consider since
we *know* the recording of those bytes is happening.

And of course if we had a structure like "f-algId,f(SNI)"
then other algs (e.g. encrypt with public key from DNS)
could be added later if we can't use 'em now, so even
adding this minimal bit of "protection" might provide
the right hooks for later, better work.

A workable SNI encryption scheme is of course what we'd
like, and would blow the above out of the water, but if
we don't find a workable SNI encryption scheme now, there
might be reasons to think about the structure above and
there are definite reasons to think about tempora as an
attack.

Cheers,
S.

PS: To be clear, I'm more arguing for considering the
tempora attack here and maybe for the structure and am
not really a fan of a simple hash.
And #include <hatstatement> as usual.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 15 May 2014 21:50:24 +0000

From: Stephen Farrell
http://www.ietf.org/mail-archive/web/tls/current/msg08722.html
> A workable SNI encryption scheme is of course what we'd like, 
> and would blow the above out of the water, but if we don't find
> a workable SNI encryption scheme now, there might be reasons
> to think about the structure above and there are definite
> reasons to think about tempora as an attack.

Dan Blah writes:
> 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.

From: Nikos Mavrogiannopoulos
> The best would be for TLS 1.3 not to bump the protocol version number.
> It could masquerade as TLS 1.2 and use extensions to negotiate any new
> functionality. That way it wouldn't have any interoperability issues
> (if we ignore for a moment the client hello size issues).

Apologies to those who have heard this before, but I lose stuff in the volume.

A couple of years back I made a detailed proposal precisely for encrypting
"as much of the handshake as possible" (including SNI) using
TLS 1.0-compatible extensions:

http://tools.ietf.org/id/draft-ray-tls-encrypted-handshake-00.txt
   This specification defines a Transport Layer Security (TLS) extension
   which allows endpoints to negotiate the use of encryption with
   forward secrecy at the beginning of the handshake.  Two levels of
   functionality are defined.  Implementations are free to support one
   or both levels, with the first level incurring no additional
   computational or round-trip overhead.  The TLS cryptographic
   calculations are unchanged.

The Introduction section describes my then-current thinking on the
topic. The ensuing list discussion felt productive:
http://www.ietf.org/mail-archive/web/tls/current/msg08722.html

- Marsh
---------------
Boilerplate disclaimers apply.

---

From: [email-masked] (Martin Rex)
Date: Fri, 16 May 2014 06:38:01 +0200 (CEST)

> is maybe something to distinguish http vs imap perhaps).

The underlying idea is in principle correct:
if the client does not want to disclose the server's hostname, then the
client plain and simple MUST NOT send that hostname in TLS extension SNI.

It is conceivable that the client could send something else instead,
that the server could use for dispatching the TLS session to the
correct virtual host (independent of whether that is physicial or
logical routing of the TLS session).

> the right hooks for later, better work.

While something like publishing an RSA public key in DNS and
using an encryption transform with random padding (PKCS#1 BT02 or OAEP)
could provide the functionality, this would also significantly
increase the server's workload (make TLSv1.3 session resumes as
expensive as TLSv1.2 static RSA full handshakes) and make the
key management (the rollover) a magnitude more difficult from
what it is now (not counting the accompanying code complexity).

If the whole SNI-hiding scheme would depend on the necessary key being
available in the DNS, then those servers that have only a single
server credential or that need high performance could avoid the
entire bloat, and that would be the most important aspect of this.

Personally, I consider pretty much all of the ideas that have been
floated so far, to be magnitudes of complexity beyond what I could
risk shipping to our customers from the usability viewpoint.
TLS key management is already the number one support issue today,
and the first customers started suffering from server load when
moving from RSA-1024 to RSA-2048 (even for static RSA key exchanges)
when there were problems with TLS session caching on TLS clients.

For our current TLS implementation, I can update&replace the server
credential (key,cert and cert chain) as well as trust anchors for
the verification of client certs in "full flight" (i.e. zero downtime),
but for multiple server keys distributed through different protocols
(DNS OOB plus TLS inband), I can not even conceive a robust / zero
downtime key management and key rollover.

Actually, I'm much more worried about the services on the internet
today that still do not use TLS at all (many discussion forums,
online shops and places like ebay), and I have exactly
ZERO problem doing online banking over TLS with static-RSA and RC4-128
or TLSv1.0 and CBC.

And I'm somewhat worried that making TLS more complex, administration
more difficult, troubleshooting harder and performance impact worse
is going to further deter adoption of TLS by the large unwashed masses
of today's HTTP-in-the-clear usage scenarios, similar to how feature bloat,
complexity, and poor usability still deters deployment of IPv6 today.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 15 May 2014 22:19:43 -0700

> what it is now (not counting the accompanying code complexity).

There are proposals out there (DH channel, authentication through
signing shared key) that require the server to do two exponentiations,
at the cost of multiple round trips. That's more performant in CPU
time than RSA-2048, and doesn't involve DNS keys. (Yes, I'm aware most
people don't use ECDSA: but why moan about speed when you haven't
already used the fastest option there is?).

Furthermore, many of the proposed changes in TLS 1.3 reduce
complexity: one padding scheme instead of three, dramatically reduced
numbers of allowed flows, obviate the need for secure renegotiation by
fixing the underlying problem, eliminate ciphers whose security has
been called into question, remove some little-used certificate
options, and hopefully simplify administration even further.

If you want simplicity CurveCP can be implemented in ~1,00 lines of
C+100*140 characters of underlying crypto. It has similar security
properties to the handshakes were are discussing now, and much more
performance.

I share your concern about ubiquity in HTTP: that's being fixed with
opportunistic HTTPS/not popping up a great big warning sign for
self-signed certificates. I don't think protocol complexity is what's
holding back deployment today so much as the cost of certificates
(which DANE addresses) and the complexity and hassle of management of
keys.

Sincerely,
Watson Ladd

> -Martin
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: [email-masked] (Martin Rex)
Date: Fri, 16 May 2014 21:57:26 +0200 (CEST)

Watson Ladd wrote:
> Martin Rex <[email-masked]> wrote:
>>

I believe we're talking past each other here.

On a healthy TLS server, the ration of abbreviated TLS handshakes
vs full TLS handshakes is around 50:1.

The abbreviated TLS v1.[012] handshake is entirely *FREE* of public key
crypto, and the ClientHello on a new connection that offers the abbreviated
TLS handshake carries in the clear *ALL* information necessary for
routing the TLS session and for performing a full TLS handshake
in case that session resumption might not possible.

Public Key crypto on abbreviated TLS handshakes would make TLS prohibitively
expensive for many/most large server installations of our customers.

> complexity: one padding scheme instead of three,

The only thing that reduces complexity is complete removal of options,
and even then this just applies to the specification itself.

For an implementation, you can not seriously expect interop without
implementing all of TLSv1.0 through TLSv1.2 in addition to TLSv1.3,
so even removal of an existing option adds code.

New features or changing exiting options will increase complexity of
implementations and cause interop failures in the installed base due
to a lack of of testing (cartesian explosion).

One large vendor botched the RSA premaster secret version check
when starting to ship TLSv1.2 support.  A problem that would have
been obvious and impossible to miss for a single engineer in pure
black-box testing with _his_own_ shelf clients and servers
within 15 minutes.

> properties to the handshakes were are discussing now, and much more

Someone who talks about new crypto, and projects effort in terms of
Lines-of-Code, may not have to deal with issues like FIPS 140-2...

> (which DANE addresses) and the complexity and hassle of management of

The reason that many discussion forums, online shops and ebay do not
use https today is probably _not_ the browser/client side, but getting
the server-side (setup,admin,maintenance) work, i.e.

 - key&trust management
 - key continuity & rollover
 - PKIX bureaucracy and (lack of) interop fun

-Martin