Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > 
> > > Another problem that Larry has is that in his implementation what I call
> > > a "TLS connection" is called a "security context", and if the
> > > application re-handshakes (e.g., to authenticate a user) then the result
> > > is a second security context -- we need to be extra clear that it's the
> > > client Finished message from the _first_ "security context" that we're
> > > after.
> > 
> > OooopS.
> > 
> > The session that results from a re-handshake is an entirely new and
> > independent session from what it started from, it does NOT modify
> > the state of the original session (as identified by its TLS session ID).
> 
> What "oops"?  We need to identify one, and only one, client Finished
> message to use.  The name of the thing that that message is related to
> is only relevant to writing the text for this channel binding type's
> definition.

The OooopS refers to the fact, that a TLS session that is renegotiated
results in an entirely different TLS session with an independent
MasterSecret, and I am violently opposed to having to memorize in
the new re-negotiated TLS session anything from a completely unrelated
TLS session.


A full TLS-handshake and a later TLS session are still the same
underlying TLS session, sharing the master secret.  (they do have
connection-specific and direction specific crypto keys, of course).


When a Web Browser loads a new page containing several elements
(style sheets, buttons, icons, frames, etc.), then it first needs
to retrieve the top level document over a single network connection.
Doing so, a new TLS session can be created and added to the
session cache.  The session can be added to the cache as soon
as the TLS handshake is successfully completed, even before
any application data has been transferred.

Having received the top-level document, the browser determines
that it will have to load another dozen or so elements in order
to render the page, and will then usually open several network
connections in parallel (and probably reuse the one it just used
if it is HTTP 1.1 keep-alive).  If session caching on both sides
is working correctly, then the client can resume the original
TLS session on all additional parallel network connections
directly.

If there is one top-level-page, 12 elements and up to 4 parallel
network connections per server, then this will result in
a single full TLS handshake and 3 TLS session resumes and 
one session in the session caches of client and server.

  1st page:  1 full,  3 resumes,  1 session in the server session cache
  2nd page:  4 resumes, 1 session in the server session cache


If your server is a Microsoft IIS with special configuration,
then it goes like this:

1 full TLS-handshake plus 1 renegotiate (=1 full TLS-handshake)
plus 3 TLS-resumes, each followed by a renegotiate (=3 full TLS-handshakes)


  1st page: 5 full, 3 resumes, 5 sessions in the server session cache
  2nd page: 4 full, 4 resumes, 9 session in the server session cache


A full TLS handshake is typically at least 10x more expensive than
a TLS session resume (that is the crypto of the TLS handshake alone,
not counting any fancy certificate path validation or revocation
checking).


> 
> > 
> > The TLS specs do not describe API semantics, however, only the
> > network protocol and TLS session state, so your terminology is
> > IMHO confusing.
> 
> All of that is irrelevant.

No, it isn't.  With channel bindings, you are actually looking/asking for
a particular API semantic.

IMHO, a renegotiation is a problem for both TLS PRF ("extractors")
and channel bindings, because on the wire and at the TLS protocol
level (concerning the TLS session state), renegotiation restarts
everything from scratch.  It does so under protection of a previously
negotiated TLS session, but still, the original and the re-negotiated
session are completely distinct and will void all assumptions that
the application may have associated with the originally established
TLS session.


-Martin