Re: [TLS] Updated draft

Marsh Ray <marsh@extendedsubset.com> Thu, 24 December 2009 20:01 UTC

Return-Path: <marsh@extendedsubset.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 B95373A689A for <tls@core3.amsl.com>; Thu, 24 Dec 2009 12:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599]
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 VCdQPRmQC6Nt for <tls@core3.amsl.com>; Thu, 24 Dec 2009 12:01:10 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id DD5E83A69E0 for <tls@ietf.org>; Thu, 24 Dec 2009 12:01:06 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NNtrd-0005id-5O; Thu, 24 Dec 2009 20:00:49 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7CC72603A; Thu, 24 Dec 2009 20:00:47 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/6T7H/cMJ4H1Xq0lHkI/ccE0Z3Zf9hDRk=
Message-ID: <4B33C86D.9010405@extendedsubset.com>
Date: Thu, 24 Dec 2009 14:00:45 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "tom.petch" <cfinss@dial.pipex.com>
References: <20091216213202.C5CC26C82B8@kilo.networkresonance.com> <044301ca84c0$6f34d0c0$0601a8c0@allison>
In-Reply-To: <044301ca84c0$6f34d0c0$0601a8c0@allison>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 24 Dec 2009 20:01:11 -0000

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