Re: [TLS] Questions about TLS Server Name Indication extension

Nelson B Bolyard <nelson@bolyard.me> Fri, 30 October 2009 19:24 UTC

Return-Path: <nelson@bolyard.me>
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 80F383A68D5 for <tls@core3.amsl.com>; Fri, 30 Oct 2009 12:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.836
X-Spam-Level:
X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599]
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 AiHswK0WPmRF for <tls@core3.amsl.com>; Fri, 30 Oct 2009 12:24:01 -0700 (PDT)
Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 8A83F3A6990 for <tls@ietf.org>; Fri, 30 Oct 2009 12:24:01 -0700 (PDT)
Received: (qmail 7582 invoked from network); 30 Oct 2009 19:24:18 -0000
Received: from unknown (67.188.69.99) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 30 Oct 2009 19:24:18 -0000
Message-ID: <4AEB3D5B.1070406@bolyard.me>
Date: Fri, 30 Oct 2009 12:24:11 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <200910301504.n9UF4Vi1009766@fs4113.wdf.sap.corp>
In-Reply-To: <200910301504.n9UF4Vi1009766@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Questions about TLS Server Name Indication extension
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: Fri, 30 Oct 2009 19:24:02 -0000

On 2009-10-30 08:04 PDT, Martin Rex wrote:
> Nelson B Bolyard wrote:
>> On 2009-10-29 16:26 PDT, Martin Rex wrote:
>>> Nelson B Bolyard wrote:
>>>> There's another issue that arises with both the SNI extension and a single
>>>> session ID space for the entire physical server.  Which takes precedence?
> 
> If the SNI made a difference in the server credential when the session
> was originally created, then the SNI MUST make the same difference
> for resume.  The a requirement for consistency and reproducable behaviour.
> 
> If the SNI did not make a difference when the cached session was
> originally created (e.g. the server doesn't support SNI), then it
> does not need to make a difference on resume.

RFC 5246 says:

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption.  Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.  However, some extensions may
   specify different behavior during session resumption.

You're saying that SNI is not like "Most current TLS extensions" in that
when an older session is resumed, the server DOES process this extension,
and its behavior is NOT different during session resumption than during
session initiation.

I think that's a legitimate and self-consistent proposal, one of several
that I could envision, which is why I raised this subject.  But as we've
seen in this thread, others (e.g. IBM) clearly have implemented a very
different model.

For the sake of interoperability, I think we need to define a single
standard definition to which we all adhere.

> 
>>>> Consider this scenario:
>>>> Physical host has two virtual hosts, A and B.
>>>> First handshake:
>>>>   client sends SNI with host name A, empty session ID.
>>>>   server does full handshake, session ID 1.
>>>> Second handshake (renegotiation):
>>>>   client sends SNI with host name B and session ID 1,
>>> That client is obviously broken.
>> Perhaps, but the question is what does the server do about it?
> 
> Compensate for the broken client and perform a full SSL handshake.

IBM's answer was: ignore the SNI and resume session ID 1 with host A,
which seems to be what RFC 5246 says TLS should do for _most_ TLS hello
extensions.  But I agree that we _could_ *define* SNI to not be like
_most_ TLS hello extensions, if we choose.

> A broken client is no excuse for inconsistent or non-predictable
> server behaviour.  

I agree that, ONCE we all agree that your definition is the right one,
then we agree that the above behavior is that of a broken client.
OTOH, if we end up agreeing that IBM's answer is the right one, then
I don't think we necessarily agree that a client behaving as described above
is necessarily broken.

Regards,
/Nelson