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

Eric Rescorla <ekr@rtfm.com> Fri, 21 October 2016 00:47 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 AD5091294BB for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 17:47:47 -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 cb_xkbWLEE1h for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 17:47:45 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 B90D91294C8 for <tls@ietf.org>; Thu, 20 Oct 2016 17:47:45 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id t193so77622144ywc.2 for <tls@ietf.org>; Thu, 20 Oct 2016 17:47:45 -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=zQeQyk82aVTLBnon+vdFgEOjdS0SlrSmBepvhRgH54E=; b=XTn2ZqjzygCNqNJxwsWdVQf1EZWaBLqlM/mnYleXELpHFvR/XwfcIR9crcPbIwhpHx lYq0erNQ7rAW5eg9r9s1aJARK9Cty6zgbFd0Jh2dimMutXRoZg7OAxRXUhuORe5rAjxk fpCrVs/f731UtUnXw2MzP0+nCWFbLhd0lCSF7Viu6vSw/04Fs2aj/MNmZi0prRfPZLIE YINjobud3D05AfCVxvloq0n48K/u8yjrAVwFrrYbZMmYUOg7JTNX3UNQXgluFu0xC6gx ECkSKgUjO55DuPEtaWpcPE09r4UzgpDy4WV1H1jYIu7JRXCW//JexGoZ1E615DwBbmvs QLEQ==
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=zQeQyk82aVTLBnon+vdFgEOjdS0SlrSmBepvhRgH54E=; b=KR40M2EqVEwl8vB3LDoRzEVF5mNiMbM6QCSckLRfNoGNREQuXlmYe4/uVKTZVnfzWW PlsJDQz6Owx3ZROkCw4TmE/HBGhRRH4BH4GorR1G/DmWQG47DgqEAxUH9WTtNVK6+HvK zMEhp5yCRVFVJEWuiCDzNWuq2h8dsKjNhPuTbMZ4jIaycZ0VsiNnjUZyI260yoY8a5Q5 uA3q9NQ/cf0ZGz0dEXNMGzYRHiri/43zWn75qj4BzATuVoesIBzmSiniobe0zNkjUCGd dJpO31fzybiRflHuay4bgStKn6Eu+BZyx3iDSDFZcru1H3lP0DmwjLgkGHAoLlpgr7y6 cJww==
X-Gm-Message-State: AA6/9RlbmqMNSC47LTciiYGNW9mlaMVYjaknORvsl56wLZl5Stn9yzi+7pIoYzpieCmxXC7MG25DyD6udW4Kaw==
X-Received: by 10.129.81.21 with SMTP id f21mr4494276ywb.149.1477010864931; Thu, 20 Oct 2016 17:47:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.82.210 with HTTP; Thu, 20 Oct 2016 17:47:04 -0700 (PDT)
In-Reply-To: <BY1PR0301MB08382DA7C63232F9DD074D548CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com> <BY1PR0301MB08382DA7C63232F9DD074D548CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 20 Oct 2016 17:47:04 -0700
Message-ID: <CABcZeBO2j+E6MOBQJgpRAcMsLj_72cU-W1q783D9ubZLEPBt=A@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary=001a11461104ef5bdf053f556316
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fS5z0mukPpi2fBQ7_9RgrLF2eFo>
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 00:47:48 -0000

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
>
>
>