Subject: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

From: Bodo Moeller <[email-masked]>
Date: Wed, 2 Jun 2010 10:15:33 +0200

A downside of deploying TLS is the latency penalty due to the TLS  
handshake: when starting a new session, HTTPS needs two additional  
round-trip times compared with unencrypted HTTP.  This document shows  
that it's easy to do better than that, just by changing the client's  
protocol implementation -- no change to server code is required to  
speed up full handshakes.

(Similarly, a server-only change can speed up abbreviated handshakes  
for application protocols in which, unlike HTTP, the server sends data  
first.)

An example implementation for OpenSSL is available as  
handshake_cutthrough.patch at http://bazaar.launchpad.net/~nagendra/openssl-patches/trunk/files 
.

Bodo

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Transport Layer Security (TLS) False Start
> 	Author(s)       : A. Langley, et al.
> 	Filename        : draft-bmoeller-tls-falsestart-00.txt
> 	Pages           : 11
> 	Date            : 2010-06-02
>
> This document specifies an optional behavior of TLS implementations,
> dubbed False Start.  It affects only protocol timing, not on-the-wire
> protocol data, and can be implemented unilaterally.  The TLS False
> Start feature leads to a latency reduction of one round trip for
> certain handshakes.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-falsestart-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <ftp://ftp.ietf.org/internet-drafts/draft-bmoeller-tls-falsestart-00.txt 
> >

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Jun 2010 17:19:31 +0200 (MEST)

> > 	Filename        : draft-bmoeller-tls-falsestart-00.txt

I think that security considerations should spend some words on
the authentication performed by the client.  The last words of
section 1 of rfc-5246:

   The decisions on [...] how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

In an abstract fashion, an app client ought to always perform the "server
endpoint identification" before sending any application data to the
server.  But in the rfc-5246 architecture, this app decision is based
on a fully verified handshake.

TLS False Start change the architecture, in that it requires the
app client to perform an "optimistic server endpoint identification"
based on unverified information from an incomplete TLS handshake.

In those application architectures, where the client app authentication
is _not_ performed through a callback, but instead in a synchronous
fashion after completion of the TLS handshake, TLS False Start will
likely not be possible.

And I think that a client should _not_ try TLS False Start with
a Server that lacks TLS Renegotiation Extension support (rfc5746).

-Martin

---

From: Adam Langley <[email-masked]>
Date: Wed, 2 Jun 2010 11:47:47 -0400

> fashion after completion of the TLS handshake, TLS False Start will

Certainly the design of some TLS code might make False Start awkward
or impossible. In those cases, it need not be supported.

> a Server that lacks TLS Renegotiation Extension support (rfc5746).

I'm afraid that I don't see where the considerations of talking to a
server without the renegotiation extension, and using False Start,
interact. I think they are independent.

If an attacker were conducting a renegotiation attack, and altered the
handshake in any way (say, to remove a renegotiation extension), then
the client's Finished message would be rejected by the server.

AGL

---

From: Marsh Ray <[email-masked]>
Date: Wed, 02 Jun 2010 13:55:31 -0500

My first reactions are:

1. This proposal scares me. Wasn't the Finished message added in
response to vulnerabilities in SSLv2? Doesn't this sort of, umm, undo
that for initial data from the client? It bears repeating that in TLS
usage for a secure web application that first transmission from the
client to the server would be expected to contain the session cookie,
perhaps even the full plaintext credentials for a form-based login. The
entire security model of web apps is based on the inability of the
attacker to decrypt this.

2. Couldn't a similar optimization be achieved without protocol changes
by simply implementing session resumption more robustly? Session
resumption also takes things like cert chain validation and revocation
checking out of the critical path of the handshake but this proposal
still depends on it.

3. This is an interesting idea and you guys have clearly thought this
through. I am suspicious, I can't find an exploitable bug in it (yet).

> or impossible. In those cases, it need not be supported.

Last I checked this included IE, Chrome, and everyone else that used
Schannel on MS Windows.

The vast majority of tutorial/example code availiable on the web has the
application check the name on the certificate (those rules are protocol
specific after all) only after the TLS stack has returned with a
successful handshake. So this would require API and client application
changes and could not be enabled by default.

> the client's Finished message would be rejected by the server.

But the server's Finished message will not have been validated by the
client, so the security analysis for the RI fix must start over with the
expectation that the client cannot trust the presence or absence of an
RI extension. If the client didn't ever have to trust it, then why did
we send it in the server-to-client direction anyway?

AFAICT, RI is the only TLS extension that's presence is mandatory for
security purposes. But other extensions affect the handshake somehow or
else they wouldn't be sent, and how much of TLS really doesn't affect
security somehow? E.g. SNI? Seems like everything must be re-analyzed
from scratch if we are to be safe sending confidential data before fully
validating the server.

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Wed, 2 Jun 2010 15:11:19 -0400

> attacker to decrypt this.

Agreed that the first request from the client to the server is very
sensitive. If someone finds a way to decrypt this because of False
Start then that's a fatal flaw.

> checking out of the critical path of the handshake but this proposal

Can you expand on 'robustly'? We cannot store session information on
disk which limits its applicability. Although we'll always try
resumption when we can.

It's true that cert chain revocation is still in play here. OCSP
multi-stapling will hopefully address that.

> Last I checked this included IE, Chrome, and everyone else that used

Chrome no longer uses SChannel on Windows in the latest development
channel builds (and False Start is enabled in these development
releases).

> from scratch if we are to be safe sending confidential data before fully

I agree that careful thought is required for this change. At this
point several people have considered it and not found any issues save
for the ones enumerated in the draft.

Cheers

AGL

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Jun 2010 22:29:48 +0200 (MEST)

Marsh Ray wrote:
> that for initial data from the client?

Personally, I'm not scared.  We've been allowing a vaguely similar
feature in GSS-API architecture for at least a decade "PROT_READY".

Personally, I've been suggesting such an optimization several times
(last time during the discussion of TLS extension RI, when I
violently opposed to adding the finished messages into the PRF
instead of into the handshake messages hashes.)

There are some subtle differences to GSS-API's PROT_READY, however,
based on the different architecture of TLS.

Essentially, this optimization obsoletes the verification of
the Server Finished message by the client, and that is an aspect
that needs to be carefully reviewed.  I remember just how badly
things failed because of a complete lack of review of the original
SSL renegotiation design -- its impossible that the renego flaw would
have gone unnoticed in an adequate review of that part of the
SSLv3&TLS protocol.

In GSS-API, the authentication of the server by the client (app)
is uniformly performed by the "target_name" parameter supplied
to the initial gss_init_sec_context() call, i.e. the the gssapi
mechanism is required to ensure that the message protection keys
will be(come) known only to the intended communication peer.

In TLS, the situation when and how the client (app) performs the
"server endpoint identification" is pretty much completely undefined.

In this fashion, GSS-API ensures that the client's app data is only
"protected" before successful security context establishment when
the message protection keys can only be recovered by the intended
communication peer.  Doing otherwise would be a real security problem.

TLS False Start can not leave the "server endpoint identification"
performed by the client app as undefined as it is.  The guidance
on "compatible cipher suites and key exchange algorithms" seems
not to be a sufficiently complete solution to the lack-of-authentication
prior to the verification of the ServerFinished handshake message
in the Full Handshake to which TLS False Start is added on top.
An explicit constraint for an client-app optimistic "server endpoint
identification" prior to sending any protected app data _will_ IMHO
have to be part of the solution.

> checking out of the critical path of the handshake but this proposal

I'm actually wondering how much thought has been put into
TLS session cache management.  My impression from looking at
specific cache management design flaws in a particularly large
installed base is: little to none.

Even the original OpenSSL session cache (entry lifetime) management
IMHO uses a poor design choice.  You can not easily adjust your session
cache lifetime dynamically with that design in order to optimize between
your server load and session cache size (memory footprint), because it
stores when the session is to be expired, based upon the configuration
when the cache entry is added to the cache, instead of the creation
timestamp for the session.

The two parameters to steer session cache size an growth in the
long term is session cache size and lifetime of session cache entries.
In addition, in order to cope with high load situations, you want
to have a capability to prune your cache based on LRU and a certain
percentage of entries long before session cache entries expire from age.

And one of the results of the poor design of some TLS session cache
management and the impact of that on load-based performance benchmarks
seems to be one of the reasons why TLS is used for such a small part
of the Web as it is today.  The other probably is the administrative
overhead of getting, installing and regularly renewing Server certs
plus help desk issues and associated cost of all combined.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 03 Jun 2010 10:31:36 -0700

I think the current name doesn't describe the feature very well.  SMTP and
HTTP call it "pipelining" so perhaps you could use that name instead.  My
software should tolerate TLS pipelining if a peer were to use it, but I
don't feel comfortable adding it as a feature.

Mike

Bodo Moeller wrote:
> protocol implementation -- no change to server code is required to speed 
> up full handshakes.
> 
> (Similarly, a server-only change can speed up abbreviated handshakes for 
> application protocols in which, unlike HTTP, the server sends data first.)
> 
> handshake_cutthrough.patch at 
> http://bazaar.launchpad.net/~nagendra/openssl-patches/trunk/files.
> 
> Bodo
> 
> 
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> <ftp://ftp.ietf.org/internet-drafts/draft-bmoeller-tls-falsestart-00.txt>

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 4 Jun 2010 11:47:09 +0200

On Jun 3, 2010, at 7:31 PM, Michael D'Errico wrote:

> HTTP call it "pipelining" so perhaps you could use that name instead.

Michael,

thanks for the comment.

Yes, "TLS False Start" is an application of the pipelining principle.   
However, I think the name "pipelining" isn't sufficiently specific,  
and thus misleading: even without "False Start", you can have  
pipelining with TLS (for application data).

Furthermore, there are important non-obvious security considerations,  
and if we just called this "pipelining", implementors might mistakenly  
believe they know what's going on because they know pipelining from  
other protocols.  We do want them to read the security considerations  
first.  I hope that the name "False Start" becomes clear once you've  
got the idea behind it: a party starts before it has received a "go"  
signal.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 15:28:24 +0200 (MEST)

> don't feel comfortable adding it as a feature.

You probably mean that your server side implementation should tolerate
it if some TLS False Start enabled component were to use it?

I assume that a lot of server implementations will tolerate such clients.
After all, waiting for and verifying the server's ChangeCipherSpec&Finished
handshake messages is a duty of the client and in the interest of the client.

There is _no_ obligation on the server to perform any kind of heuristics
on initial(!!) TLS handshakes on a connection whether there already is
incoming application data TLS record available from the communication
channel at the time when the server is about to send off his
ChangeCipherSpec&Finished handshake messages.  For renegotiation handshakes
there is an explicit requirement in the specs 22465/4346/5246 that
interleaving of handshake messages and data records must be tolerated.

When TCP is used as the transport, I assume that sending the
ChangeCipherSpec&Finished handshake message in a TCP segment seperate
from the successor TLS application data record ("TCP Push") likely makes
TLS False Start clients interoperate with any TLS server implementation.

TLS implementations that work similar to OpenSSL, reading each record
individually (header first, then the rest of the body) probably don't
care at all about network-level segments.

-Martin

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 4 Jun 2010 09:27:51 -0500

> from the successor TLS application data record ("TCP Push") likely makes
TLS
> False Start clients interoperate with any TLS server implementation.

My prototype server implementation does not work with this mechanism. First,
my implementation always reads as much input as is available, up to its
buffer size, so any data after the client's Finished message will be read
into the buffer. Then, it will abort the connection if it sees anything
after the Finished message--mostly because it actually reuses the receive
buffer as its send buffer. Or, in other words, my implementation is
optimized for the fact that the initial TLS handshake is half-duplex. I
would be surprised if I was the only person to implement such an
optimization. 

Trying to separate the packets will do any good, as the server operating
system is just going to coalesce them anyway before the application can
process them. And, sending separate packets would be quite a pessimization
for the GRPS clients that would benefit the most from this extension.

> individually (header first, then the rest of the body) probably don't care
at all
> about network-level segments.

I think most implementations work similarly to OpenSSL in that respect,
especially if they support renegotiation; in renegotiation you can have
application data interleaved with the handshake messages so optimizations
like the ones described above do not work. Most implementations seem to use
the same logic for initial and renegotiated handshakes whenever possible.

Regards,
Brian

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 17:37:29 +0200 (MEST)

> would be surprised if I was the only person to implement such an

What exactly do you mean by "read as much input as is available".

> for the GRPS clients that would benefit the most from this extension.

The underlying operating system is not allowed to coalesce across a
TCP Push boundary.  Your server would have to blindly iterate recv()
on an non-blocking socket until EWOULDBLOCK in order to "accidentally"
run on the app data.  But reading until EWOULDBLOCK is not reliable
in reading all the expected handshake data (which may be fragmented).

The existing proposal does neither require nor suggest the client to
coalesce the final client handshake messages (ChangeCipherSpec&Finished)
into a single TCP segment along with the initial TLS application data
record, and I think it would be a bad idea to make such a suggestion.

The currently stated purpose is solely to cut down on the number of
network round trips before the first TLS record with application
data can be sent from client to server.  That still works even when
sending the final handshake messages and the initial data records
in seperate TCP segments with a PSH flag on the segment with the
handshake messages.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Jun 2010 11:58:44 -0500

> What exactly do you mean by "read as much input as is available".

The description makes sense to me. Seems like a straightforward
optimization for a memory-constrained environment.

The $256 question is then, how many other servers are there that are
using similar optimizations?

I could also imagine code that rejected the unexpected data on the
principle of being conservative from a security perspective. The TLS
RFCs strongly imply (if not state explicitly) that this is illegal behavior.

It would be good for the ID to discuss possible ways for clients to
detect and handle servers that don't accept this optimization.

> record, and I think it would be a bad idea to make such a suggestion.

+1

The ID currently doesn't mention TCP anywhere, and of course, TLS
doesn't specifically require TCP anyway. Schemes that depended on
maintaining specific TCP segmentation characteristics would likely be
broken by any number of intermediate TCP-level proxies that never
guaranteed to preserve it (e.g. Tor).

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Fri, 4 Jun 2010 13:04:04 -0400

> using similar optimizations?

As noted in the draft, we have some fairly extensive real world
testing of False Start. Both with the application data being delayed
somewhat from the Finished and with it being in the same TCP packet.
We have so far found one host on the Internet which doesn't support
it.

AGL

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 4 Jun 2010 21:51:18 +0200

>> Trying to separate the packets will [not] do any good, as the  
>> server operating
> TCP Push boundary.

I don't think this is accurate.  Even with the "push" bit set, while  
the receiving system shouldn't just buffer the data waiting for more,  
the later TCP record may already have arrived when the earlier one is  
being processed, and boundaries won't necessarily be preserved.   
Heuristically, the sender's boundaries often *will* reappear as  
boundaries when receiving, but this isn't reliable.

Bodo