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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Thu, 20 May 2010 05:17 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 B88143A6C80 for <tls@core3.amsl.com>; Wed, 19 May 2010 22:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.885
X-Spam-Level:
X-Spam-Status: No, score=-8.885 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_40=-0.185, 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 1uIhhjVfxEA8 for <tls@core3.amsl.com>; Wed, 19 May 2010 22:17:10 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 929C13A6CC1 for <tls@ietf.org>; Wed, 19 May 2010 22:15:27 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As8KAKpi9EurR7H+/2dsb2JhbACOPoM1jA9xowWZSIURBINA
X-IronPort-AV: E=Sophos;i="4.53,268,1272844800"; d="scan'208";a="132208132"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 May 2010 05:15:08 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4K5F8Qt000601 for <tls@ietf.org>; Thu, 20 May 2010 05:15:08 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 May 2010 22:15:08 -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: Wed, 19 May 2010 22:15:06 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A67D09A@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Text for draft-ietf-tls-rfc4366-bis
Thread-Index: Acr322kSN3wNGMqhRZKxHPre59iMKQ==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: tls@ietf.org
X-OriginalArrivalTime: 20 May 2010 05:15:08.0601 (UTC) FILETIME=[6A40CA90:01CAF7DB]
Subject: [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 05:17:13 -0000

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