[TLS] Questions about TLS Server Name Indication extension
Nelson B Bolyard <nelson@bolyard.me> Wed, 28 October 2009 03:37 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 9400C28C151 for <tls@core3.amsl.com>; Tue, 27 Oct 2009 20:37:30 -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 eNYRmC+iHtwE for <tls@core3.amsl.com>; Tue, 27 Oct 2009 20:37:29 -0700 (PDT)
Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 77A553A676A for <tls@ietf.org>; Tue, 27 Oct 2009 20:37:29 -0700 (PDT)
Received: (qmail 26817 invoked from network); 28 Oct 2009 03:37:38 -0000
Received: from unknown (67.188.69.99) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 28 Oct 2009 03:37:38 -0000
Message-ID: <4AE7BC74.9010806@bolyard.me>
Date: Tue, 27 Oct 2009 20:37:24 -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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Alexei Volkov <Alexei.Volkov@Sun.COM>
Subject: [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 03:37:30 -0000
A few years ago, I implemented the SNI extension in a client-only TLS library and it was really simple because I only ever sent one host name to the server. Now I'm implementing the server side of SNI and I realize that the RFC appears to allow clients to do much more complex things than my client ever did. So, I have some questions seeking clarification about the definition of SNI. I hope someone here can help me by answering some of these questions. Q1) A client hello's SNI extension is defined such that it may contain multiple names. Perhaps the intent was to allow the same server to be named in multiple different name spaces (DNS and others), but I saw nothing in RFC 4366 that precludes the client from naming multiple different hosts in a single ServerNameList. If a client names multiple host names in a single client hello SNI extension (let's call them A.foo.com, B.foo.com and C.foo.com) how does the client learn which one of those has been chosen by the server? RFC 4366 requires the "extension_data" field of the SNI extension in the server hello to be empty. The server may respond with a "wildcard" certificate ("*.foo.com"), or with a certificate with multiple Subject Alternative Names that include more than one of the names given by the client. In that case, how does the client know which FQDN is the one that the physical server has chosen/identified? I can think of lots of possible answers here, including a) It is an error to include multiple names in the same name space, e.g. multiple DNS names. (but the RFC doesn't say that.) b) If multiple names are included, they must be logically synonymous, all alternative names for the same host. (What if they're not?) Q2) if multiple non-synonymous names are included, is the server free to pick any one that it wants? 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. Are there any special requirements or prohibitions on the use and contents of the client hello's SNI extension in the renegotiation case? Q3a) Is SNI permitted in that case? Q3b) Is it required to match the SNI of the original handshake, if any? Q3c) If it contains multiple non-synonymous host names, is the server allowed to choose a different one than the one chosen in the first handshake? The next questions have to do with the "resumption" or "restart" of a TLS session that has been previously established using an SNI extension that named one or more virtual hosts in a connection to a physical server on an IP address and port. Q4) In that context, is the scope of a TLS session ID that of the physical server, or that of a virtual server? When attempting to restart a TLS session on a new connection, does the TLS session ID in the client hello uniquely identify the virtual host and its session to the physical server, even in the absence of an SNI extension? Or is it possible that each of the virtual servers within the physical host may have used that same session ID, in which case it would be necessary for the client to supply the virtual host's FQDN in an SNI extension to uniquely identify the session? Q5) When an SNI extension was used to establish a TLS session, it is required that an SNI extension bearing the same host name be used in the client hello that attempts to "restart" or "resume" the session on a new connection? (Obviously Q3, Q4 and Q5 overlap.) I eagerly await your answers and comments. /Nelson Bolyard
- [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