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

Victor Vasiliev <> Mon, 24 October 2016 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9848D129AAF for <>; Mon, 24 Oct 2016 15:48:41 -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 AYZk7gEJuR1n for <>; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0241129500 for <>; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
Received: by with SMTP id 12so2219960qtm.3 for <>; Mon, 24 Oct 2016 15:48:39 -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=9I2CpS3BkUw8FOei0lnyjYTSqoKJvZ+3ejzqgEGJhJg=; b=pITyCbJNBjd2ShbDLGMwbaKU1Bh9+uIpCUwm+YpDqrZZjYeMFDIQcqhmfqgFNwPfSe DjBmo7QuwQ+ofaEUvZy9udC1b3gSxp+ct7J43MqSQp823teEaBE27CBRdzIWsVy0ovx3 SXZCufsyRGaMLttuAb48z4XKMRojvLIIRBODTGBmvSWqqc2xkaI3SagK0Np3N3sDPVKC QKcVotFgGKvOGA23MQ8IMrzIKZXJzyE1P0wfi0SPYnJ0L51GgrKuydrEyeJNGB3UgVMK 5k0zItg8T0S02JgV1O9D4RMDjhDg0YEs6qJF1HYE7gFCcL4USgJT8j5LvsVkqq0HNQxG Wf/w==
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=9I2CpS3BkUw8FOei0lnyjYTSqoKJvZ+3ejzqgEGJhJg=; b=OpJ4sm+YraD2liArZmNyht+/ptT+7O1HlNezFt5XAfFXMIMEC4FlIYWfpa0ezJxtX+ BJmUEDgYJJkNK06QOLg8v69dhwwiEzdJ34wq7II15KoCR0qnZs6yhSYDcJhT8IeOxUGc FLNRW7sdEuhsf39R8IlrMTQiG/6n18EZ6hTQ8zGXUNEZYKqGBrLOrmmXDa1ZORJ+FL9m tbVWxUQYJ8qMX/na7BrOKCyp/bkO1zC8GgEpWIvPXqjJxMWsmenE3gxGkDhewEaA4FDj lYR4IrtMNmibgdth0QxMxrto6VE0itT+kE97VEhWpK0Rfq0OpnhTpQWYZUUEjjjo1Xn/ OjEA==
X-Gm-Message-State: ABUngvf5ZD10VtufmN0Vhvjt88Cyc2eTdewtLZcgRloBLs9ZFSGoT47KvHdAu7cuMfx0HzqjvYxICfz4vVfzZKFy
X-Received: by with SMTP id 7mr17581123qts.71.1477349318518; Mon, 24 Oct 2016 15:48:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 24 Oct 2016 15:48:37 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Victor Vasiliev <>
Date: Mon, 24 Oct 2016 18:48:37 -0400
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary=001a1140458a57488e053fa4313f
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: Mon, 24 Oct 2016 22:48:41 -0000

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
resources from different servers.  A particular use case I have in mind is
a website maintains a pool of servers, say, *, and supplies
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
key too, meaning it makes sense for them to accept the ticket issued by
server in the pool.

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
how to handle SNI value change.  I suggest that the servers should
indicate to the client that a newly issued ticket may be used for all the
subjectAltName values present in the server's certificate.

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
say, a client which uses different cipher configuration or a different set
trust anchors for each host.  In all of those cases, it is on the client to
cross-resume, but a lot of those concerns are application-specific in
so I am not sure how much guidance can the TLS specification provide on this

On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla <>; wrote:

> We used to explicitly say that you had to check SNI for 0-RTT (but
> didn't say anything about resumption). On the principle that 0-RTT and
> resumption should be the same I removed that, but it turns out that
> the document doesn't actually have any rule at all other than the one
> we've inherited from RFC 6066, which clearly says that you can't
> resume with a different SNI [0].
> Following the discussion in
> I've added a statement
> to the draft clarifying that the RFC 6066 rule still applies [1]
> With that said, it does seem like there might be situations where it
> would be useful to allow resumption/0-RTT with different SNIs. My
> intuition (partly informed by [2]) is that this is something we should
> be pretty careful about and have the server opt-in explicitly (if at
> all) but I'm willing to be wrong about that.
> Comments?
> -Ekr
> [0]
> [1]
> b26093b5e9143fb61f5b619d1da78c4ba54b2121
> [2]
> _______________________________________________
> TLS mailing list