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

Victor Vasiliev <vasilvv@google.com> Wed, 26 October 2016 18:11 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 4F6B01295B5 for <tls@ietfa.amsl.com>; Wed, 26 Oct 2016 11:11:11 -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 MhgWtTHJqM3L for <tls@ietfa.amsl.com>; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 A328D129426 for <tls@ietf.org>; Wed, 26 Oct 2016 11:11:08 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id n189so13641809qke.0 for <tls@ietf.org>; Wed, 26 Oct 2016 11:11:08 -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=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; d=1e100.net; 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 10.55.23.65 with SMTP id i62mr2545897qkh.238.1477505467588; Wed, 26 Oct 2016 11:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.98.79 with HTTP; Wed, 26 Oct 2016 11:11:06 -0700 (PDT)
In-Reply-To: <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com> <CAAZdMac_nzAYcTUG361EXRgs4nvVFfVCc445roZZdm8uAqZTHA@mail.gmail.com> <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Wed, 26 Oct 2016 14:11:06 -0400
Message-ID: <CAAZdMadCLSc0QUMs4YZiDqzQMt9nBPPjxwRpeiDbCcNs5N-mEQ@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Content-Type: multipart/alternative; boundary=001a1147a0528d20df053fc88ced
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MrTXA50biSr_No5Aw_vbY_WZCvg>
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: Wed, 26 Oct 2016 18:11:11 -0000

On Wed, Oct 26, 2016 at 1:41 PM, Benjamin Kaduk <bkaduk@akamai.com>; 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, *.cdn.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cdn.example.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=t1O12kmBzZmXqHTSFe7DFW0i20d2hmZAgQxx-K8C4z4&e=>;,
> 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.]
> example.com 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
nature
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
HTTP/2
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
implementation.

  -- Victor.