Re: [TLS] Updated draft

"tom.petch" <> Tue, 29 December 2009 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B05F23A6933 for <>; Tue, 29 Dec 2009 09:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_40=-0.185, J_CHICKENPOX_35=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uSUlo1YCUCuO for <>; Tue, 29 Dec 2009 09:13:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6E10C3A683D for <>; Tue, 29 Dec 2009 09:13:42 -0800 (PST)
X-Trace: 226420938/$PIPEX-ACCEPTED/pipex-customers/
X-SBRS: None
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQFAPXGOUs+vGl2/2dsb2JhbACCWyqFL4g/xgoKhCcE
X-IronPort-AV: E=Sophos;i="4.47,469,1257120000"; d="scan'208";a="226420938"
X-IP-Direction: IN
Received: from (HELO allison) ([]) by with SMTP; 29 Dec 2009 17:13:18 +0000
Message-ID: <051a01ca88a1$e5da94a0$0601a8c0@allison>
From: "tom.petch" <>
To: Marsh Ray <>
References: <> <044301ca84c0$6f34d0c0$0601a8c0@allison> <>
Date: Tue, 29 Dec 2009 17:10:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: Re: [TLS] Updated draft
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Dec 2009 17:13:44 -0000

----- Original Message -----
From: "Marsh Ray" <>
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
> :
> >    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.


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
It is unfortunate that neither sessions nor connections nor renegotiation (nor
things:-) are clearly defined so I will see what emerges from the parallel
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