Re: [TLS] Text for draft-ietf-tls-rfc4366-bis

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Thu, 20 May 2010 15:29 UTC

Return-Path: <jsalowey@cisco.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 282733A66B4 for <tls@core3.amsl.com>; Thu, 20 May 2010 08:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.46
X-Spam-Level:
X-Spam-Status: No, score=-8.46 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_50=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
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 uVDBSGrsbvPL for <tls@core3.amsl.com>; Thu, 20 May 2010 08:29:34 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2082F3A67AB for <tls@ietf.org>; Thu, 20 May 2010 08:29:34 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYKAKPx9EurR7Ht/2dsb2JhbACOP49FcaREmVaFEgSDQA
X-IronPort-AV: E=Sophos;i="4.53,272,1272844800"; d="scan'208";a="532720905"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 20 May 2010 15:29:27 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4KFTFmo019351; Thu, 20 May 2010 15:29:27 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 May 2010 08:29:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 May 2010 08:29:21 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A67D0FA@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <003701caf817$b4754140$4001a8c0@gateway.2wire.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Text for draft-ietf-tls-rfc4366-bis
Thread-Index: Acr4IIZ/PiPUc5BCTiKcjQiW2ZN4ywADB1WQ
References: <AC1CFD94F59A264488DC2BEC3E890DE50A67D09A@xmb-sjc-225.amer.cisco.com> <003701caf817$b4754140$4001a8c0@gateway.2wire.net>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "t.petch" <ietfc@btconnect.com>, tls@ietf.org
X-OriginalArrivalTime: 20 May 2010 15:29:22.0783 (UTC) FILETIME=[390EAEF0:01CAF831]
Subject: Re: [TLS] Text for draft-ietf-tls-rfc4366-bis
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, 20 May 2010 15:29:35 -0000

Good suggestion, thanks for the text, here is the text reworked:

"When the server is deciding whether or not to accept a request to
resume
 a session, the contents of a server_name extension may be used in 
 the lookup of the session in the session cache.  The client SHOULD 
 include the same server_name extension in session resumption 
 request as it did in the full handshake that established the
 session.  If the server_name extension contains a different name, 
 the server MUST NOT accept the request to resume the session. 
 Instead, it proceeds with a full handshake to establish a new 
 Session.  The client MAY omit the extension, in which case, if 
 the server chooses to resume the session, it must use the server 
 name cached from the original full handshake. When resuming a 
 session, the server MUST NOT include a server_name extension in
 the server hello."

Changes to section 1.1

"Note also that all the extensions defined in this document are
 relevant only when a session is initiated.  When a client includes
 one or more of the defined extension types in an extended client
 hello while requesting session resumption:

	-  The server name indication extension MAY be used by the 
         server when deciding whether or not to resume a session 
         as described in section 3.

      -  If the resumption request is denied, the use of the extensions
         is negotiated as normal.

      -  If, on the other hand, the older session is resumed, then the
         server MUST ignore the extensions and send a server hello
         containing none of the extension types.  In this case, the
         functionality of these extensions negotiated during the
         original session initiation is applied to the resumed session."

> -----Original Message-----
> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Thursday, May 20, 2010 3:04 AM
> To: Joseph Salowey (jsalowey); tls@ietf.org
> Subject: Re: [TLS] Text for draft-ietf-tls-rfc4366-bis
> 
> Joe
> 
> I think that it still avoids the point that has been raised.
> 
> Setting aside my dislike of using 'session resumption':-), I think
that
> the new text should split out the decision as to whether or not to
> accept such a request from the subsequent mechanics ie the first
> sentence must be along the lines of
> 
> "When the server is deciding whether or not to accept a request to
resume
> a
> session, the contents of a server_name extension may be used in the
lookup
> of
> the session in the session cache."
> followed by such as
> "The client SHOULD include the same server_name extension during
session
> resumption request as it did in the full handshake that established
the
> session.
> If the server_name extension contains a different name, the server
MUST
> NOT
> accept the request to resume the session. Instead, it proceeds with a
full
> handshake to establish a new session
> 
> " The client MAY omit the extension, in which case, if the server
chooses
> to resume the session, it must use the server name cached from the
> original full handshake.
> 
> "When resuming a session, the server MUST NOT include a server_name
> extension in
> the server hello."
> etc
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
> To: <tls@ietf.org>
> Sent: Thursday, May 20, 2010 7:15 AM
> Subject: [TLS] Text for draft-ietf-tls-rfc4366-bis
> 
> 
> > Below is some proposed text for inclusion in section 3 of
> > draft-ietf-tls-rfc4366-bis. The text now clarifies that the server
name
> > can be used by the server in looking up the cached session.   Please
> > respond to the list with any issues or improvements to the text.
> >
> > Thanks,
> >
> > Joe
> >
> > New text in section 3 to replace "When the server resumes a session,
the
> > server_name extension is ignored.":
> >
> > "When the server resumes a session, the contents of server_name
> > extension may be used in the lookup of the session in the session
cache.
> > The client SHOULD include the same server_name extension during
session
> > resumption as it did in the full handshake that established the
session.
> > The client MAY omit the extension, in which case, if the server
chooses
> > to resume the session it must use the server name cached from the
> > original full handshake.  The client MUST NOT include a different
server
> > name than what is included in the original full handshake.  If the
> > server_name extension contains a different name the server MUST NOT
> > allow the session to be resumed.  Instead, it proceeds with a full
> > handshake to establish a new session. When resuming a session, the
> > server MUST NOT include a server_name extension in the server
hello."
> >
> > In addition the end of section 1.1 needs some modification to the
last
> > paragraph and bullet points:
> >
> > "Note also that all the extensions defined in this document are
> >  relevant only when a session is initiated.  When a client includes
> >  one or more of the defined extension types in an extended client
> >  hello while requesting session resumption:
> >
> >       -  If the resumption request is denied, the use of the
extensions
> >          is negotiated as normal.
> >
> > -  The server name indication extension MAY be used during the
> >          lookup of a cached session as described in section 3.
> >
> >       -  If, on the other hand, the older session is resumed, then
the
> >          server MUST ignore the extensions and send a server hello
> >          containing none of the extension types.  In this case, the
> >          functionality of these extensions negotiated during the
> >          original session initiation is applied to the resumed
session."
> >
> > Cheers,
> >
> > Joe
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls