Re: [TLS] Renegotiation with SNI after initial connection without SNI (was Questions about TLS Server Name Indication extension)
Michael D'Errico <mike-list@pobox.com> Fri, 30 October 2009 18:29 UTC
Return-Path: <mike-list@pobox.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 66F883A6841 for <tls@core3.amsl.com>; Fri, 30 Oct 2009 11:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level:
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 36lPyLC3O20M for <tls@core3.amsl.com>; Fri, 30 Oct 2009 11:29:23 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 2E6033A6808 for <tls@ietf.org>; Fri, 30 Oct 2009 11:29:23 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E57A28CABE for <tls@ietf.org>; Fri, 30 Oct 2009 14:29:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=tgj7jPvNOka2 KRlTaz3mV+FacRs=; b=NMbg+IcyTJSM/MqB4s611G7djAtj/YyI1TP9b20Hc6bJ qSUEwNAocZiH1TyvAavARXRH1kwTDuWnvnXdybjfZ1r8Tn3zxbDUWdp8ftco7VSr PMy5aGXGkuF5I1hZatMUmpwzs/Po466vLqW+GzsgCoeCtJolnQo5SpVMDWzduhY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KwGp3+ MQ1fDqO9ZOiD820B42nJ/G3a7TXdQvbb97iZgQkT9tPFdfHWdPOtP35HRF2LgFGl WGhM2P0XnmTPA71wAIkOFSruh3xILPpWqYyNOM0q+FZHwJGa2csN+SLMeTaLgNXB L/DNtA2gEP6D44NWtU66kPEtoGHEMo2vLARxs=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E1EB88CABD for <tls@ietf.org>; Fri, 30 Oct 2009 14:29:39 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9807E8CABC for <tls@ietf.org>; Fri, 30 Oct 2009 14:29:35 -0400 (EDT)
Message-ID: <4AEB30E9.8080603@pobox.com>
Date: Fri, 30 Oct 2009 11:31:05 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <E1N32Q4-00072H-J3@wintermute01.cs.auckland.ac.nz> <4AE880CA.3060902@bolyard.me>
In-Reply-To: <4AE880CA.3060902@bolyard.me>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2F5D96AA-C582-11DE-87CF-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] Renegotiation with SNI after initial connection without SNI (was 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 18:29:24 -0000
The desire seems to be to have a way to first negotiate a secure channel to a machine, then to perform the intended handshake over this secure channel to keep the real handshake private. This could be done by adding a new NameType to the SNI extension. This new NameType would let the server know that it is performing a handshake merely to create a private channel over a public medium like the Internet. Immediately following the negotiation of this secure connection, the client would be required to perform the intended handshake. Note that the session ID specified by the client in the 2nd handshake would be empty. The "name" associated with this name type would most likely be empty (two zero bytes indicating zero length) since it means "the host I'm connected to". Both handshakes could return non-empty session IDs. Upon resuming the first session, the client would be at the point where it needed to renegotiate the session using a valid SNI and empty session ID. Resuming the second session would get them all the way to the virtual host. There are obvious security issues -- a client would need to make sure that the host it connected to was friendly so when it performs the real handshake, the information doesn't end up in the wrong hands. Or perhaps the security offered is similar to the use of TLS for SMTP where clients don't necessarily care who the server is, just that their message is encrypted when sent over the Internet; they rely on the DNS to make sure they're connected to a real MX for the recipient. Mike >>> 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.
- [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