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

Martin Rex <mrex@sap.com> Mon, 17 May 2010 17:12 UTC

Return-Path: <mrex@sap.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 E6FD33A6AA4 for <tls@core3.amsl.com>; Mon, 17 May 2010 10:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.734
X-Spam-Level:
X-Spam-Status: No, score=-7.734 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 Eywa-+u4Pzn0 for <tls@core3.amsl.com>; Mon, 17 May 2010 10:12:06 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5404D28C110 for <tls@ietf.org>; Mon, 17 May 2010 10:11:32 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o4HHBIka017396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 May 2010 19:11:18 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005171711.o4HHBHNg001424@fs4113.wdf.sap.corp>
To: jsalowey@cisco.com (Joseph Salowey)
Date: Mon, 17 May 2010 19:11:17 +0200 (MEST)
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A67C2D6@xmb-sjc-225.amer.cisco.com> from "Joseph Salowey" at May 17, 10 08:42:24 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
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
Reply-To: mrex@sap.com
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 17:12:08 -0000

Joseph Salowey wrote:
> 
> 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.

I would really like to you distinguish the details more carefully.

"ignored when resuming a session" is something that applies
_after_ the server's decision to resume a proposed TLS 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.

It is just the opposite.  If a Server _supports_ SNI, it ought to make
the chosen value from the previous handshake part of the cached TLS session,
and re-validate any SNI values supplied by the client in ClientHello
on every session resumption.


>
> 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.

Full agreement here.


>
> The client should not attempt to use a different SNI in the
> resumption as it is ambiguous.  

Although I'm also in full agreement on the client's behaviour,
this ought not to have any relevance for the server's decision.
The server is supposed to act on data that is actually present in
ClientHello.  The server should not try to guess what the client
may have desired and potentially mis-represented in ClientHello params.

> 
> 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. " 


I'd like to see instead something more like this:

"If a server implements _and_ confirms the use of a server_name extension
 proposed by a TLS client on a full TLS handshake, then the server MUST
 validate the contents of the server_name extension on all attempts of
 the TLS client to later resume this TLS session from the TLS session
 cache in an abbreviated handshake.  If a validation is necessary,
 and that validation fails, the server MUST perform a full TLS handshake.

 TLS clients that want to propose TLS session resumption, SHOULD provide
 the same parameters in ClientHello (including TLS extensions) as in the
 original handshake, because the server is supposed to validate these
 parameters against the characteristics of the cached session from the
 original full TLS handshake, and the server is supposed to perform
 a full TLS handshake instead of a TLS session resumption if that
 validation of the ClientHello parameters determines that it will
 result in a TLS session with different characteristics."

-Martin