Re: [TLS] Updated draft

[Marsh Ray <[e-mail]>]

tom.petch wrote:
> I find the reference to
>       immediately previous handshake
> in s.3 unclear.

The complete wording from
http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt :
>    o  For ClientHellos which are renegotiating, this field contains the
>       verify_data from the Finished message sent by the client on the
>       immediately previous handshake.  For current versions of TLS, this
>       will be a 12-byte value.
>    o  For ServerHellos which are renegotiating, this field contains the
>       concatenation of the verify_data values sent by the client and the
>       server (in that order) on the immediately previous handshake.  For
>       current versions of TLS, this will be a 24-byte value.


> Thinking of session resumption, as identified in RFC5246,

Please don't. :-)

This draft is about renegotiation, session resumption has nothing to do
with it.

I, too, used to conflate renegotiation and resumption but they are
completely unrelated.

The term "resumption" only appears in the document twice, both times
like "even when TLS session resumption is used".

> there are three cases
> namely
>   "The session identifier MAY be from an earlier connection,
>    this connection, or from another currently active connection."

The term "session identifier" appears nowhere in the draft. Session
identifiers do not play a part in this fix for renegotiation.

> Which connection should the immediately previous handshake come from

The connection that is renegotiating.

Renegotiation is a change in the session state of a single connection.

> given that there may be one session and multiple connections
> (each of which may be independently re-negotiating) in each of these three
> cases?

Sessions don't relate directly to the fix either. The best term I can
find for the things that are renegotiated between is "connection state".

> My grasp of TLS session and TLS connection may not be as crystal clear
> as it might be;

This is extremely common, I know it took me weeks to figure it out. Now
that I think I understand it, it's no longer obvious to me how why it's
so difficult.

Improvements in the TLS RFCs might help. Renegotiation is only discussed
minimally because it's simple to describe, whereas resumption takes more
words.

> I see session as defined by a common session
> identifier but connection being the construct whose protocol is changed by
> this I-D.

Looks good to me.

Just keep in mind the many-to-many relationship between sessions and
connections. A connection may handle multiple sessions (generally at
different times) and a session may be on multiple connections
(simultaneously or separated in time). An instance of a session on a
connection is referred to as a "connection state".

- Marsh