Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 17 May 2010 15:44 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 ECDB83A6D56 for <tls@core3.amsl.com>; Mon, 17 May 2010 08:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.174
X-Spam-Level:
X-Spam-Status: No, score=-9.174 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_20=-0.74, 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 3hFmsTteDrMP for <tls@core3.amsl.com>; Mon, 17 May 2010 08:44:46 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9B34528C170 for <tls@ietf.org>; Mon, 17 May 2010 08:42:43 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAB4B8UurR7Ht/2dsb2JhbACdc3GiX5lChRAEg0A
X-IronPort-AV: E=Sophos;i="4.53,247,1272844800"; d="scan'208";a="256288412"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 17 May 2010 15:42:35 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4HFgZQC029016; Mon, 17 May 2010 15:42:35 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 08:42:25 -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: Mon, 17 May 2010 08:42:24 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A67C2D6@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <201005171321.o4HDLgmX018711@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
Thread-Index: Acr1w+tAAbWc1QMHQzGum/6F/eAlEAADi4Hg
References: <AC1CFD94F59A264488DC2BEC3E890DE50A67C235@xmb-sjc-225.amer.cisco.com> from "Joseph Salowey" at May 16, 10 09:43:08 pm <201005171321.o4HDLgmX018711@fs4113.wdf.sap.corp>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: mrex@sap.com
X-OriginalArrivalTime: 17 May 2010 15:42:25.0749 (UTC) FILETIME=[8C809050:01CAF5D7]
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to 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: Mon, 17 May 2010 15:44:48 -0000

I do not think the behavior that Mike describes is strictly compliant
with RFC 4366 as it states that the SNI should be ignored when resuming
a session. From an interop point of view I think it is important to
clarify that the server does not use the SNI extension in the look-up
the session ID in the session cache.  If the session is resumed and
client presents an SNI extension in the resumption attempt it should get
the same result as if it did not.  The client should not attempt to use
a different SNI in the resumption as it is ambiguous.  

How about the following text:

"When the server resumes a session, the server_name extension is ignored
and not used in the lookup of the session in the session cache.  If the
session is resumed, the server will always use the server name
associated with the cached session. The server MUST NOT include a
server_name extension in the server hello. When resuming a session the
client MUST NOT use a different server name than the one used in
establishing the original session.  The client MAY omit the server_name
extension during session resumption. " 

Joe

> -----Original Message-----
> From: Martin Rex [mailto:mrex@sap.com]
> Sent: Monday, May 17, 2010 6:22 AM
> To: Joseph Salowey (jsalowey)
> Cc: mike-list@pobox.com; d3e3e3@gmail.com; tls@ietf.org
> Subject: Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
> 
> Joseph Salowey wrote:
> >
> > This clarification is consistent with existing text in the draft and
in
> > RFC 4366.
> 
> The way it is written appears somewhat misleading, and the resulting
> change to 4366 indicates that we need to come up with a better
> description.
> 
> >
> > " Note also that all the extensions defined in this section are
> >    relevant only when a session is initiated. ...
> >
> > -  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."
> >
> > Michael D'Errico wrote:
> > >
> > >    Add to section 3 before the last paragraph to clarify session
> > >    resumption behavior:
> > >
> > >    "When the server resumes a session, the server_name extension
> > >    is ignored."
> > >
> > > I have not yet done it, but I plan to have my session resumption
> > > logic look at the SNI to see if it matches the name used for the
> > > cached session.  If they don't match, a full handshake will be
> > > completed.  We already have to verify that TLS version, cipher
> > > suite, and compression method are compatible with the hello
> > > parameters.  I don't see why the SNI is any less important.
> 
> 
> Your intended behaviour sounds perfectly fine and sensible.
> 
> >
> > > Does the above text suggest that my plan would be non-compliant?
> 
> 
> No.  Your intention is to determine whether a suitable cached session
> exist for resumption.  Once you have determined that, you resume
without
> SNI affecting the characteristics of the resumed session.
> 
> 
> But your confusion suggests that this should probably be rephrased
> in order clarify what is meant.
> 
> 
> There are two entirely seperate issues that ought to be distinguished.
> 
> (1) criteria which the server considers in his decision whether to
>     resume a TLS session from the cache by performing an abbreviated
>     TLS handshake for the TLS session ID proposed by the TLS client in
>     the ClientHello handshake message.
> 
> (2) effects of parameters in ClientHello (regular or through
extensions)
>     on the characteristics of the established TLS session.
> 
> 
> What Joe an the new text says is only about (2).  When the server
decides
> to resumt a TLS session from cache, then it must be resumed as-is,
none
> of the parameters or extensions in the ClientHello is allowed to
modify
> the characteristics of the resumed TLS session.
> 
> 
> (1) is a totally different beast.  Whether or not the server resumes a
> TLS session proposed by the TLS client is completely at the
> discretion of the server.  IMHO, it makes perfect sense for the
> server to check whether the attributes that the client requests
> through all those parameters in regular ClientHello plus TLS extension
> actually match the characteristics of proposed cached session,
> and to go through a full TLS handshake if they don't.
> A server can also expire a session from his session cache whenever
> it sees a need to do so.
> 
> 
> In some implementations, the TLS session cache may be shared among
> several processes on a host, not just a single application that tries
> to offer virtual hosting with TLS through the server name indication
(SNI)
> TLS extension.  That correct client implementations shouldn't be
> proposing to resume TLS sessions across "virtual hosts" boundaries is
> not relevant for the server's decision.  The server should not try to
> make any assumptions on client desire or behaviour, but instead act
> deterministically based on the parameters in the supplied ClientHello
> handshake message.
> 
> 
> 
> -Martin