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

Victor Vasiliev <vasilvv@google.com> Mon, 24 October 2016 22:48 UTC

Return-Path: <vasilvv@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9848D129AAF for <tls@ietfa.amsl.com>; Mon, 24 Oct 2016 15:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.131
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYZk7gEJuR1n for <tls@ietfa.amsl.com>; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0241129500 for <tls@ietf.org>; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id 12so2219960qtm.3 for <tls@ietf.org>; Mon, 24 Oct 2016 15:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.200.41.135 with SMTP id 7mr17581123qts.71.1477349318518; Mon, 24 Oct 2016 15:48:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.98.134 with HTTP; Mon, 24 Oct 2016 15:48:37 -0700 (PDT)
In-Reply-To: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Mon, 24 Oct 2016 18:48:37 -0400
Message-ID: <CAAZdMac_nzAYcTUG361EXRgs4nvVFfVCc445roZZdm8uAqZTHA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a1140458a57488e053fa4313f
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ORVCB7KOQHgZ2dp8xwWN_wpr1nE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SNI and Resumption/0-RTT
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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
fetch
resources from different servers.  A particular use case I have in mind is
when
a website maintains a pool of servers, say, *.cdn.example.com, 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.

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.

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.


On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla <ekr@rtfm.com>; 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
> https://github.com/tlswg/tls13-spec/issues/720 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] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
> [1] https://github.com/tlswg/tls13-spec/commit/
> b26093b5e9143fb61f5b619d1da78c4ba54b2121
> [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>