Re: [TLS] Updated draft

"tom.petch" <cfinss@dial.pipex.com> Tue, 29 December 2009 17:13 UTC

Return-Path: <cfinss@dial.pipex.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05F23A6933 for <tls@core3.amsl.com>; Tue, 29 Dec 2009 09:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSUlo1YCUCuO for <tls@core3.amsl.com>; Tue, 29 Dec 2009 09:13:42 -0800 (PST)
Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 6E10C3A683D for <tls@ietf.org>; Tue, 29 Dec 2009 09:13:42 -0800 (PST)
X-Trace: 226420938/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.118/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.105.118
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-SMTP-AUTH:
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 1cust118.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.118]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Dec 2009 17:13:18 +0000
Message-ID: <051a01ca88a1$e5da94a0$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Marsh Ray" <marsh@extendedsubset.com>
References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <044301ca84c0$6f34d0c0$0601a8c0@allison> <4B33C86D.9010405@extendedsubset.com>
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
Cc: tls@ietf.org
Subject: Re: [TLS] Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Dec 2009 17:13:44 -0000

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