Re: [TLS] SNI and tickets and resumption (Martin Rex) Fri, 08 August 2014 23:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E3D4B1A015D for <>; Fri, 8 Aug 2014 16:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Km8benh2tgIy for <>; Fri, 8 Aug 2014 16:25:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0A39B1A014E for <>; Fri, 8 Aug 2014 16:25:05 -0700 (PDT)
Received: from by (26) with ESMTP id s78NP3WI020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 01:25:03 +0200 (MEST)
In-Reply-To: <>
Date: Sat, 09 Aug 2014 01:25:03 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
X-SAP: out
Cc: Adam Langley <>, " (" <>
Subject: Re: [TLS] SNI and tickets and resumption
X-Mailman-Version: 2.1.15
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, 08 Aug 2014 23:25:08 -0000

Ooops.  Somehow the previous message wasn't what I wanted to say.

When I implemented support for TLS extension SNI (at the lower levels
or our software stack), then I implemented the "principle of least
surprise" in the following fashion:

Essentially, whenever a full handshake would result in the use of the
same server certificate as the resumption proposed by the client,
my server will perform session resumption, and ingnore SNI mismatches.


Martin Rex wrote:
> Salz, Rich <> asked:
>> Can a client connect with an SNI extension and then later on resume
>> or send a ticket with a different SNI value?
> AGL responded:
>> At Google, we share ticket keys between servers, but the servers will
>> reject a resumption if any part of the ClientHello causes a different
>> certificate to be selected than was presented on the original
>> connection.
> Salz, Rich wrote:
>> We do the same thing, but wasn't sure if it was legit. 
> The words you're using are sufficiently ambiguous to get me worried.
> Since the specification of the TLS extension "server name indication"
> is also somewhat wrong (which I only noticed when I implemented it),
> I would appreciate to get this clarified.
> On a mismatch of SNI in combination of resumption with the original SNI
> value (and I include _absent_ SNI on an initial SSLv2 CLIENT-HELLO
> in this count!), the server should behave according to the
> "Principle of least surprise", and **NOT** reject the connection
> (i.e. *NOT* abort with a fatal alert).
> If the server doesn't use SNI at all (which includes not supporting
> TLS extension SNI), then it should continue to ignore SNI on resumption.
> If the server uses SNI on initial full handshakes (those without any
> kind of resumption proposed by the client), then the server should
> perform a full TLS handshake if SNI differs from what was used for
> the session that was proposed for resumption.