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

[Martin Rex <[e-mail]>]

Bodo Moeller wrote:
> 
> > 	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

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