Re: [TLS] Requiring SNI for resumption (was Questions about TLS Server Name Indication extension)

Michael D'Errico <> Fri, 30 October 2009 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 521413A6867 for <>; Fri, 30 Oct 2009 13:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2gYAwv1N3qaz for <>; Fri, 30 Oct 2009 13:23:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 38BA43A67BD for <>; Fri, 30 Oct 2009 13:23:52 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id D8DAC8B56A for <>; Fri, 30 Oct 2009 16:24:09 -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=GVG8wtCNx83J 7xy/qGwXaibN294=; b=vTphFiN1RmQ3OO+8ANwGbQJOlHV/5pyTkdNVtXVawnfa B088d1tZue4xMH+biKjJfLuKqbrVdSKWwW8LT1sZ3Z70a9LSYuuu5cGWCELEc6wA v6C2NWwe33OZ3VdNXsl1FHrzuUaAX2PVm6gRO4/Ql6bhYWpjnpgJNBluqfwmAQ0=
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=nM6vk/ MXBFWHa0y2X1wxMmA7x9q3rcFjUe0idgF2cjKEXw+zFSjI1CxgcW3MEFeOYMFgCj D+2DuMhsCjGc2p8X6yAGUrkdvxzOvdv+HcHWgQdbcqItTy8SFeZM5YtsSl7Wb79I zWmtiqQ3cAYsCnM5KcLqNUHxGp9QaAHYcY5hM=
Received: from (unknown []) by (Postfix) with ESMTP id D4EC68B569 for <>; Fri, 30 Oct 2009 16:24:09 -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 518A28B568 for <>; Fri, 30 Oct 2009 16:24:08 -0400 (EDT)
Message-ID: <>
Date: Fri, 30 Oct 2009 13:25:40 -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: 2E2CD4DE-C592-11DE-AE2D-A67CBBB5EC2E-38729857!
Subject: Re: [TLS] Requiring SNI for resumption (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 20:23:55 -0000

I think that it would be a good change to require a client to include the
same SNI extension when resuming a session.  The complexity of my code to
find a session among multiple session caches is far greater than it would
have been if I could have relied on the hostname from SNI.

RFC 4366 currently disallows using SNI to resume:

    -  If, on the other hand, the older session is resumed, then the
       server MUST ignore the extensions and send a server hello
       containing none of the extension types.  In this case, the
       functionality of these extensions negotiated during the original
       session initiation is applied to the resumed session.

I'd be in favor of changing RFC 4366 to mandate providing the same SNI when
resuming a session, if nothing will break because of it.


Nelson B Bolyard wrote:
> On 2009-10-30 08:04 PDT, Martin Rex wrote:
>> Nelson B Bolyard wrote:
>>> On 2009-10-29 16:26 PDT, Martin Rex wrote:
>>>> Nelson B Bolyard wrote:
>>>>> There's another issue that arises with both the SNI extension and a single
>>>>> session ID space for the entire physical server.  Which takes precedence?
>> If the SNI made a difference in the server credential when the session
>> was originally created, then the SNI MUST make the same difference
>> for resume.  The a requirement for consistency and reproducable behaviour.
>> If the SNI did not make a difference when the cached session was
>> originally created (e.g. the server doesn't support SNI), then it
>> does not need to make a difference on resume.
> RFC 5246 says:
>    In general, the specification of each extension type needs to
>    describe the effect of the extension both during full handshake and
>    session resumption.  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.  However, some extensions may
>    specify different behavior during session resumption.
> You're saying that SNI is not like "Most current TLS extensions" in that
> when an older session is resumed, the server DOES process this extension,
> and its behavior is NOT different during session resumption than during
> session initiation.
> I think that's a legitimate and self-consistent proposal, one of several
> that I could envision, which is why I raised this subject.  But as we've
> seen in this thread, others (e.g. IBM) clearly have implemented a very
> different model.
> For the sake of interoperability, I think we need to define a single
> standard definition to which we all adhere.
>>>>> 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,
>>>> That client is obviously broken.
>>> Perhaps, but the question is what does the server do about it?
>> Compensate for the broken client and perform a full SSL handshake.
> IBM's answer was: ignore the SNI and resume session ID 1 with host A,
> which seems to be what RFC 5246 says TLS should do for _most_ TLS hello
> extensions.  But I agree that we _could_ *define* SNI to not be like
> _most_ TLS hello extensions, if we choose.
>> A broken client is no excuse for inconsistent or non-predictable
>> server behaviour.  
> I agree that, ONCE we all agree that your definition is the right one,
> then we agree that the above behavior is that of a broken client.
> OTOH, if we end up agreeing that IBM's answer is the right one, then
> I don't think we necessarily agree that a client behaving as described above
> is necessarily broken.
> Regards,
> /Nelson
> _______________________________________________
> TLS mailing list