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

Eric Rescorla <ekr@rtfm.com> Fri, 21 October 2016 01:07 UTC

Return-Path: <ekr@rtfm.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 B6DA0127735 for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 18:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 7JjGlaBt7Q8u for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 18:07:26 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 89DDD124281 for <tls@ietf.org>; Thu, 20 Oct 2016 18:07:26 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id w3so77301012ywg.1 for <tls@ietf.org>; Thu, 20 Oct 2016 18:07:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/mOSof61XMfu5yOnWNGXwRqbkv9NvN/F5v0UE3t+gJs=; b=Yc7sa/VXDVCtYCS2KSkHWa0SGfLp3E4lsdLoWGBpyrP8ZUCgo/J7QNGdeGh3m4SMn4 tSdH7yIryAjwHKcT/S7KmamSrKZ+EuYlG1Kp4TIOfM8tcmCl+SL0hplreXsCPqrLObJA KlKenBnGYefOk1SUd41Bpd+RCGTbwojI0F4pFyCHPXqsxy6XS0TOjONy1DvgPW//41gw tDrrdbb1gC7eMxvALFzvFvj7tNFkgBGvslX6kFocZaANDS6+AKHDQsH1EgU/+Nw5Taqs Md9T4I/82MRyMRGrEJP+Y3cYHsakkx4sCb4Br0758wO9hajNvx7EurkYiX7db6lS+MHx oEbQ==
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=/mOSof61XMfu5yOnWNGXwRqbkv9NvN/F5v0UE3t+gJs=; b=EHrKrorOJvJrwUsG7AUoCwA58BBmm6iEbO1K3Gehd9mArkUY3jLC5Nuov6LCyKCaiU 8Q9qPMoeG+Sku846nXfeyzE2sseVBwrykvjTwJPyVBKq37g1TVTdvF5Ez1z93oAUd2yo kmk0dsxnr/h/Ta74phGUzG1beXE7l34pr/539h6gx7tdfmud1EPqtKFicgIDtjxwZGeK BavAPiXkXK/rEEAu6vJvF6iJy89TmkUjgltWW3CYgTc1qDIq/k1DwgkrEuw1NH3q8vxe hfhfBvwryzaFb01AwZ5hhjQBifDV3ceiMmPYSxYeZfAkQ4L4Pt9AqhinES9tz4jP6KfZ 0LLQ==
X-Gm-Message-State: AA6/9Rl2e9X5bcstG57a/ltzLm9AadxBV33lOqj7wHvdI52c1hOGHaeIgi2Yeh/6qomTsPZvWwKFjqsasEAeFQ==
X-Received: by 10.129.53.206 with SMTP id c197mr4488693ywa.205.1477012045556; Thu, 20 Oct 2016 18:07:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 18:06:45 -0700 (PDT)
In-Reply-To: <BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com> <BY1PR0301MB08382DA7C63232F9DD074D548CD40@BY1PR0301MB0838.namprd03.prod.outlook.com> <CABcZeBO2j+E6MOBQJgpRAcMsLj_72cU-W1q783D9ubZLEPBt=A@mail.gmail.com> <BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 20 Oct 2016 18:06:45 -0700
Message-ID: <CABcZeBMWR7apyb9zMsdOJgrWrdjs7-uKe7hzCgZ97o_VUzSH0w@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=001a11421a264e204b053f55aac8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xxMJCNTbOXTCHC1oNfpnyPw7uGA>
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: Fri, 21 Oct 2016 01:07:29 -0000

Yeah, it does seem a bit complicated.... :)

-Ekr


On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov <Andrei.Popov@microsoft.com>;
wrote:

> Perhaps it’s OK to resume a session with a different SNI if in this
> session the server has proved an identity that matches the new SNI.
>
> In order to enforce this, the server would have to cache (or save in the
> ticket) a list of identities it presented in each resumable session…
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Thursday, October 20, 2016 5:47 PM
> *To:* Andrei Popov <Andrei.Popov@microsoft.com>;
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] SNI and Resumption/0-RTT
>
>
>
>
>
>
>
> On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <Andrei.Popov@microsoft.com>;
> wrote:
>
> Ø  With that said, it does seem like there might be situations where it
>
> Ø  would be useful to allow resumption/0-RTT with different SNIs.
>
> What are some example situations where resumption with a different SNI is
> useful
>
>
>
> A system where you have a bunch of co-tenanted names and you'd like to get
> 0-RTT on
>
> SNI A after negotiating with SNI B. Basically the same conceptual
> situation as Mike Bishops
>
> add-a-server-cert draft.
>
>
>
> With that said, I'm more than happy to stuff this in the "TODO-for-later"
> list.
>
>
>
> -Ekr
>
>
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 20, 2016 5:34 PM
> *To:* tls@ietf.org
> *Subject:* [TLS] SNI and Resumption/0-RTT
>
>
>
> 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
>
>
>
>
>