[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
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis t.petch
- [TLS] Text for draft-ietf-tls-rfc4366-bis Joseph Salowey (jsalowey)
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Joseph Salowey (jsalowey)
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Michael D'Errico
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis t.petch
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Martin Rex
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Joseph Salowey (jsalowey)
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Joseph Salowey (jsalowey)
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Martin Rex
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Michael D'Errico
- Re: [TLS] Text for draft-ietf-tls-rfc4366-bis Donald Eastlake