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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 21 October 2016 08:55 UTC

Return-Path: <ilariliusvaara@welho.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 C567E129511 for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 01:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
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 32o3hhvAt1zy for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 01:55:13 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9774A129543 for <tls@ietf.org>; Fri, 21 Oct 2016 01:55:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5105F13844; Fri, 21 Oct 2016 11:55:11 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id s0Vti52SvvQQ; Fri, 21 Oct 2016 11:55:11 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EDB502310; Fri, 21 Oct 2016 11:55:10 +0300 (EEST)
Date: Fri, 21 Oct 2016 11:55:02 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161021085502.GA7878@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WBPEpzWWTC-uBG5SfKFIdRLrI_k>
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 08:55:18 -0000

On Thu, Oct 20, 2016 at 05:33:41PM -0700, Eric Rescorla 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].

If you define "resumption" as "using PSK provisioned by NST", there is
a pretty major difference between "resumption" and "0-RTT".

The symmetry arguments are between "PSKs provisioned by NST" and
"PSKs provisioned externally", not between PSKs of any kind and 0-RTT.

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

IIRC, Martin Rex used to argue that the rule should be "would result in
the same certificate". Of course, defining the "same certificate" is
way trickier than it initially seems (runs into the same type of
philosophical problems as "Trigger's broom")...

Maybe one interpretation would be that the server can choose a
certificate that is valid for both old and new SNI... That is at least
a consistent rule (no idea about any sort of usefulness).

Or another: The certificate that would be chosen for new SNI is
also valid for old SNI (or vice versa). These rules are subtly
different.

Or saving the list of domains for the selected certificate in
the original connection and then allowing PSK with any of those.


One thing to be very careful of: What careless server that omits the
checks can cause (the checks are relatively complex and subtle, so
getting that wrong is to be expected).


-Ilari