Re: [TLS] SNI and Resumption/0-RTT

Victor Vasiliev <> Wed, 26 October 2016 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F6B01295B5 for <>; Wed, 26 Oct 2016 11:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MhgWtTHJqM3L for <>; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A328D129426 for <>; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
Received: by with SMTP id n189so13641809qke.0 for <>; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T20ihYTMIHv+GIXvkeKe3kA/TR92lXh6E8iKcnMQXuk=; b=YAbq6JSJPpeDH8O4zS2PoNV1wc+iHSeAmDeb5Fsx3z1jDU3ACe/6VMZ8z081bUvyRW 9XELUs/rfNezJPwlcEw1XjRoGX2W5LGjNwnm7vw0mUM0lN/g6Tj2V+Pq1bglJKl3o1Va /Yn0Zac8qQaqn0RxCl2jgy2tHKEhonbotQxCkW9q0MAvlh4nnxC/SOzyOjyZeH4Rr5dw 0516Hp6k7AhlBlbpkj5N5AbanHXduB2/Mn/F7LAQtfDWttyzEGE7VXE2j16TeDWM3DF4 Gkch3sPzUFZeAIJiI20kTCRVdrJ4BMdzt5PNCt75/04Gmbsg3tcDX6Hh/g69qa9nAG4u hQpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T20ihYTMIHv+GIXvkeKe3kA/TR92lXh6E8iKcnMQXuk=; b=lRoqwlaMNSY0hnYeTBLgqu1pm5WsAkRyOy2bBaby2lY3p14Q0UHG90jDy8qwt5q8/+ mya6QSxqp1kJMUF6RfqmGgXpTlhYbzLsviwK0lgepQtlm1h1rKWf218VxgPkwIz3RM0T e28Kynb64Zm+a1WxrebB1vvFejrFN0HnQs8n2F4DRMCGBD/08lcVrWlZCZ81xljGVAzj J/8tnhYXPWSHhUBsmohQcHIocgdskQ1amanGm93Ifm8O6r/LJfgp7BWdVm62zAmrOXP9 6L3DuRTnEsZio6nGaj58o26kYgR373+WbQZ4DnINzA/LfyLiyq0fnGiUTzfrwTUw8lnI 3shg==
X-Gm-Message-State: ABUngveBQpGmOtAZNb97SZtvYzcjkk+BlxhWznG/gWRwo8btt+ki26kcBD0suLxzNz0gBEAZyB2jtpIimiPEGu3Z
X-Received: by with SMTP id i62mr2545897qkh.238.1477505467588; Wed, 26 Oct 2016 11:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Oct 2016 11:11:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Victor Vasiliev <>
Date: Wed, 26 Oct 2016 14:11:06 -0400
Message-ID: <>
To: Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary=001a1147a0528d20df053fc88ced
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-Mailman-Version: 2.1.17
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: Wed, 26 Oct 2016 18:11:11 -0000

On Wed, Oct 26, 2016 at 1:41 PM, Benjamin Kaduk <>; wrote:

> Picking a message somewhat at random to reply to with some more-general
> observations...
> On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
> I believe that an ability to resume across different server_name values
> specified in the subjectAltName of a certificate will have a positive
> performance impact on the websites which due to various reasons have to
> fetch
> resources from different servers.  A particular use case I have in mind is
> when
> a website maintains a pool of servers, say, *
> <>;,
> and supplies a
> specific server directly in a resource URL.  In that case, all the servers
> already share a wildcard certificate with a secret, so they can share a
> ticket
> key too, meaning it makes sense for them to accept the ticket issued by
> another
> server in the pool.
> I think it is useful to distinguish between this case, where [cdn.]
> is the owner of all the content involved, from other
> co-tenanted names that have different content owners, such as from a shared
> hosting service.  The wildcard cert is pretty clearly in the "same content
> owner" case, but even subjectAltNames in a single cert do not necessarily
> provide the same indication -- I understand that some CDNs offer a
> lower-cost TLS option by means of being a SAN on a cert that shares names
> with many different CDN customers.
> So, even the server's configuration settings may change as a result of SNI
> (e.g., a hosting provider may let customers configure settings differently
> even when served from the same TLS server).
> There are potential confusion issues associated with using a ticket for a
> different server name, both with the server becoming confused and the
> client
> becoming confused.  On the server side, this requires implementations to
> know
> how to handle SNI value change.  I suggest that the servers should
> explicitly
> indicate to the client that a newly issued ticket may be used for all the
> subjectAltName values present in the server's certificate.
> I would argue that changing SNI value on resumption or 0RTT only has a
> hope of making sense in the "same content owner" case ... but the client
> may not have an easy way of knowing, in the absence of an explicit server
> signal as you propose.
I agree with your points, hence I have suggested explicit signal.  This is
more of a performance issue than a security issue, since resumption by
requires the server to have access to the resumption key.

> Clients must also account for any per-host differences before offering a
> ticket.  For instance, web browsers typically require users to pick a
> certificate for each domain they authenticate to, so resumption across
> different SNI values should obviously not happen here.  One can also
> imagine,
> say, a client which uses different cipher configuration or a different set
> of
> trust anchors for each host.  In all of those cases, it is on the client
> to not
> cross-resume, but a lot of those concerns are application-specific in
> nature,
> so I am not sure how much guidance can the TLS specification provide on
> this
> matter.
> Things are getting messy enough that I'm starting to lean towards just not
> doing it at all (perhaps with the carve-out for future behavior that
> Chrstian wants, if we can satisfy ourselves that it won't ossify).
Web browsers already have to implement all of those policy filters for
connection pooling, so I do not expect this to be that much of a burden to
implement.  Since the client can always choose to not send a ticket, it can
always decide to not resume across multiple domains in order to simplify the

  -- Victor.