Subject: [TLS] draft-ray-tls-encrypted-handshake-00.txt

From: Marsh Ray <[email-masked]>
Date: Fri, 04 May 2012 11:21:11 -0500

I would appreciate it if the participants of the TLS WG will give this 
draft a reading and serious consideration to taking it up as a work item:

------------------------------
http://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/

A new version of I-D, draft-ray-tls-encrypted-handshake-00.txt has been 
successfully submitted by Marsh Ray and posted to the IETF repository.

Filename:	 draft-ray-tls-encrypted-handshake
Revision:	 00
Title:		 Transport Layer Security (TLS) Encrypted Handshake Creation 
date:	 2012-05-04
WG ID:		 Individual Submission
Number of pages: 18
Abstract:
    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.
------------------------------

This draft is motivated by the discussions in recent weeks, when some 
related issues came up in a similar context:

* AGL et al. have some particular requirements for the handshake when 
using the NP(N)/SPDY feature. They really need confidentiality in 
negotiating the next protocol but they cannot afford the overhead of 
even one extra round trip (let alone renegotiation). I would like for 
them to be able to implement NP(N) in an RFC-defined way.

* When coupled with the RFC 4680 'TLS Handshake Message for Supplemental 
Data' that Martin Rex pointed out, it provides a powerful and very 
general way of negotiating features under encryption. It could possible 
enable new features.

* Alternatively, we could view this as a round-trip-saving optimization 
for certain handshake operations that really do need encryption.

* It allows to encrypt the client certificate without renegotiation, 
magic cipher suite values, or a bunch of new protocol that isn't useful 
for anything else.

* I watched a fascinating presentation from the Tor project
https://www.youtube.com/watch?v=GwMr8Xl7JMQ
Unfortunately, they are having to minimize their dependence on TLS 
because it's so easy to DoS selectively. I don't know if this proposal 
will make TLS suitable for Tor again, but I do think it represents a 
shortcoming of the protocol which deserves fixing.

* There's simply no reason TLS needs to leak so much plaintext.

* I believe it may help a little with the issue Nikos Mavrogiannopoulos 
and I were discussing, where an attacker is able to trick the client 
into interpreting the server's signed key exchange parameters as the 
wrong type of structure.

* To the implementers in the group: don't be fooled, it's not as big a 
change as it looks! I just tried to be extra careful to describe it 
step-by-step in the spec. Did I mention it doesn't change the crypto 
calculations?

Thanks,

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Fri, 4 May 2012 12:37:20 -0400

On Fri, May 4, 2012 at 12:21 PM, Marsh Ray <[email-masked]> wrote:
> I would appreciate it if the participants of the TLS WG will give this draft
> a reading and serious consideration to taking it up as a work item:

Marsh was good enough to share an early draft of this with me.

For now I would like to gloss over the details of the proposal in
order to concentrate on the intention:

I believe that this would be beneficial. It rather neatly solves the
encrypted client certificates problem and, probably, others in the
future. It would allow NPN to encrypt both the server's protocols and
the client's selection without additional round trips.

I would like to commend the idea to the working group.

Cheers

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 May 2012 11:49:07 -0700

Was it intentional to leave out the ChangeCipherSpecs that immediately
precede Finished?  I think they still need to be there.

Mike

Marsh Ray wrote:
> Title:         Transport Layer Security (TLS) Encrypted Handshake 
> Creation date:     2012-05-04

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 May 2012 13:56:10 -0500

> precede Finished? I think they still need to be there.

The intent was to move the CCS from late in the handshake to as soon as 
practical in the handshake without changing their meaning. So, yes.

Are you saying just the CCS records still need to be there, or we really 
should plan to change the cipher a second time? Why?

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 May 2012 14:22:31 -0500

> precede Finished?  I think they still need to be there.

It's not left out.  It's moved earlier in the exchange, and that's the
whole point: encrypt as early as possible.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Sat, 5 May 2012 00:13:20 +0300

Hi Marsh.

Interesting stuff. There have been several ideas for moving parts of the handshake to after the CCS. There's NPN, identity protection, and even the EAP-in-TLS draft. Your draft takes care of the identity protection, but accepting it would also make the others easier.

I think this moves TLS to be more like IKE, where encryption of the IKE protocol precedes everything else (authentication, configuration, and IPsec setup)

IMO this is a huge change to the TLS state machine. Much bigger than the diff between TLS 1.1 and 1.0, and bigger than the difference between 1.2 and 1.1. This should not be an extension but a new version number. You would still need an extension to carry the extra information (if we want backwards compatibility), but negotiating this capability should be done at the version level.

Yoav

On May 4, 2012, at 7:21 PM, Marsh Ray wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> Scanned by Check Point Total Security Gateway.

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 May 2012 16:53:44 -0500

> IMO this is a huge change to the TLS state machine. Much bigger than the diff between TLS 1.1 and 1.0, and bigger than the difference between 1.2 and 1.1. This should not be an extension but a new…

But the experience we've had with new versions doesn't fill one with
confidence that a new version can be deployed quickly at all.
Extensions have been much less problematic.

I think it'd be best to introduce new versions only for dramatic
changes that require downgrade protection.  (I realize that's not a
great description of the rule I have in mind.)

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 May 2012 21:36:50 -0700

> practical in the handshake without changing their meaning. So, yes.

If you don't perform a second CCS prior to Finished, then there are
two problems I see:

   - you can not use RSA key exchange anymore; how about PSK or SRP?
   - multi-homing is hindered -- different virtual servers on the same
     machine could prefer different bulk encryption and MAC algorithms

Sending a second CCS solves both problems, and is not expensive either
in network overhead or running the PRF again.

In cases where a non-DH key exchange is preferred, the first exchange
could be the same as DH_anon.

Mike

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 May 2012 23:44:51 -0500

> could be the same as DH_anon.

Ah, that makes sense.  I'd earlier (off-list) proposed to Marsh to
just keep the CCSes in the messages they were already in, just move
them up.  But there's value to encrypting things as early as possible.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Sat, 5 May 2012 16:41:32 +0300

>   - you can not use RSA key exchange anymore; how about PSK or SRP?

That is a feature. With this draft, the server has to perform two asymmetric operations anyway: one for the key exchange (most likely D-H), and then it still has to do another one as proof of possession of the private key (or for SRP). The only advantage of RSA keying was that you got both in one operation, and that's gone anyway.

>     machine could prefer different bulk encryption and MAC algorithms

Agree.

> in network overhead or running the PRF again.

The PRF is not expensive. It's the operation used to generate the seed for the PRF that is expensive. It should be noted that this is a disadvantage of this proposal.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 May 2012 06:44:10 -0700

> IMO this is a huge change to the TLS state machine. Much bigger than the diff between TLS 1.1 and 1.0, and bigger than the difference between 1.2 and 1.1. This should not be an extension but a new…

It is a huge change in the TLS state machine, but only when both parties fully understand the change, as signaled by the extension. There is no need to change the version number: there is no chance one party won't know what is going on.

--Paul Hoffman

---

From: Marsh Ray <[email-masked]>
Date: Sat, 05 May 2012 10:48:43 -0500

On 05/05/2012 08:44 AM, Paul Hoffman wrote:
>
> It is a huge change in the TLS state machine, but only when both
> parties fully understand the change, as signaled by the extension.

It is a change, whether or not it's "huge" probably depends on what
kind of implementation you maintain? As the EH designer/author, the
adjective I was trying for is "minimal".

TLS isn't rigorously defined in terms of a state machine, but it's
natural to speak of it in terms of one. However what we mean by that can
vary quite a bit. For example, the OpenSSL codebase seems to use two
states for every handshake message but the basic state machine 
representation is much simpler:

                 Basic TLS handshake, server side

    without EH                       EH level one
    ----------                       ------------
                               |
      |                        |        |
      v                        |        v
    state 'start'              |     state 'start'
      |                        |        |
      |                        |        |
event: received ClientHello   | event: received ClientHello
      |                        |        |
      |                        |        |
      v                        |        v
state 'handshake_a':          | state 'handshake_a':
  on entry: send ServerHello,  |  on entry: send ServerHello1a,
     Cert*, ServerKeyExch*,    |     [ChangeCipherSpec], SH1b,
     CertReq*, ServerHelloDone |     Cert*, ServerKeyExch*,
      |                        |     CertReq*, ServerHelloDone
      |                        |        |
      |                        |        |
event: received Cert*,        |  event: received
    ClientKeyExch,             |     [ChangeCipherSpec],
    CertVerify*,               |     Cert*, ClientKeyExch,
    [ChangeCipherSpec],        |     CertVerify*,
    Finished                   |     Finished
      |                        |        |
      |                        |        |
      v                        |        v
state 'handshake_complete':   | state 'handshake_complete':
  on entry:                    |  on entry:
    send [ChangeCipherSpec],   |    send [ChangeCipherSpec],
    Finished                   |    Finished
                               |

So for EH level one there's not really a change in the number of states 
or transitions in the 'TLS state machine' per se. EH level two 
introduces one new transition to one new state. This why EH support is 
split into two implementation levels.

 > There is no need to change the version number: there is no chance one
 > party won't know what is going on.

As Nico pointed out, the TLS version number is for when you need 
rollback protection. It has to be incremented when changing the 
hash/MAC/PRF algorithm because that's the thing which authenticates the 
handshake negotiation itself. But most other changes should be 
negotiable via extensions, as long as they do not negatively affect the 
process of generating and validating the Finished messages.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 05 May 2012 09:17:28 -0700

> That is a feature. With this draft, the server has to perform two asymmetric operations anyway: one for the key exchange (most likely D-H), and then it still has to do another one as proof of posse…

I don't see that as a feature.  Telling people that they can't do things
the way they've been doing them for a decade doesn't go over well.

Why throw away all of the TLS_RSA_xxx, TLS_PSK_xxx, TLS_SRP_xxx, (and
TLS_KRB5_xxx ?) cipher suites in one shot?  Wrapping them in anon DH
adds forward secrecy (attackers can't see the RSA encrypted secret, for
example).  People get to do things more or less the same as they've
always done, but get more security "for free".

> The PRF is not expensive. It's the operation used to generate the seed for the PRF that is expensive. It should be noted that this is a disadvantage of this proposal.

In cases where the second CCS would produce the same key material as the
first CCS (i.e. the master secret hasn't changed), an implementation can
optimize away the second one.

Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 May 2012 09:25:09 -0700

> the way they've been doing them for a decade doesn't go over well.

It is hard to tell if you are criticizing the idea of encrypting the handshake early, or the first draft of the document. If the former, I would disagree: this seems like very useful work. If the latter, a different way to say this is "I really hope there will be a way to also authenticate with current forms of TLS authentication if the parties want that".

A second, optional authentication seems like a reasonable thing to add to the -01 draft, at least to me.

--Paul Hoffman

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 05 May 2012 10:04:46 -0700

> It is hard to tell if you are criticizing the idea of encrypting the handshake early, or the first draft of the document. If the former, I would disagree: this seems like very useful work. If the l…

I'm sorry if I wasn't clear.  I was responding to the idea that allowing
this new extension to be incompatible with TLS_RSA_xxx cipher suites was
a feature.

I am in favor of encrypting the handshake early, but not if the new
mechanism is incompatible with the way things are done today (many sites
prefer TLS_RSA_xxx cipher suites).

Adoption will be much faster if server operators don't need to do anything
but upgrade their software.  Many have inherited working configurations
and are not expert in cipher suites and key exchange algorithms.

> A second, optional authentication seems like a reasonable thing to add to the -01 draft, at least to me.

That can be achieved by adding a second CCS just prior to Finished, allowing
the use of all existing cipher suites defined today.  When a DH-based cipher
suite is negotiated, an implementation can treat the 2nd CCS as a NOOP as an
optimization.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 05 May 2012 20:10:17 +0200

> prefer TLS_RSA_xxx cipher suites).

I don't see that as a valid reason to introduce extra complexity to the

current draft. Are there any real benefits from the usage of
TLS_RSA_xxx? In any case the sites that prefer the TLS_RSA_xxx would
still prefer it even after this draft. Only sites that want to provide
encrypted parts in the handshake will use the new draft with the
required ciphersuites.

> and are not expert in cipher suites and key exchange algorithms.

Why this isn't possible with the current draft?

regards,
Nikos

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 May 2012 11:22:00 -0700

> this new extension to be incompatible with TLS_RSA_xxx cipher suites was

That might have been Yoav being glib (but he might have actually have meant it...).

> and are not expert in cipher suites and key exchange algorithms.

I don't read the draft as possibly being implemented with only upgrading software. The server would need to also have a (EC)DH certificate to authenticate the first CCS.

> suite is negotiated, an implementation can treat the 2nd CCS as a NOOP as an

I would propose that, if the WG likes this work and goes with the option of a second authentication, that it either be signaled in the original extension, or that it always be mandatory but in the case where it is not needed, it is done with small packets saying to the effect of "I'm not authenticating a second time" and "yes, I know".

--Paul Hoffman

---

From: Marsh Ray <[email-masked]>
Date: Sat, 05 May 2012 14:04:42 -0500

> the way they've been doing them for a decade doesn't go over well.

I don't want to tell anybody they can't do things their way. It's a 
totally optional extension, nobody has to use it.

That said, I think it would be great if eveybody did use it. :-)

Like Yoav said:
On 05/04/2012 04:13 PM, Yoav Nir wrote:
 > I think this moves TLS to be more like IKE, where encryption of the
 > IKE protocol precedes everything else (authentication, configuration,
 > and IPsec setup)

SSH2 is another example of a protocol that starts off encryption with DH 
as early as possible.

The goal here is to update TLS to look a bit more like those newer 
protocols. In fact, we can do it even better than SSH2. Imagine, before 
even one full round-trip has completed, few hundred bytes
into the server's initial reply, we are already forward-secretly 
encrypted from that point on!

All it takes to make this possible is to include some (EC)DH parameters 
in the Client Hello. The rest the spec is just working out the details. :-)

> always done, but get more security "for free".

I'm not opposed to it in principle, but I chose not to support RSA key 
exchange mainly because it looked like it would increase the complexity 
significantly. The fact that it wouldn't have the forward secrecy 
property didn't seem to help either.

With RSA key exchange the client sends the premaster secret to server. 
In order to do this, he has to know the server's public key. So if the 
server sends the cert in the clear we end up with basically the same 
full handshake we have now.

If the client were to somehow already know the server's public key 
perhaps he could send the RSA-encrypted premaster secret in the Client 
Hello. But server public keys change regularly, so this info could not 
be cached very long. If the extension only worked in cases where the 
client had had recent contact with the same server, well, we could just 
use session resumption for those cases now.

If what you're suggesting is starting out EH with a DHE key exchange and 
then switching to the RSA-negotiated key at the usual point before the 
Finished messages, maybe that could work. It brings a few challenges:

* The client and server now need to negotiate and use *two* cipher 
suites instead of just one.

* They would need separate random_datas for the (EC)DHE and the RSA key 
exchanges

* We lose the ability of the client to verify the ServerHello2a 
dh_params using a simple memcmp() with the *signed* structure in the 
ServerKeyExchange, and vice versa for the ClientKeyExchange. This may 
not be such a big deal today because some implementations don't even 
check that until the Finished message anyway. I think it may reduce some 
of the extra integrity protection we might get by encrypting and MACing 
more of the handshake, but I didn't claim any of that as a selling point 
of the proposal because I wasn't prepared to quantify it.

* I didn't want to shock everyone so thoroughly with the complexity of 
the proposal that the WG wouldn't want to take it up. We all have a 
fuzzy line beyond which we say "hmm, that really ought to be implemented 
as a different protocol". For me, that line is currently somewhere 
between EH level two and Snap Start.

So, again, I'm open to modifications but at the end of the day, (EC)DHE 
is just a much more elegant key exchange method when the goal is to 
begin encrypting after a minimum of message passing.

>> The PRF is not expensive. It's the operation used to generate the seed
>> for the PRF that is expensive. It should be noted that this is a
>> disadvantage of this proposal.

Yes, the benefits of (EC)DHE do not come for free (unless perhaps you 
use certs with fixed-DH parameters). But if you are already using some 
form of DH key exchange, you *do* get Encrypted Handshake level one for 
free.

> optimize away the second one.

We can't let the same key material be used for multiple plaintexts. That 
would be bad.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Sat, 05 May 2012 14:12:13 -0500

On 05/05/2012 01:22 PM, Paul Hoffman wrote:
>
> I don't read the draft as possibly being implemented with only
> upgrading software. The server would need to also have a (EC)DH
> certificate to authenticate the first CCS.

Hmm, does it?

I tried to make it so any endpoint that could do ephemeral key exchange 
today could begin encrypting handshakes, just possibly needing a little 
config change.

- Marsh

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 5 May 2012 22:49:56 +0200

> > IKE protocol precedes everything else (authentication, configuration,

TLS has its own key exchange, but if we really want to move TLS to be more
like IKE, so I think it could be wise to study the case of integrating the
IKE key exchange into the TLS handshake.

A couple of years ago, there was a proposal to integrate ISAKMP into the
handshake:
I. Hajjeh et al, "ISAKMP handshake for SSL/TLS"
Digital Object Identifier: 10.1109/GLOCOM.2003.1258484

Best regards,
Badra

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 5 May 2012 14:34:45 -0700

>  - you can not use RSA key exchange anymore; how about PSK or SRP?

Note that you can still use RSA with dhe_rsa. So, you are not doing RSA key exchange, but you are still doing RSA authentication. I propose that less than 1% of web site operators would care about the difference.

>    machine could prefer different bulk encryption and MAC algorithms

How many web hosting providers let their individual customers make those choices? Isn't this also in the 1%ish range?

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 May 2012 17:00:23 -0500

>>   - you can not use RSA key exchange anymore; how about PSK or SRP?

I think it'd be easy enough to allow those in addition to the initial
DH key exchange.

> The PRF is not expensive. It's the operation used to generate the seed for the PRF that is expensive. It should be noted that this is a disadvantage of this proposal.

But note that re-negotiation (which is needed to gain some privacy for
the client) also involves two key exchanges and PRFs.  This approach
does not do worse, and it reduces round-trips.  So that's a win.

Now, DH with server signature of its parameters is more expensive than
RSA key transport, certainly, but I think we're at the point where we
can accept that extra cost (particularly with ECDH in the picture).

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 06 May 2012 09:38:03 +0200

> can accept that extra cost (particularly with ECDH in the picture).

Moreover there are several optimizations in plain DH that could be done
for performance. The fact for example that TLS doesn't send the subgroup
size, harms DH's performance. I was experimenting [0] with a server that
operates on a subgroup and got a performance boost. If both the server
and the client were aware of the subgroup the performance may have been
comparable to ECDH.

regards,
Nikos

[0].
http://nikmav.blogspot.com/2011/12/generating-diffie-hellman-parameters.html

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 May 2012 10:50:58 +0300

I was mostly being glib, but I think RSA keying has just one advantage: that a single private key operation gets you both server authentication and key exchange. Once the EH extension gets in the way, you are doing two operations anyway, so they might as well be anonymous (EC)DH and a digital signature, regardless of the algorithm.

And there's no need to have an (EC)DH certificate to authenticate the first CCS. The authentication comes later with a digital signature.

Yoav 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: 05 May 2012 21:22
To: Michael D'Errico
Cc: [email-masked]
Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt

On May 5, 2012, at 10:04 AM, Michael D'Errico wrote:

>>> I don't see that as a feature.  Telling people that they can't do 
>>> things the way they've been doing them for a decade doesn't go over well.
> I'm sorry if I wasn't clear.  I was responding to the idea that 
> allowing this new extension to be incompatible with TLS_RSA_xxx cipher 
> suites was a feature.

> mechanism is incompatible with the way things are done today (many 
> sites prefer TLS_RSA_xxx cipher suites).
> 
> Adoption will be much faster if server operators don't need to do 
> anything but upgrade their software.  Many have inherited working 
> configurations and are not expert in cipher suites and key exchange algorithms.

> That can be achieved by adding a second CCS just prior to Finished, 
> allowing the use of all existing cipher suites defined today.  When a 
> DH-based cipher suite is negotiated, an implementation can treat the 
> 2nd CCS as a NOOP as an optimization.

--Paul Hoffman

---

From: Mohamad Badra <[email-masked]>
Date: Sun, 6 May 2012 11:56:20 +0400

On Sun, May 6, 2012 at 11:50 AM, Yoav Nir <[email-masked]> wrote:

>
> And there's no need to have an (EC)DH certificate to authenticate the
> first CCS. The authentication comes later with a digital signature.
>

How then you will be protected against active attacks?
Best regards
Badra

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 May 2012 11:04:56 +0300

On May 6, 2012, at 10:56 AM, Mohamad Badra wrote:

On Sun, May 6, 2012 at 11:50 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

It depends on what the signature covers. If it covers the unencrypted clientHello and serverHello, and is signed with the private key associated with the server certificate, what can an active attacker do?  They can complete the handshake with the client, and a separate handshake with the server, but they can either copy the client's DH public key, in which case they won't have the master secret, or they can generate their own, in which case the signature won't verify.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 06 May 2012 10:36:36 +0200

On 05/04/2012 06:21 PM, Marsh Ray wrote:
> draft a reading and serious consideration to taking it up as a work item

Hello,
 I like the draft and I support having it as a WG item. Some questions:

* client_required, client_requested,
Instead of those two fields, why not just sending a single list with all
acceptable levels?

* conditional_extensions,
I think this is complicated. Why not assume that the extensions present
in the hello are valid?

* cipher_suites in ClientDHParamSet
Wouldn't it be beneficial to define all the ciphersuites this extension
can be used with? As far as I understand most/all of the SRP,
(EC)DHE-PSK, and (EC)DHE are valid.

> * I believe it may help a little with the issue Nikos Mavrogiannopoulos and I were discussing, where an attacker is able to trick the client into interpreting the server's signed key exchange parameters as the wrong type of structure.

In an unexpected way though. The signature on the server again only
covers the parameters but not the keyExchangeAlgorithm, but this time
the parameters are sent by the client and only repeated by the server.
(I don't know whether this is sufficient to prevent all such attacks,
but this isn't the goal of this draft anyways)

regards,
Nikos

---

From: Mohamad Badra <[email-masked]>
Date: Sun, 6 May 2012 12:49:36 +0400

On Sun, May 6, 2012 at 12:04 PM, Yoav Nir <[email-masked]> wrote:

> It depends on what the signature covers. If it covers the unencrypted
> clientHello and serverHello, and is signed with the private key associated
> with the server certificate, what can an active attacker do?  They can
> complete the handshake with the client, and a separate handshake with the
> server, but they can either copy the client's DH public key, in which case
> they won't have the master secret, or they can generate their own, in which
> case the signature won't verify.
>

I was reading "no need to have an (EC)DH certificate to authenticate the
first CCS". In that case, active attacks are possible.

Best regards
Badra

---

From: Marsh Ray <[email-masked]>
Date: Sun, 06 May 2012 11:00:05 -0500

On 05/06/2012 03:36 AM, Nikos Mavrogiannopoulos wrote:
>
> * client_required, client_requested, Instead of those two fields,
> why not just sending a single list with all acceptable levels?

That could work too. There are just three levels including "zero". I
don't know how likely it is that there will ever be more. A list would
likely take as much or more space and as a variable length field it
would be slightly more complex to process securely.

My sense is that having two fields, requested and required, gives the
negotiation a little more flexibility, like hard and soft limits for a
resource quota system. By setting the required level higher than
requested, it also gives a neat way to query the server for what he can
support.

I can envision a website admin thinking "I don't want to enable this new
feature for everyone by default because I heard it costs an extra 5 ms
CPU". But there are clients who would like to indicate that they "really
do need at least level one" because they expect to use a client cert or
the browser is in some type of enhanced privacy configuration.

It could be beneficial for the server to have a way to indicate
requested and required as well. For example, a high-security
latency-tolerant server may wish to require level two at all times. Such
an application may be better off requiring renegotiation though.

Alternatively, there may be a consensus that this is all just
unnecessary complexity. One early reviewer has expressed a preference to
have the client simply request a level and if he didn't get what he
requires the handshake fails.

> * conditional_extensions, I think this is complicated. Why not
> assume that the extensions present in the hello are valid?

The idea behind this is that there may be extensions which the client is
willing to send the CH extension in the clear when level one may be
negotiated, but strongly prefers that the server not send his SH
extension reply in the clear.

I don't know which (if any) existing extensions might benefit from this.
NP(N) may be such an extension, if it worked one of the ways being
discussed. That was where the NP Client Hello extension is basically
empty to signal support for the feature but the Server Hello extension
contains a list of protocols the server supports for the client to
select from in a subsequent message. If this list is sent in the clear
and contains only one protocol (and who isn't going to set up a
websockets or spdy.example.com?) then that's nearly equivalent to
sending the next protocol in the clear.

Again there may be a consensus that this is all just unnecessary
complexity. It may be that no currently defined extensions would benefit
from this and extensions defined in the future could simply require EH
level one.

> * cipher_suites in ClientDHParamSet Wouldn't it be beneficial to
> define all the ciphersuites this extension can be used with? As far
> as I understand most/all of the SRP, (EC)DHE-PSK, and (EC)DHE are
> valid.

I don't really know, others in [TLS] would have a better sense
of this than I do.

I thought it might be beneficial to define it without regard to any
specific cipher suites so new cipher suites could be defined in the
future without needing to update the EH. But the format of the DH params
were defined as part of TLS. So the 'select's for DH param format in the
definition of the EH extension and the ServerHello2a represent a
combination of the corresponding structure from RFC 5246 (TLS 1.2) and
RFC 4492 (ECC).

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Sun, 06 May 2012 11:53:53 -0500

> first CCS". In that case, active attacks are possible.

Right, EH does not resist active attacks. It is possible for an active 
attacker to learn what the client or server would have sent in the 
handshake. But any such attack causes the handshake to fail in all the 
scenarios where TLS currently provides integrity protection, i.e., 
everywhere except for anon-anon DH connections or a pwned trusted root CA.

It may be possible to get better guarantees for messages that are sent 
after the Client Key Exchange or Server Key exchange (such as RFC 4680 
'Supplemental Data' messages). But some TLS implementations reportedly 
do not check these signatures until the Finished messages and many 
non-browser clients do not even look at the name on the server cert 
until the handshake is complete.

This means that the protections offered by EH to client certs is 
limited. Applications requiring serious security for the content of 
client certs should still use renegotiation.

If the client has an interest in protecting the client cert he MUST NOT 
transmit the client cert until he's fully authenticated the server. 
Generally this requires renegotiation, but many servers will not allow 
the client to initiate that.

Consequently, general purpose clients like web browsers can be tricked 
into transmitting the client cert to an active attacker. The only thing 
that can fix that is to change the client behavior to be more strict. In 
order to avoid breaking existing applications, clients can only become 
more strict if they are given positive indication to do so. Most forms 
of negotiation can be falsified by an active attacker at the point the 
client cert must be sent.

So AFAICT the only way that a client cert used by web browsers can be 
protected from active attackers is to encode a positive indication in 
the client cert itself to require such protection. This must take the 
form of an authorization mechanism defining which server identities are 
allowed to receive the plaintext client cert and how they may be 
authenticated.

If such a mechanism is ever put in place, EH may be able to optimize out 
the renegotiation. But we would have to approach that very carefully 
because the signature on the Server Key Exchange does not provide the 
same security properties as that of the server Finished.

- Marsh

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 May 2012 18:05:12 +0100

Probably too complex to be worth it, but I guess a client
could send encrypted forms of values like NPN, client-cert,
using a symmetric key that the client generates but only
exposes to the server after the handshake has succeeded. If
a generic approach for early encryption is worth it, it
could be (though I doubt it) that only allowing deciphering
of those values after the h/s succeeds might also be worth
it.

That'd force the mitm to complete the h/s to get at the
private info and would increase accountability maybe and
also remove some obvious unauthenticated mitm possibilities.

S

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 May 2012 21:00:36 +0300

> client cert must be sent.

I must be missing something. Here's your modified handshake, and I'm assuming (EC)DHE_RSA or (EC)DHE_ECDSA

      Client                                               Server

      ClientHello (with EH ext)    -------->
                                                    ServerHello2a
                                               [ChangeCipherSpec]
                                                    ServerHello2b
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      [ChangeCipherSpec]
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      Finished                     -------->
                                   <--------             Finished
      Application Data             <------->     Application Data

An active attacker can either move DH public keys between the client and server, but in that case it won't have the shared secret, and so - no certificate
So the active attacker has to perform a different DH with each side. But that means that the ServerKeyExchange from the server signs a different public key from the one the client saw, so that's not valid, and the attacker can't generate one that is appropriate, because it doesn't have the private key for the server certificate.

So regardless of whether ECDSA or RSA keys are used, how can the attacker get the certificate?

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Sun, 06 May 2012 13:09:43 -0500

> So regardless of whether ECDSA or RSA keys are used, how can the attacker get the certificate?

He simply tells the client that the server doesn't support EH at all.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 May 2012 21:28:08 +0300

> He simply tells the client that the server doesn't support EH at all.

Right. I see. That's what I was missing.

> allowed to receive the plaintext client cert and how they may be 

Wouldn't it be better to encode this indication in the server certificate? That way, the question of whether to send the certificate in the clear to a non-supporting server can be left to the client's local policy.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Sun, 06 May 2012 13:59:38 -0500

On 05/06/2012 01:28 PM, Yoav Nir wrote:
>> So AFAICT the only way that a client cert used by web browsers can
>> be protected from active attackers is to encode a positive
>> indication in the client cert itself to require such protection.
>> This must take the form of an authorization mechanism defining
>> which server identities are allowed to receive the plaintext client
>> cert and how they may be authenticated.
>
> Wouldn't it be better to encode this indication in the server
> certificate? That way, the question of whether to send the
> certificate in the clear to a non-supporting server can be left to
> the client's local policy.

With RSA key exchange, the client has no way to verify that the party on 
the end of the wire is in possession of the private key to the cert 
until he receives and validates the server's Finished message. Even with 
DHE key exchange where the parameters are signed in the Server Key 
Exchange message it could be simply a relay of a signature the MitM 
collected from the legitimate server after presenting the same Client 
Hello random.

Without EH, the client sends the client cert in the clear.

With EH the client cert would be sent encrypted, but except for the 
randoms and the server dh params every other part of the handshake is 
subject to modification by the attacker. So it's a tricky proposition to 
prove that there is no possible way for an active attacker to construct 
a set of messages that, when combined with the server's signed SKE 
message, would allow the attacker to decrypt the client cert.

I suspect that's not possible to prove in the general case, because new 
cipher suites could be defined in the future that allow the attacker to 
give new meanings to whatever the server signs.

Current applications expect the client to send his client cert upon 
request, so it really seems like the client will need some permission 
before he can refuse such a request. I don't think we can realistically 
expect browser users to configure their browser into strict-client-cert 
mode before going online. So the only way (I can think of) for a useful 
policy to get implemented is for the client cert itself to contain a 
critical attribute to authorize a server's request for it.

- Marsh

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 07 May 2012 09:16:31 +0200

Hi,

which currently defined extensions are worth to be "protected".
the draft says:

    Before the Server Name
    Indication (SNI) extension [RFC 6066], it was not possible to serve
    multiple HTTPS sites from a single IP address, so the specific site
    to which the user was connecting was effectively already known.

Does that mean that the authors considers the servername as
information that should be protected? what happens when IPV6
comes in? Is it unlikely to have one IPV6 adress per server?

If the SNI is not send in the initial clienthello, what is a client
supposed to do when the serverhello does not indicate
support for the new method?

           If no EH extension is present, the negotiated EH level is zero
           server continues the TLS connection as usual.  The remainder
           of this section does not apply.

how does the client "continue" as usual since it has not send all
desired extensions?

regards
/PS

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 7 May 2012 09:47:38 +0200

> requested, it also gives a neat way to query the server for what he can

There is a similar issue in TLS protocol negotiation, where the client
only indicates his highest version. Now if an implementation indicates
1.2 it is not clear whether it supports 1.1, and to what version the
server would fallback. Even with the three levels supported (zero,
one, two), if a client advertises required zero, requested two, should
the server assume that he supports one? What if the client only
supports level two and zero?

> extension reply in the clear.

I'd suggest that this should be extension specific. I.e. each
extension should specify the behavior on each level. Otherwise it
looks like each implementation would assume its own defaults and there
will be no consistent privacy level for each extension. For the
currently defined extensions that specify no default behaviors I think
this document should define it. This would avoid both the complexity,
and the implementation specific privacy-level (and a user would know
that in level two the extensions XYZ and ZZY are protected while XXY
isn't etc).

> future without needing to update the EH.

Future ciphersuites should mention how they should be used with EH.
The ones defined past this point cannot do that, and this document
should make things clear, or everything should be left on implementors
(e.g. I can think a way SRP can be used with this draft, but someone
on another implementation may have a different idea).

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Mon, 07 May 2012 13:33:54 -0500

> to which the user was connecting was effectively already known.

The EH extension provides a defined method by which a client and server 
MAY transfer certain handshake data under encryption. EH level one does 
not encrypt Client Hello extensions, EH level two will probably be able 
to encrypt all but a few.

SNI is tricky since in theory a server could use it to route to 
different vhosts, each with different allowed cipher suites. I don't 
know how likely such a setup will be in reality.

If SNI needs to be sent under encryption to such a site, here are some 
ideas:

* Servers requiring SNI may support EH level two, but they still require 
the SNI to be sent on the first ClientHello.

* Servers requiring SNI don't allow arbitrary per-vhost configuration of 
the ciphersuites.

* Servers requiring SNI with a client requiring EH level two begin the 
handshake using the settings of the default vhost. After the SNI arrives 
on ClientHello2, if the negotiated cipher suite is supported by the 
target vhost then the handshake completes as a normal EH level two. If 
the negotiated cipher suite is not supported by the target vhost, an 
anon-anon DH handshake is completed and the server initiates a 
renegotiation with the target vhost's allowed cipher suites.

* The server selects the ciphersuite from the union of all the sets of 
ciphersuites of all the vhosts. A problem with this 
least-common-denominator approach is it effectively allows one one vhost 
to downgrade the ciphersuites of all the others.

> information that should be protected?

My personal opinion is that SNI looks like it may contain interesting 
information and it would be beneficial for EH to be able to provide 
encryption for clients that wanted it. It's just a matter of 
consistentizing the configuration, this should be a solvable problem.

I suspect in practice, today, eavesdroppers near the client who are in 
position to see the SNI are also in position to see the client's DNS 
query. Eavesdroppers near the server will get a pretty good idea of the 
list of sites hosted from the non-EH level two clients. If the hostnames 
and certs presented by different vhosts are of different lengths then 
the TLS handshake record sizes may distinguish them.

> what happens when IPV6

I don't know. I think many folks have given up trying to predict when 
IPv6 will show up on the server side.

> support for the new method?

Like support for any other optional feature, the client has a decision 
to make. We may never get to a point where client can require EH level 
two on first contact with a random server.

But for those do who want to handshake that way, we can give them a well 
defined way to do it.

>>   of this section does not apply.

Looks like I have a missing fragment here. I'll probably do an editing 
pass soon since the -00 text is pretty rough in some places.

> how does the client "continue" as usual since it has not send all

The client and server each decide based on their configuration how the 
lack of certain extensions affects the completion of the handshake and 
what happens at the application layer afterwards, just like they do now.

It's pretty rare for handshakes between well maintained devices to fail 
for such a reason. Nevertheless, web browsers tend to have fallback 
logic to handle it.

Story: I read in an SSL survey that something like 99.99% of servers 
support TLS 1.0. So I unchecked the "Allow SSL 3.0" box in Firefox. 
Well, a few days later I came across a server without support for TLS. 
It was my little home Wifi router configuration interface.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 07 May 2012 13:50:14 -0500

On 05/07/2012 02:47 AM, Nikos Mavrogiannopoulos wrote:
>
> Even with the three levels supported (zero,

I think that EH level one is such a clear subset of level two that it 
doesn't make sense to implement level two but not level one.

Would we ever define more levels such that implementation support for 
them could sensibly be non-contiguous? It doesn't seem too likely to me, 
but should the need arise we'd probably have a new extension ID anyway.

Agree.

I'd be happy to add those sections to the ID, but I will need to rely on 
the subject matter experts here in the WG for many of the specifics.

- Marsh

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 08 May 2012 10:04:10 +0200

On 05/07/2012 08:33 PM, Marsh Ray wrote:
> The EH extension provides a defined method by which a client and server MAY transfer certain 
> handshake data under encryption. EH level one does not encrypt Client Hello extensions, EH level 
> two will probably be able to encrypt all but a few.
>
> SNI is tricky since in theory a server could use it to route to different vhosts, each with 
> different allowed cipher suites. I don't know how likely such a setup will be in reality.
>
> If SNI needs to be sent under encryption to such a site, here are some ideas:
>
> * Servers requiring SNI may support EH level two, but they still require the SNI to be sent on the 
> first ClientHello.
>
> * Servers requiring SNI don't allow arbitrary per-vhost configuration of the ciphersuites.
>
> * Servers requiring SNI with a client requiring EH level two begin the handshake using the 
> settings of the default vhost. After the SNI arrives on ClientHello2, if the negotiated cipher 
> suite is supported by the target vhost then the handshake completes as a normal EH level two. If 
> the negotiated cipher suite is not supported by the target vhost, an anon-anon DH handshake is 
> completed and the server initiates a renegotiation with the target vhost's allowed cipher suites.
>
> * The server selects the ciphersuite from the union of all the sets of ciphersuites of all the 
> vhosts. A problem with this least-common-denominator approach is it effectively allows one one 
> vhost to downgrade the ciphersuites of all the others.
>
> My personal opinion is that SNI looks like it may contain interesting information and it would be 
> beneficial for EH to be able to provide encryption for clients that wanted it. It's just a matter 
> of consistentizing the configuration, this should be a solvable problem.
>
> I suspect in practice, today, eavesdroppers near the client who are in position to see the SNI are 
> also in position to see the client's DNS query. Eavesdroppers near the server will get a pretty 
> good idea of the list of sites hosted from the non-EH level two clients. If the hostnames and 
> certs presented by different vhosts are of different lengths then the TLS handshake record sizes 
> may distinguish them.
>
>> what happens when IPV6
> I don't know. I think many folks have given up trying to predict when IPv6 will show up on the 
> server side.
ok, I was assuming the sentence about SNI on page 3 be an indication about SNI being
something worth to be protected. with ipv6 you most likely have one address per hostname
again.

> Like support for any other optional feature, the client has a decision to make. We may never get 
> to a point where client can require EH level two on first contact with a random server.

>
> But for those do who want to handshake that way, we can give them a well defined way to do it.
so this would most likely require some management at the client level to select the feature.

> Looks like I have a missing fragment here. I'll probably do an editing pass soon since the -00 
> text is pretty rough in some places.
if there is nothing for the second client hello, the client can
continue.  if the client wanted level 2, you need to abandon
and restart with a new clienthello

srp has a similar situation when srp suite are proposed without
a client name.

> The client and server each decide based on their configuration how the lack of certain extensions 
> affects the completion of the handshake and what happens at the application layer afterwards, just 
> like they do now.
>
> It's pretty rare for handshakes between well maintained devices to fail for such a reason. 
> Nevertheless, web browsers tend to have fallback logic to handle it.
   ...

>
> Story: I read in an SSL survey that something like 99.99% of servers support TLS 1.0. So I 
> unchecked the "Allow SSL 3.0" box in Firefox. Well, a few days later I came across a server 
> without support for TLS. It was my little home Wifi router configuration interface.
>
nice.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 May 2012 12:15:43 +0300

> something worth to be protected. with ipv6 you most likely have one address per hostname

I highly doubt that. The reason for colocating web servers is to lower the administrative cost, not because of the scarcity of IPv4 addresses. Giving a single interface multiple IP addresses and tying each to a service makes for a higher administrative cost, and the mechanisms for multiple services, both in HTTP and in TLS are already there. I think it would be much simpler to keep things the way they are.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 May 2012 10:23:25 -0500

On 05/08/2012 04:15 AM, Yoav Nir wrote:
>> ok, I was assuming the sentence about SNI on page 3 be an
>> indication about SNI being something worth to be protected. with
>> ipv6 you most likely have one address per hostname again.
>
> I highly doubt that. The reason for colocating web servers is to
> lower the administrative cost,

Or to share the costs of high-bandwith connectivity with the rest of the 
datacenter.

> not because of the scarcity of IPv4 addresses.

We have a weird situation today where the scarcity of IPv4 addresses has 
provided a source of revenue for some lucky ISPs. So they are 
disincentivized to promote IPv6. Even still, a server can't abandon IPv4 
until all its clients can talk to it over IPv6. I think it will be a 
long time before that happens for most public servers.

> Giving a single interface multiple IP addresses and tying
> each to a service makes for a higher administrative cost, and the
> mechanisms for multiple services, both in HTTP and in TLS are already
> there. I think it would be much simpler to keep things the way they
> are.

I agree that EH should not attempt to change SNI.

Even if we had an infinite address space, SNI with EH level two could, 
under the right circumstances, offer some advantage of encrypting even 
the name of the server being connected to. Ideally you'd have a large 
number of unrelated sites served via the same set of SSL terminators, 
e.g., Akamai.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 May 2012 23:21:42 +0300

> long time before that happens for most public servers.

Yes, the home user who uses web, email and some P2P software can go all IPv6 (or at least no external IPv4 address) much easier than content providers.

Google and www.ietf.org will have an IPv4 address long after the vast majority of consumers don't have it anymore.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 08 May 2012 22:57:35 +0200

> doesn't make sense to implement level two but not level one.

In that case, it should be clearly forbidden by this draft not to
implement one if two is implemented, and pretty much mention that
only the options 0, 1, 2 will ever be available. Otherwise if 10
years from now sbd adds 3 which is independent of 1,2 it may make
sense to support 3 but not 2.

I'd prefer however if the draft is flexible to allow future updates.

> but should the need arise we'd probably have a new extension ID anyway.

I don't know. The future is hard to predict, so it may be better to be
safe than sorry :)

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2012 00:23:44 +0200 (MEST)

Yoav Nir wrote:
> Yes, the home user who uses web, email and some P2P software can go
> all IPv6 (or at least no external IPv4 address) much easier than
> content providers.

Except that lots of home equipment does not support IPv6 at all
(the majority of the installed base of home DSL&WLAN routers,
  Nintendo WII, Nintendo DS, My 2-year-old Sony LED 40" Flatscreen,
  my WD HomeNAS, my DVB-s receiver ...) to name a few.

And with IPv6 one would loose the added privacy protection of
dynamic IPv4 addresses.

At the same time, getting IPv6 provides ZERO benefit.

  http://www.theregister.co.uk/2012/05/08/ipv6_coming_next_month/

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 10 May 2012 16:27:18 -0600

> Except that lots of home equipment does not support IPv6 at all

<flame-bait>
So? We could say the same (or worse) about TLS 1.1/1.2 :P
</flame-bait>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 May 2012 08:29:44 +0200

> So? We could say the same (or worse) about TLS 1.1/1.2 :P
I mentioned ipv6 yo ask whether SNI would
benefit from being used in an encrypted client hello
in level 2  or not.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 16 May 2012 08:49:31 -0400

This has quieted down a little bit after running around in different
directions, but I wanted to bring back up the question of adopting it.
 By my informal count there were a few supports - I'd like to add to
those and say I think this is worth adopting and developing.  I think
it's clear it'll require some careful accounting to track issues, but
I'm willing to assist Marsh with that.

-tom

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 May 2012 10:03:24 -0500

> I'm willing to assist Marsh with that.

Tom, thanks for your offer to coordinate that will be helpful.

Update:

I've been accumulating edits for a -01 that I expect will be out in a 
few days. If anyone else has things they'd like to see in the -01, this 
would be a good time to send them.

Nikos has been helping develop the details on the various key exchange 
methods. Some of the non-RFC5246 key exchange methods look like they fit 
more elegantly than others. :-)

A few points on which I'd love to take the temperature of the WG:

1.  Having an unlimited variety of ways for the client to propose the 
(EC)DHE be conducted seems likely to unnecessarily increase the size of 
the Client Hello and make client fingerprinting easier. For classic DH, 
would it make sense to suggest using a more limited set of p and g 
parameters, like the standard groups used by IPsec and SSH?

2. This extension seems to be a natural fit for ECC in a few different 
ways. Would it make sense to standardize on ECC and/or a particular curve?

3. I have consistently resisted handshake changes that involve adding a 
second round of CCS absent renegotiation, mainly because it's 
unnecessary complexity in the primary use case of (EC)DHE. But some of 
the other key exchange methods can be done more efficiently than 
renegotiating if we allow another round of CCS in the usual place before 
the Finished messages of the first handshake. How much of a disruptive 
change is this really, or am I just feeling too conservative?

Thanks,

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 May 2012 11:35:52 -0400

On Wed, May 16, 2012 at 11:03 AM, Marsh Ray <[email-masked]> wrote:
> (EC)DHE be conducted seems likely to unnecessarily increase the size of the
> Client Hello and make client fingerprinting easier. For classic DH, would it
> make sense to suggest using a more limited set of p and g parameters, like
> the standard groups used by IPsec and SSH?
>
> 2. This extension seems to be a natural fit for ECC in a few different ways.
> Would it make sense to standardize on ECC and/or a particular curve?

I think having ids for some well known groups makes a lot of sense.
Most TLS EDH in the world is done in a few, standard groups anyway.

For ECC, I believe that P-256 is the best option. Because it's Suite
B, it has wide implementation (as opposed to curves like P-224) and
it's the fastest of the Suite B curves. I really don't like its prime
structure as an implementer, but I believe it's other benefits
outweigh that.

> second round of CCS absent renegotiation, mainly because it's unnecessary
> complexity in the primary use case of (EC)DHE. But some of the other key
> exchange methods can be done more efficiently than renegotiating if we allow
> another round of CCS in the usual place before the Finished messages of the
> first handshake. How much of a disruptive change is this really, or am I
> just feeling too conservative?

I think that would be a fairly significant change. Which key exchanges
benefit from more flows like that?

Cheers

AGL

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 May 2012 09:34:56 -0700

On May 16, 2012, at 8:03 AM, Marsh Ray wrote:

> 1.  Having an unlimited variety of ways for the client to propose the (EC)DHE be conducted seems likely to unnecessarily increase the size of the Client Hello and make client fingerprinting easier. For classic DH, would it make sense to suggest using a more limited set of p and g parameters, like the standard groups used by IPsec and SSH?

The Client Hello being a few bytes bigger is not worth considering. Image the downside of having to create a new extension when a new ECDHE is proposed, as it surely will be. As for client fingerprinting, a client should probably only be offering one or two proposals.

> 2. This extension seems to be a natural fit for ECC in a few different ways. Would it make sense to standardize on ECC and/or a particular curve?

If you mean "should this spec have a mandatory to implement ECC profile", that would be great. I agree with Adam: P256 seems like a popular choice.

> 3. I have consistently resisted handshake changes that involve adding a second round of CCS absent renegotiation, mainly because it's unnecessary complexity in the primary use case of (EC)DHE. But some of the other key exchange methods can be done more efficiently than renegotiating if we allow another round of CCS in the usual place before the Finished messages of the first handshake. How much of a disruptive change is this really, or am I just feeling too conservative?

Other folks have pressed for this, so maybe have it in your next draft with a bit of discussion about taking it out later when this is a WG work item.

--Paul Hoffman

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 May 2012 19:26:58 +0200

> Most TLS EDH in the world is done in a few, standard groups anyway.

Indeed.

> structure as an implementer, but I believe it's other benefits

Having SECP-256 in a small list of curves is a good thing after the
advantages you mention, but having it as a single curve would create
a monoculture. That way in case of a catastrophic flaw, it would require
a protocol change (as opposed to a configuration change)
to avoid this curve.

> benefit from more flows like that?

DHE-PSK and ECDHE-PSK. Unlike the "normal" DHE-RSA that sign the
exchange parameters, those ciphersuites include the PSK into the
negotiated premaster secret. That way the premaster secret needs
to be updated after the PSK is known to both parties. (similary
for SRP that performs a new key exchange after the initial DH)

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 10:54:46 -0700

> a reading and serious consideration to taking it up as a work item:

I have reviewed this document and I don't believe that
the WG should adopt it.

I understand the general desire to minimize the number
of things exposed to a passive attacker but when one
actually looks at the list of things that are disclosed,
it's not particularly impressive. The draft says:

                                                      The server's
   identity, session resumption data, and session ticket data are all
   sent in the clear.  When client cert authentication is used, the
   client's identity and the server's list of trusted root CAs is also
   exposed.  Typically the leaked information is sufficient to allow a
   passive observer to fingerprint the TLS client and server
   applications in use, and even to learn something about the connection
   history of the user.

Unfortunately, much of this data is trivial to observe anyway.
In particular:

- The session ID and session ticket should both be random and/or
  encrypted, so what you really learn is that the client and
  server have communicated recently. But you can observe
  whether resumption is used merely from message order and size.
- The server's trusted root list isn't any kind of secret
  and can be trivially elicited just by asking the server
  a single time.
- You can fingerprint the server actively cheaply, so hiding that
  information from a passive attacker doesn't buy you much.
- Fingerprinting the client is often possible if it does
  any HTTP at all (just based on the client's HTTP headers).
  Moreover, the cipher suite list is one of the most
  powerful fingerprinting tools and that lives in
  ClientHello, not ClientHello2.

This leaves us with SNI and the client's certificate. SNI can often be
inferred passively by examining message length and it's well-known
that you can infer what sites people are visiting by traffic analysis
[0], so the degree of protection that is provided here is distinctly
limited.

Finally, we have the client certificate. The idea of protecting the
client certificate has been discussed many times over the years, most
recently in Paris. However, given the extremely low use of client
certificates, the rather significant level of changes to the
protocol to protect it, and the fact that all the proposed changes
are vulnerable to active attack, these proposals seem of limited
value.

In Paris, the WG was specifically asked the question of whether they
wanted to protect client certificates from passive attack (but have
them be vulnerable to active attack) and the answer was clear.
(http://www.ietf.org/proceedings/83/minutes/minutes-83-tls.txt):

    Joe: 2 questions: do you think its important to protect client
    cert against passive attack (e.g. defeatable by active)? Or do you
    think it's not worth pursuing and we should move on? No one hums
    on first, lots of hums on 2nd.

I don't see that this draft has a significantly different cost/benefit
tradeoff. It's true that it protects more than the certificate,
but (a) it still doesn't protect against active attack (b) most
of the data it protects can be inferred by other means and (c)
it does a lot more damage to the TLS state machine in the process.

-Ekr

[0] Chen, et al., "Side-Channel Leaks in Web Applications: a Realisty
Today, a Challenge Tomorrow", Oakland 2007.
Sen et al, "Statistical Identification of Encrypted Web Browsing Traffic",
Oakland 2002.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 May 2012 22:01:46 +0200

>   information from a passive attacker doesn't buy you much.

You cannot always fingerprint the server cheaply. What if the server
presents different identities depending on where you connect from? In
that case passive protection of the server credentials is an advantage.

> This leaves us with SNI and the client's certificate. SNI can often be

Also SRP and PSK usernames.

> are vulnerable to active attack, these proposals seem of limited

Interestingly this proposal isn't vulnerable to active attacks. The
client only sends its certificate, encrypted, after the server has
presented a signed serverkeyexchange. If the client verifies that
serverkeyexchange on reception he can be sure that the only the
legitimate server knows the key to read it.

In any case certificates, and usernames typically contain e-mails and
that makes them a prime target for eavesdropping. Thus even protection
against passive attacks is an interesting property for several
use-cases.

> it does a lot more damage to the TLS state machine in the process.

I believe (a) isn't true. (c) is an unfortunate side-effect and by
checking the EH protocol closely, several things could be simplified
if TLS had privacy features designed in from the beginning.

My opinion is that a redesign of TLS is needed to account for privacy
as this draft does. I see this draft being as the first steps for TLS
1.3 which should include privacy protection by default. Dismissing it
without suggesting an alternative plan seems like a step backwards for
TLS and privacy.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 May 2012 15:30:46 -0500

Eric,

In addition to Nikos' point I'd like to point out that it's not just
the things this approach would protect today, but also the future
extensions that it will also protect.  More importantly, I think
starting cryptographic protection as early as possible is a good
design goal in general.

It is worth asking whether these changes are worthwhile, of course.
Even if desirable, if they were to be too difficult to implement
and/or deploy then desirability might not be sufficient.  But I think
it's too soon to tell that this is too difficult to implement.  I
don't think Marsh's proposal does quite as much violence to
implementations as you seem to think, and in any case, that's a
one-time hit.  The bigger concern for me is whether refactoring can be
done so as to keep the complexity of implementation withing acceptable
limits, but I think that must be possible anyways.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 13:52:12 -0700

> that case passive protection of the server credentials is an advantage.

Why? If I'm on-path, I can just generate the same address as the client.

> Also SRP and PSK usernames.

Neither of these are in wide use, especially on the Web (more on this shortly).
Moreover, it's not clear that these can be bootstrapped into this framework.
For instance, SRP requires a salt that is stored with the username, so
you must reveal the username to the server prior to doing the key
exchange, which means you somehow need a preexisting DH exchange
secured by the server.

> legitimate server knows the key to read it.

The attacker simulates being a server which doesn't support this
extension, and unless clients hard fail (which is problematic),
then the client will send the certificate in the clear.

> (c) is an unfortunate side-effect and by

We already have a perfectly good alternative plan: do simple TLS handshake
to establish a secure channel and then renegotiate inside that channel
with any fancy extensions you want. Note that this would have the advantage
that it works with basically any TLS enhancement without any special
per-enhancement engineering. The only real downsides of this
are performance in the forms of latency and computational cost. As
has been widely observed the computational cost of TLS relative
to CPU power is shrinking fast, so this primarily leaves latency, which is
principally an issue in the Web environment and even that for a relatively
small number of servers.

Since basically none of the features that you're claiming leak a lot of
information (client certs, SRP, PSK) have significant deployment on the Web,
this seems like classic premature optimization.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 13:53:44 -0700

> limits, but I think that must be possible anyways.

But as is already clear, this design doesn't actually give you protection
for all additional features: rather it interacts badly with a number of
existing features. There's no reason to think that other future
features wouldn't have similar problems.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 May 2012 15:58:49 -0500

> features wouldn't have similar problems.

Of course there is! Future features (e.g. NP(N), Websockets, SPDY) can 
not only be designed to work smoothly with Encrypted Handshake, but may 
even benefit from and require it.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 14:03:15 -0700

On Wed, May 16, 2012 at 1:58 PM, Marsh Ray <[email-masked]> wrote:
> Of course there is! Future features (e.g. NP(N), Websockets, SPDY) can not
> only be designed to work smoothly with Encrypted Handshake, but may even
> benefit from and require it.

I don't know why you raise Websockets here, since it's at an entirely
different layer.

More generally, yes, *some* features would obviously integrate smoothly,
but it's really a stretch to talk about these as future features since
they were designed prior to this proposal and indeed you list them
as part of the design motivation in your original message. The test
is how difficult it will be to make actual future features work.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 May 2012 23:13:32 +0200

> then the client will send the certificate in the clear.

This is a denial of service attack that even TLS is vulnerable to.
A client that doesn't want its identity to be expose it will
disconnect. This is the same as saying the TLS is insecure because an
attacker can say to the client please use SSL 2.0. It's up to the
client to enforce the desired security level.

> with any fancy extensions you want. 

It is not identical. This plan _is_ vulnerable to mitm attack. I can
perfectly intercept an anonymous handshake and watch the certificate
sent in the second handshake. In the EH protocol this isn't possible
(unless of course you assume that the client will voluntarily transmit
its identity in the clear).

> this seems like classic premature optimization.

Note that this proposal started because a popular browser (chrome) did
try to add that functionality restricted to the NPN extension. As
far as I know major TLS libraries already implement that extension,
so there is need for hiding parts of the handshake.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 14:20:25 -0700

> client to enforce the desired security level.

That's not the security guarantee that TLS generally attempts to
provide, namely the highest common parameters, not the weakest,
which is why there is such extensive protection against
downgrade attacks. Yes, I realize that it's difficult to provide
that protection in this case, which is precisely why in Paris
we decided that it wasn't worth moving forward with encrypted
client certificate extensions.

> sent in the second handshake.

Not anonymous. Server authenticated.

> In the EH protocol this isn't possible

Which clients will of course do (or not, but in either case the security
guarantees of renegotiation for the client cert are the same in this
case).

> so there is need for hiding parts of the handshake.

There has been extensive debate about whether NPN actually needs
to be encrypted. Given that NPN currently more or less always means
SPDY, I think the best thing you could say about that is that the
jury is still out (and more likely that it's unnecessary).

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 May 2012 17:08:41 -0500

> Why? If I'm on-path, I can just generate the same address as the client.

Yes, EH does not attempt to protect against active attacks.

Up until recently I believed that unauthenticated encryption was bad 
because it was did not resist active attacks and could even lend a false 
sense of security. On any given network segment, an active attack is 
usually just as practical as a passive one.

But then I considered the sheer volume of traffic flying around the net 
in aggregate. Some unknowable huge amount of it is subject to 
eavesdropping. But what we do know that only a very very small amount of 
it will be non-consentually MitM'd.

So now I believe that converting a passive attack to a 
possibly-detectable active attack can be very valuable.

> Neither of these are in wide use, especially on the Web (more on this shortly).

Chicken, meet egg.

Note: I am specifically not calling anyone a chicken. :-)

> exchange, which means you somehow need a preexisting DH exchange

There are options for SRP, but I agree with Eric that SRP shouldn't be 
the defining use case for the evolution of TLS.

>>> recently in Paris.

Have these all been merely solutions chasing nonexistent problems?
Or is there possibly some demand for something better?

>>> However, given the extremely low use of client
>>> certificates,

Chicken-egg, to some degree.

>>> the rather significant level of changes to the

Yes, EH involves some cost and it does not solve everything.

> then the client will send the certificate in the clear.

I agree with Eric, an active attack will remain possible for all 
maximally interoperable TLS client applications.

Again, EH does not attempt to protect against active attacks.

> with any fancy extensions you want.

Everyone knows how much I value secure renegotiation.

But it seems that our users are speaking with their feet and saying that 
the status quo is not, in fact, perfectly good.

> Note that this would have the advantage

I suppose web servers run by admins who value low latency are still a 
minority in absolute terms. But some of these sites are pretty darn 
successful (famously Amazon) and others of them are pushing TLS protocol 
innovations into half the world's web browsers (Google, Mozilla).

> this seems like classic premature optimization.

I think you're slicing it too thin.

The TLS handshake leaks a lot of metadata. So much so that people are 
reluctant to trust it for user credentials, standardize new upper-level 
features like NP(N), and even the talented developers behind Tor feel 
the need to migrate away due to TLS's susceptibility to selective DoS.

Many of us have had the experience of looking at Wireshark and 
diagnosing connectivity issues. We shouldn't be able to do this!
Useful as this may be, one of the properties of an ideal security 
protocol is that it will be annoyingly difficult to analyze passively.

This means taking stuff that's now sent in the clear and moving it under 
encryption. EH is an attempt to achieve that goal with minimal disruption.

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 May 2012 17:17:56 -0500

On Wed, May 16, 2012 at 3:52 PM, Eric Rescorla <[email-masked]> wrote:
> with any fancy extensions you want. [...]

The record type is visible to the attacker, so re-negotiation can be
observed to be happening.  I hear Tor used to use re-negotiation but
had to stop because of this, it being trivial to observe
re-negotiation happening, and re-negotiation being such a rare thing
that blocking it is trivial.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 May 2012 15:41:03 -0700

> I have reviewed this document and I don't believe that
[...]

Just in case it wasn't clear, this (and the other messages I have sent
to this thread) are sent in my individual capacity. When I intend to
be acting as chair, I clearly identify it in my messages.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 May 2012 18:57:38 -0500

On 05/16/2012 04:03 PM, Eric Rescorla wrote:
> On Wed, May 16, 2012 at 1:58 PM, Marsh Ray<[email-masked]>
> wrote:
>> Of course there is! Future features (e.g. NP(N), Websockets, SPDY)
>> can not only be designed to work smoothly with Encrypted Handshake,
>> but may even benefit from and require it.
>
> More generally, yes, *some* features would obviously integrate
> smoothly, but it's really a stretch to talk about these as future
> features since they were designed prior to this proposal and indeed
> you list them as part of the design motivation in your original
> message. The test is how difficult it will be to make actual future
> features work.

Agree.

> I don't know why you raise Websockets here, since it's at an
> entirely different layer.

Partly I just associate them because they seemed to be proposed sort of 
in the same batch as SPDY and NP(N).

But here's another take, an example of *the general kind of thing* that 
we might be able to consider after EH as a first step. This is not a 
central point of EH or a rigorous proposal I'm making. Perhaps someone
has thought of something similar before.

If you fundamentally don't like the idea of extending TLS merely to 
accomodate app data protocols (there are certainly good reasons to feel 
that way), please stop reading now. :-)

 From Wikipedia https://en.wikipedia.org/wiki/WebSockets :
> WebSocket is a web technology providing for bi-directional,
> full-duplex communications channels...

(OK we knew that already)

> In addition, the communications are done over the regular TCP port
> number 80, which is of benefit for those environments which block
> non-standard Internet connections using a firewall.

!!! This is an affront to data security everywhere!
And we have no one to blame but [TLS] (and the careless vendors, server 
admins, and the clueless users, but blaming them is useless).

It is absurd to recommend that anyone should use TCP port number 80 to 
avoid selective DoS when port 443 SHOULD provide a much better solution. 
A selective DoS is only possible when the confidentiality is 
ineffective. Of course anyone could run websockets on port 443, but 
common usage (as embodied in Wikipedia) recommends port 80 without a 
second thought.

This is what Websockets looks like:

> GET /mychat HTTP/1.1
> Host: server.example.com
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
> Sec-WebSocket-Protocol: chat
> Sec-WebSocket-Version: 13
> Origin: http://example.com
>
> HTTP/1.1 101 Switching Protocols
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
> Sec-WebSocket-Protocol: chat

Almost none of that is useful at the HTTP layer, why would you even need 
to involve a web server? Passing the necessary info in a TLS extension 
could eliminate the server! Split off the websocket flow in the SSL 
offload device or other lightweight SSL stack. This could save a round 
trip or more of latency.

But only *if* there were a way to pass the necessary information under 
encryption. We would also have to deal with the issue of active attacks, 
but still, we're talking about people happy with port 80 right now.

Hmm, what would that look like..

> GET /mychat HTTP/1.1

Only '/mychat' conveys meaning. Send it later and drop the rest.

> Host: server.example.com
Already in SNI.

> Upgrade: websocket
>Sec-WebSocket-Protocol: chat
>Sec-WebSocket-Version: 13

Sounds like a job for NP(N), already specified.

> Connection: Upgrade
It's now redundant. Drop it.

> Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

Derive this and cryptographically bind it properly from your favorite 
flavor of strong mutual auth. E.g., SRP, PSK, existing TLS session support.

> Origin: http://example.com

Send in the extension.

> HTTP/1.1 101 Switching Protocols
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
> Sec-WebSocket-Protocol: chat
All this is now redundant. Drop it.

So, we could combine EH, SNI, and NP(N) with a hypothetical Websocket 
TLS extension which might look something like:

struct WebsocketClientToServerData {
     string url;
     string origin;
};

struct WebsocketServerToClientData {
     // empty, just indicates acceptance
};

effect:

You no longer need a webserver to do websockets.

* There is no longer an ad-hoc authenticated and unbound channel 
tunneled in HTTP, tunneled in TLS.

* People happy with websockets on port 80 today could obtain the full 
security of TLS for their application data with only one additional 
round trip on the first connection and no additional round trips on 
subsequent (session resuming) connections.

* Client apps in "environments which block non-standard Internet 
connections using a firewall" could restore connectivity using EH level 
two, unless their firewall is willing to break port 443 handshakes at 
random looking for a reason to DoS the client IP on future port 443 
requests.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 May 2012 19:30:01 -0500

On 05/16/2012 04:13 PM, Nikos Mavrogiannopoulos wrote:
> try to add that functionality restricted to the NPN extension.

For the record and before this meme gets out of hand, that was just one 
factor. I tried to list the motivating forces in that first email 
introducing the draft. At about the same time I saw several desired use 
cases running up against TLS limitations that seemed to have a common 
solution, or at least direction of improvement. I probably would not 
have gone to the trouble of writing a detailed I-D for any single one of 
them. :-)

> As

That, and I don't think the current incarnation of NP(N) is the best 
possible or even the best practical one. For example, NP(N) defines a 
new handshake message type (likely angering a few MitM in the process) 
but it doesn't seem to improve the handshake for anything except NP(N). 
The server-proposes-N/client-picks-1 negotiation is (IMHO) the right one 
for NP(N) and perhaps other extensions too, but it's not overly elegant 
with the current handshake.

Of course the best NP(N) is the one that's properly RFC'd, by 
definition. Let's make it happen.

- Marsh

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 17 May 2012 02:48:45 +0200

On Wed, May 16, 2012 at 11:20 PM, Eric Rescorla <[email-masked]> wrote:

> downgrade attacks.

Although TLS attempts to negotiate the highest it explicitly mentions
that it may not negotiate the strongest shared ciphersuite [0].  I
think however that this disagreement is a matter of definition rather
than actual disagreement. You assume a user (1) that would like to
have his identity hidden, but doesn't really care. I assume a user (2)
that doesn't want his identity to be revealed.

Indeed this draft does not protect the former user, although it
protects the latter under active attacks. In that sense I think it is
similar to the TLS promise. It'll try for the best, but cannot
guarantee it so one must be prepared to negotiate the weakest
supported ciphersuite.

[0] "Note that higher layers should not be overly reliant on TLS always
   negotiating the strongest possible connection between two peers..."

> guarantees of renegotiation for the client cert are the same in this

Indeed it  is a practical solution, but at the cost of an extra
handshake (2x round-trips + 2 times DH).

> to be encrypted.

I also think that for current uses NPN should have been defined as a
typical TLS extension, but there is not a definite answer for
everyone. For some uses it may need to be encrypted, and the same is
true for every other TLS extension.

The reason I support this draft is that I see use-cases where
encrypting parts of the handshake makes sense. What I am afraid is the
complexity this currently requires due to the required protocol
changes. For that I think it would be an advantage of having this work
done within the WG rather than having to accept a de facto standard
later.

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Wed, 16 May 2012 23:36:40 -0500

On 05/16/2012 12:54 PM, Eric Rescorla wrote:
> it's not particularly impressive.

I feel that way too. But how much of that is simply that we're just 
conditioned by long experience to accept it?

>    whether resumption is used merely from message order and size.

Straight up: If I fixed all of that too in this or follow-on I-Ds, would 
you then support it?

> - The server's trusted root list isn't any kind of secret

But isn't this primarily an effect of current protocol limitations? It 
doesn't seem like a design principle we should seek to maintain.

>    and can be trivially elicited just by asking the server

Not if the server only requests a client under renegotiation triggered 
by a specific HTTP request unknown to the attacker. Such a server could 
even serve different lists according to the request.

>    information from a passive attacker doesn't buy you much.

Yes, but the active fingerprinting requires the eavesdropper to pay a 
certain price: He must divulge that he has in fact eavesdropped on some 
connection to that server and is now following-up with an active 
fingerprint. This could be very interesting information to the defender 
under the right circumstances.

Sure, there is a background level of port 443 scans occurring over the 
entire IPv4 address space. But consider a TLS server on a nonstandard 
port, or in a sparse section of IPv6 address space.

Active probing is not always so cheap to the attacker.

>    any HTTP at all (just based on the client's HTTP headers).

Yes, if it does HTTP via a place that the eavesdropper can monitor and 
associate. For example, an eavesdropper near a server with HSTS is 
likely to see very little HTTP coming from the latest client apps.

>    ClientHello, not ClientHello2.

In practice, the more common sets are sent identically by millions of 
clients.

> Sen et al, "Statistical Identification of Encrypted Web Browsing Traffic",

Those are great papers. They prove that encryption alone does not solve 
everything. But the existence of even very effective traffic analysis 
does not seem a good argument for sending plaintext when it could be 
sent encrypted instead.

- Marsh