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

Nelson B Bolyard <nelson@bolyard.me> Fri, 30 October 2009 04:52 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 9DFC83A69D4 for <tls@core3.amsl.com>; Thu, 29 Oct 2009 21:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.884
X-Spam-Level:
X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=-0.285, 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 up+yEvV0sMIm for <tls@core3.amsl.com>; Thu, 29 Oct 2009 21:52:24 -0700 (PDT)
Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id C05BF3A68B8 for <tls@ietf.org>; Thu, 29 Oct 2009 21:52:24 -0700 (PDT)
Received: (qmail 23816 invoked from network); 30 Oct 2009 04:52:39 -0000
Received: from unknown (67.188.69.99) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 30 Oct 2009 04:52:39 -0000
Message-ID: <4AEA7117.7050309@bolyard.me>
Date: Thu, 29 Oct 2009 21:52:39 -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: <200910292326.n9TNQvVb016843@fs4113.wdf.sap.corp>
In-Reply-To: <200910292326.n9TNQvVb016843@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Alexei.Volkov@sun.com
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 04:52:25 -0000

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

>> Session ID 1 implicitly identifies host A.
>>
>> The server could
>> A)  Honor the session ID and ignore the SNI.
>> B)  Compare the host name in the SNI with the host name for session ID 1,
>>     observe the mismatch, and do a new FULL handshake for host B.
>> C)  Compare the host name in the SNI with the host name for session ID 1,
>>     observe the mismatch, and return a fatal error alert.
> 
> If the server supports virtual hosting through SNI, 

that's a given for this exercise

> it should look up the session ID of the client only in the session cache 
> associated with the hostname A.

And it should choose hostname A because why?  Remember that in the above
example, the SNI bears host name B.

> If a TLS session resume proposal with [an] SNI for B arrives,
> there will be no cached session with that session ID in the
> TLS session cache tied to credential for A, so it must result
> in a full TLS handshake.

So, you're proposing that the server should look in the SNI first to see
which host name is there, and use that info to decide which virtual host's
server session cache to examine for the numbered session?  In other words,
each virtual host has its own separate session cache with fully overlapping
spaces of session ID numbers, disambiguated by the SNI host name, yes?
In this model, an SNI would be absolutely required to resume a session that
had been established with an SNI, yes?


> A server that has different credentials for A and B (and would
> use them based on SNI 

The whole point of SNI is to have different credentials for different
virtual hosts.  If you don't have different credentials for different
virtual hosts, (e.g. if you have a single certificate for all your
virtual hosts) then you don't need SNI.

> is definitely broken if it agrees to a proposed resume of a session
> originally established with A in a ClientHello that carries an SNI for B,
> because the server knows exactly that the server certificate that the
> client has for this session is NOT the same certificate that the server 
> would send in a full handshake for B.

This objective could be accomplished with a single server session cache
that covered the entire physical server and all its virtual servers, IF
the server compared the host name in the SNI with the host name associated
with the session in the cache.  But I see that your proposal definitely
gives precedence to the SNI.  This is quite different than Mick's answer.