Re: [TLS] Renegotiation with SNI after initial connection without SNI (was Questions about TLS Server Name Indication extension)

Michael D'Errico <> Fri, 30 October 2009 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66F883A6841 for <>; Fri, 30 Oct 2009 11:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 36lPyLC3O20M for <>; Fri, 30 Oct 2009 11:29:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E6033A6808 for <>; Fri, 30 Oct 2009 11:29:23 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id E57A28CABE for <>; Fri, 30 Oct 2009 14:29:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; 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;; 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 (unknown []) by (Postfix) with ESMTP id E1EB88CABD for <>; Fri, 30 Oct 2009 14:29:39 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9807E8CABC for <>; Fri, 30 Oct 2009 14:29:35 -0400 (EDT)
Message-ID: <>
Date: Fri, 30 Oct 2009 11:31:05 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2F5D96AA-C582-11DE-87CF-A67CBBB5EC2E-38729857!
Subject: Re: [TLS] Renegotiation with SNI after initial connection without SNI (was Questions about TLS Server Name Indication extension)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.


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