[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Updated draft
From:       "tom.petch" <cfinss () dial ! pipex ! com>
Date:       2009-12-29 16:10:43
Message-ID: 051a01ca88a1$e5da94a0$0601a8c0 () allison
[Download RAW message or body]

----- Original Message -----
From: "Marsh Ray" <marsh@extendedsubset.com>
Sent: Thursday, December 24, 2009 9:00 PM


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

Marsh

This quote is from the base document for which this I-D is a corrigendum,
so unless the I-D amends it, the quote still applies.

This I-D should make clear the interaction of 'immediately previous handshake'
with respect to sessions and connections and at present, I don't think it does
so.
It is unfortunate that neither sessions nor connections nor renegotiation (nor
things:-) are clearly defined so I will see what emerges from the parallel
thread
on things and then most likely raise this again

Tom Petch.

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


[prev in list] [next in list] [prev in thread] [next in thread]