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

Michael Gray <mickgray@au1.ibm.com> Thu, 29 October 2009 00:11 UTC

Return-Path: <mickgray@au1.ibm.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 EACB03A68C7 for <tls@core3.amsl.com>; Wed, 28 Oct 2009 17:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lQeLsHCaET5q for <tls@core3.amsl.com>; Wed, 28 Oct 2009 17:11:01 -0700 (PDT)
Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id CE0683A68E4 for <tls@ietf.org>; Wed, 28 Oct 2009 17:11:00 -0700 (PDT)
Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id n9T08clh007334 for <tls@ietf.org>; Thu, 29 Oct 2009 11:08:38 +1100
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9T08LiA1687772 for <tls@ietf.org>; Thu, 29 Oct 2009 11:08:22 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9T0BDlA027776 for <tls@ietf.org>; Thu, 29 Oct 2009 11:11:13 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9T0BCmb027769; Thu, 29 Oct 2009 11:11:12 +1100
In-Reply-To: <4AE8D30D.6020305@bolyard.me>
To: Nelson B Bolyard <nelson@bolyard.me>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF61172767.312DF080-ON4A25765D.0081EB68-4A25765E.00005E97@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Thu, 29 Oct 2009 10:04:02 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 29/10/2009 11:17:40
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Cc: Alexei.Volkov@sun.com, tls@ietf.org
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: Thu, 29 Oct 2009 00:11:02 -0000

<nelson@bolyard.me> wrote:

> 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,
>
> 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.
>
> RFC 5246 seems to suggest choice A.  It says:
>
>    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.
>
> But I tend to lean towards choice B myself.
>
> What do other SNI server implementations do in this case?

A for IBM native SSL.  The Client SNI data is only processed if the session
can NOT be resumed.

Also as an answer to the previous question; we only consider that the
Client has sent a single name in Client SNI request.

Also on previous note <snip> 'because they don't want to send the client
cert over the wire in the clear" <snip>

For what reason would you require a client cert or a host name or a host
certificate to be not treated as public information?  Of course it could be
a good way to cover your tracks if you were up to no good :-)

Mick Gray
IBM

> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls