Subject: [TLS] Potential New Handshake Flows for TLS 1.3

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Nov 2013 13:08:55 -0800

I've just submitted a document on potentially new reduced RT/more
private protocol flows for TLS 1.3. It's fairly handwavy ATM but I wanted
to err on the side of getting some of the ideas out for discussion
so we could figure out which avenues we want to pursue. This draft
borrows (steals) liberally from a bunch of prior work too numerous
to name here.

I'll be going over some of this material at today's meeting, but seeing
as how this just got delivered, I'll make sure you don't need to have
read the draft to follow along.

Sorry about the late delivery....

-Ekr

Filename:        draft-rescorla-tls13-new-flows
Revision:        00
Title:           New Handshake Flows for TLS 1.3
Creation date:   2013-11-05
Group:           Individual Submission
Number of pages: 21
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-tls13-new-flows-00.txt
Status:
http://datatracker.ietf.org/doc/draft-rescorla-tls13-new-flows
Htmlized:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00

Abstract:
   This document sketches some potential new handshake flows for TLS
   1.3.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 05 Nov 2013 15:58:17 -0800

> borrows (steals) liberally from a bunch of prior work too numerous

In the handshake of Figure 7, an active attacker can obtain the 3rd
ClientHello since the ServerKeyExchange is not signed.

I would like to see some DH parameters standardized to simplify
things (no need for the client to validate) and to remove the need
to transmit them.

Since the idea of server state is being thrown around, perhaps the
server can simply send a key to the client (after Finished) to be
used to make the next handshake private.  New PreSharedKeyRequest
and response messages (not necessarily Handshake messages) could be
defined for this if necessary.

Mike

---

From: Watson Ladd <[email-masked]>
Date: Tue, 5 Nov 2013 19:38:32 -0800

> read the draft to follow along.
Is there a technical reason we can't have the client send an ECDH key,
server respond with ECDH key and signature of client
and server keys, and then use that key for a transmission in the response.
This has one round trip latency, and is secure under standard assumptions.

The second issue is that historically the handshaking has been a
plague upon the security: We should chop out handshakes,
not add them, to simplify the analysis. This assumes we keep the
bloated message+extension format here.
> _______________________________________________
> 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: Nico Williams <[email-masked]>
Date: Tue, 5 Nov 2013 22:01:25 -0600

> This has one round trip latency, and is secure under standard assumptions.

Sure, but this is optimistic; there has to be a fallback if the server
doesn't like the client's proposed curve/group/whatever.  The client
could send multiple DH keys, but...  Also, might as well always use
key agreement (which isn't quite the same as PFS, since what should be
ephemeral keys might get reused).

So, at least for initial [and therefore non-resumption] connections
there must be at least an option for a 1.5 round trip handshake.  Note
that a 1.5 round-trip handshake does not add a round-trip's worth of
latency to when the client can start sending application records -- it
only adds local crypto's worth of latency.

> bloated message+extension format here.

The key to this is negotiating key agreement, DH groups/curves, KDFs,
hash functions, server authentication methods, and symmetric (and
authenticated) ciphers+modes separately, in as compact a way as
possible (variable-length bitmasks, with a registry of bit numbers).
With optimal initial assignments (optimal for assignment-time
conditions anyways, or near future) this might yield really, really
small hellos.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Tue, 5 Nov 2013 20:16:29 -0800

> only adds local crypto's worth of latency.
Solution: the client says what it will accept and offer, and the
server goes first. Actually,
I don't like that idea because we have to have the server present an
authentication of the handshake.
The fact that we need this is utterly horrid: there should be so few
options that
the chances of success are very good.

Seriously, why don't we resolve to do it right this time? Yes,
backwards compatibility matters, but at this point
it will break because RC4 is dead, and so is AtE without seriously clever fixes.
> conditions anyways, or near future) this might yield really, really
Will anyone not using AES_GCM, AES_SHA256, or the ECDHE variants
thereof, please explain to the list
what your reason is?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 6 Nov 2013 10:28:53 +0100

> borrows (steals) liberally from a bunch of prior work too numerous

I don't quite like that all the abbreviated handshakes make use of
cached information. Does this really scale? I mean do we expect each
client to keep a database of every host it connected? I'm afraid that
if cache information are required then these handshakes will be used
to connect to popular sites, and everyone else will be using the old
non-cached-data depended handshake. This adds complexity as everyone
would have to implement the old and the new handshakes.

In fact the same effect with cached information is present with
session tickets, which is even lighter and available today.

Maybe instead of cached information, move the choice of the parameters
to the client (and maybe give the server the option to discard them
and use others at the cost of an additional RTT and a
ClientKeyExchange).

The handshakes in Figure 6 and 7 look quite promising (although I
don't get the idea of AlmostFinished). What is its purpose?

regards,
Nikos

---

From: Bill Frantz <[email-masked]>
Date: Wed, 6 Nov 2013 06:02:20 -0800

On 11/6/13 at 1:28 AM, [email-masked] (Nikos Mavrogiannopoulos) wrote:

>client to keep a database of every host it connected?

If we are only concerned with HTTP, and all the cacheing is at 
the client side, things should scale quite well. Assuming the 
cached data is 10K bytes, you would be able to hold 200-300 
sites for the storage cost of one digital picture -- well within 
the capacity of even a smart phone.

The cache would only contain the sites of interest to the user. 
My cache would not have an entry for Facebook or Twitter, which 
I never use, but would have entries for www.caves.org and www.qrz.com.

If caching is required on the server side, it would be an 
additional burden for Periwinkle. www.pwpconsult.com is a simple 
web site that displays the same information to every visitor. 
The only per visitor information may be a log entry. (I question 
if HTTPS is really appropriate for web sites like Periwinkle. 
Defeating traffic analysis is a separate problem.)

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Nov 2013 09:24:03 -0500

> If caching is required on the server side,

I would expect that to be problematic for any big site that is spread around multiple locations, or even just multiple racks in a datacenter, or blades in a rack. Unless you can pin the client to a specific IP address which doesn't move.

	/r$
--  
Principal Security Engineer
Akamai Technology
Cambridge, MA