Re: [TLS] Questions about TLS Server Name Indication extension
Nelson B Bolyard <nelson@bolyard.me> Wed, 28 October 2009 17:34 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 41AEE3A6A2A for <tls@core3.amsl.com>; Wed, 28 Oct 2009 10:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 LG9HYfz7MaGM for <tls@core3.amsl.com>; Wed, 28 Oct 2009 10:34:53 -0700 (PDT)
Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id 21DD53A697A for <tls@ietf.org>; Wed, 28 Oct 2009 10:34:52 -0700 (PDT)
Received: (qmail 22774 invoked from network); 28 Oct 2009 17:35:07 -0000
Received: from unknown (67.188.69.99) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 28 Oct 2009 17:35:07 -0000
Message-ID: <4AE880CA.3060902@bolyard.me>
Date: Wed, 28 Oct 2009 10:35:06 -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: <E1N32Q4-00072H-J3@wintermute01.cs.auckland.ac.nz>
In-Reply-To: <E1N32Q4-00072H-J3@wintermute01.cs.auckland.ac.nz>
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: Wed, 28 Oct 2009 17:34:54 -0000
On 2009-10-27 23:54 PDT, Peter Gutmann wrote: > Nelson B Bolyard <nelson@bolyard.me> writes: > >> I eagerly await your answers and comments. > > OK, I'll bite: > >> Q1) A client hello's SNI extension is defined such that it may contain >> multiple names. > > Intuitively I would say option (a) is the right one, if you're expecting > to connect to a.foo.com then it doesn't seem to make much sense to say > you'd also like b.foo.com, c.foo.com, amazon.com, youtube.com, and > phishme.com. I'm sure someone can dream up some bizarre corner case > where you could in theory possibly somehow maybe do this, but in the > interests of implementation sanity I'd say you're only allowed one name. I've been informed that the SNI implementation in OpenSSL/mod_ssl/Apache only honors the first host name in the client hello SNI extension, and will send an unrecognized_name alert if that first name is unrecognized. I'm quite willing to follow that example and let that become the de facto standard. I just wish the RFC was clear about it, and wonder why the RFC even allows multiple names to be sent. >> Q2) if multiple non-synonymous names are included, is the server free >> to pick any one that it wants? > > This one is resolved by the solution for Q1 above. > >> Q3) Consider the "renegotiation" case, where a client and server >> negotiate an initial SSL handshake ("in the clear") and then negotiate >> a second handshake over the encrypted channel established by the first >> handshake. > > I'd say it's not permitted, it's still the same server and (again) all > you're going to do is create confusion if you allow new SNI's to be > inserted at this point. This answers all the subquestions in one. Well, consider that there are people who don't want to do client authentication in the initial handshake because they don't want to send the client cert over the wire in the clear. Perhaps they also don't want to send the virtual host name in the clear, or receive the cert for the intended virtual host in the clear. So, one could imagine that they do an initial handshake without any SNI, then a subsequent renegotiation with SNI. I'm not advocating that. I'm merely suggesting that forbidding SNI in renegotiation might be seen as unnecessarily restrictive in some applications. > Q4 and 5 get a bit complicated, I'd need to hear a bit more about the > circumstances where this might occur... I received some other email that suggests that my use of the word "scope" rather than "space" may have made the question unclear, so let me try to reword Q4 here. In the context of a physical server acting as multiple virtual server, is the space of session IDs coming from that server a single space that encompasses all the sessions for all the virtual servers served by that physical server? Or does each virtual server have its own separate space? If each virtual server has its own separate session ID space, then when attempting to "resume" or "restart" a TLS session, the client hello MUST bear an SNI extension to inform the physical server which virtual server's session ID space contains the given session ID, and each virtual server potentially has its own separate session store/cache. OTOH, if there is a single session ID space for the entire physical server covering all the virtual servers, then each cached session must record and identify the virtual server with which it is associated. I'm just wondering which way is the right way to implement session cache lookup in an SNI environment.
- [TLS] Questions about TLS Server Name Indication … Nelson B Bolyard
- Re: [TLS] Questions about TLS Server Name Indicat… Nelson B Bolyard
- Re: [TLS] Questions about TLS Server Name Indicat… Wan-Teh Chang
- Re: [TLS] Questions about TLS Server Name Indicat… Michael D'Errico
- Re: [TLS] Questions about TLS Server Name Indicat… Nelson B Bolyard
- Re: [TLS] Questions about TLS Server Name Indicat… Michael Gray
- Re: [TLS] Questions about TLS Server Name Indicat… Wan-Teh Chang
- Re: [TLS] Questions about TLS Server Name Indicat… Peter Gutmann
- Re: [TLS] Questions about TLS Server Name Indicat… Martin Rex
- Re: [TLS] Questions about TLS Server Name Indicat… Martin Rex
- Re: [TLS] Questions about TLS Server Name Indicat… Nelson B Bolyard
- Re: [TLS] Questions about TLS Server Name Indicat… Nelson B Bolyard
- Re: [TLS] Questions about TLS Server Name Indicat… Martin Rex
- Re: [TLS] Multiple domain names in SNI (was Quest… Michael D'Errico
- Re: [TLS] Multiple Session Caches and SNI (was Qu… Michael D'Errico
- Re: [TLS] Multiple domain names in SNI (was Quest… Martin Rex
- Re: [TLS] Renegotiation with SNI after initial co… Michael D'Errico
- Re: [TLS] Multiple domain names in SNI (was Quest… Michael D'Errico
- Re: [TLS] Multiple Session Caches and SNI (was Qu… Martin Rex
- Re: [TLS] Multiple domain names in SNI (was Quest… Martin Rex
- Re: [TLS] Questions about TLS Server Name Indicat… Nelson B Bolyard
- Re: [TLS] Multiple Session Caches and SNI Michael D'Errico
- Re: [TLS] Multiple domain names in SNI (was Quest… Michael Gray
- Re: [TLS] Multiple domain names in SNI (was Quest… Michael D'Errico
- Re: [TLS] Requiring SNI for resumption (was Quest… Michael D'Errico
- Re: [TLS] Multiple Session Caches and SNI Martin Rex
- Re: [TLS] Multiple Session Caches and SNI Michael D'Errico
- Re: [TLS] Questions about TLS Server Name Indicat… Michael D'Errico
- Re: [TLS] Questions about TLS Server Name Indicat… Pasi.Eronen