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

Martin Thomson <martin.thomson@gmail.com> Fri, 21 October 2016 01:38 UTC

Return-Path: <martin.thomson@gmail.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 075AA12948D for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 18:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YBrR6r_3sbkp for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 18:38:31 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 C06AC129488 for <tls@ietf.org>; Thu, 20 Oct 2016 18:38:30 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id n189so126726456qke.0 for <tls@ietf.org>; Thu, 20 Oct 2016 18:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jv94MB5NYyBYdgkwWo91wtQhspoTS10C7497UxD9N/s=; b=QaS88+oBTO2j0YFkrOSI4CkxXTc83QpkKnQYyYdn0Cuqv3W4TUBjqm4lUWR4gcpWA6 OO1+8YPcJ03xjSeKxRX+2kzO95VP7ADr5IRhtp5I7XVE4gzkoqK+gp/4q4nBCCV7/GF6 0Q2N8xknZfQux/e/SW4k1TXZ4Tw/BjJq6gtTMtDN2sYnF0zZjO4o5hNmyr0DQlIY8HRf rZIqcemH9k0QYqovZ5TZkERcpADcO2LY8Z698Xjup1aIWfbyUY+1OuVbIyrKYxj53FJG W4OngyyiZ5fyqgXblOcCc9vYXcKQqB0057bPCPRqm3DU5T4D3rv/zlfrWHreUCyIEe1B 7ibg==
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:content-transfer-encoding; bh=jv94MB5NYyBYdgkwWo91wtQhspoTS10C7497UxD9N/s=; b=RvIBR8Elpl0zCzr/URCY6PQrs6EwasSIpWFZ/2ZmMB5FnxBRxTmxUORdZScLmaHXo6 JANs35qeHc/c/EPiK88dtYPg4BttdZPwhIr4FYW0a8Pkec9QA8LI2QITOJKLDBefolBh rRdo0oq5LR1UVGVpXFGuijup3SomDNpI6Cz6Zph/ZWPIe4CNaJ/m0JbUQ7TX+XxmeJZ8 pAS3Nc/B4625l931FNO1zEqEYXA5pIbCSwDTZMqyb71zTlqW0pLM3lNra2twxPxxuvw2 npDwsYOKZMo7eDB+g3y/+LYDCsVKd54ZC49LYy30Hk8gVRWVJ9Vxbmhqm7EeQiiToGJ1 xQQA==
X-Gm-Message-State: ABUngveTBHnOWsXp7Mj0nbx2O4ZWY6HAa0BDhB+GWo/l52Hb6IH2ZmPVkQrLrg5nCUPBrK4IwSZPI8tV4INOsg==
X-Received: by 10.55.165.16 with SMTP id o16mr3690737qke.5.1477013909849; Thu, 20 Oct 2016 18:38:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Thu, 20 Oct 2016 18:38:29 -0700 (PDT)
In-Reply-To: <CABcZeBMWR7apyb9zMsdOJgrWrdjs7-uKe7hzCgZ97o_VUzSH0w@mail.gmail.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> <CABcZeBMWR7apyb9zMsdOJgrWrdjs7-uKe7hzCgZ97o_VUzSH0w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 21 Oct 2016 12:38:29 +1100
Message-ID: <CABkgnnUv8d6A47+woqwcvc99fNjXohwsV7kxB=GJyVyqU+Nuyg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yZ51jGr6AyNZE5q7Q3Dd48W805M>
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:38:33 -0000

So I think that the problem could be reduced in complexity.  A little
at least.  The obvious consequence of changing SNI is that you end up
somewhere different than last time.  But we can still ensure that the
connection is to the same peer.

If the server remembered which certificate it used, and insisted that
THAT remain constant, then you could take a different SNI from - for
example - a subjectAltName.  Provided that the routing works out, you
might still get the same certificate.

I mean, the point of SNI is to route to the right configuration.
Changing name messes with resumption in that you want to make sure
that you end up in a place that has the resumption secret.  But if you
end up at the wrong server, you either fail to resume, or fail to
connect on the normal terms of the protocol.

The only thing that could screw this all up is if we end up in a
situation where one or other peer is confused about either its own
identity, the identity of its peer, or the identity (-ies) that it
believes it peer has for itself.  However, with certificate stability
rather than name stability I don't think we are worse off than with -
say - a wildcard cert.

I agree that the add-a-name stuff makes this harder.  A co-tenanted
server with resumption keys across a bunch of names risks confusing
itself if it allows resumption across certificates, depending on how
much state it carries from the old session.  In doing add-a-name, then
we need to be careful about that, but that's a problem for those of us
who want to do add-a-name.

On 21 October 2016 at 12:06, Eric Rescorla <ekr@rtfm.com>; wrote:
> 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
>>
>>
>>
>>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>