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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> 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?

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.


>
> 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.

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