Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

Eric Rescorla <ekr@rtfm.com> Thu, 03 December 2020 18:15 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 E4F733A0B8A for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 10:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 XTir6jFFAgeF for <tls@ietfa.amsl.com>; Thu, 3 Dec 2020 10:15:22 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 E51453A0B36 for <tls@ietf.org>; Thu, 3 Dec 2020 10:15:21 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id a1so2254106ljq.3 for <tls@ietf.org>; Thu, 03 Dec 2020 10:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LkQrZXV9GGjkgwSf3lLa3Tv208y7aK4HlQOKWYOWXKs=; b=L/IZsGxILjoZluDCc0/JSXKaSiS2y0a79KrpxZ9LO9RZr13WqE1u9XqJrjPOKVyuhN 4kyPIu6xGXoxR6i94v6Cz6ftpmnaWeo9ry7AfnFLFwzS0Wmov5cOnHs7DUDFMI7lAmVV jZnVnYpf37bUG50tjk9Zrd78ST5DWxY5yzHfRku4+lyVM5BlzCLff9qoU86Q3mfh5yEl eTmIyoCOEu/TKR/PnhCQ27ft/0EZueqFLlbXt77vX7UMUHsLPXtj1ox/tJiz2cq4aOFL 2MA0jUMdywCnRU92UyFg6XLbR5vBhV+9kjfMXoRZuaiYHPFOHvEWDvKKtJQJfGR3GSd6 jLsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LkQrZXV9GGjkgwSf3lLa3Tv208y7aK4HlQOKWYOWXKs=; b=LBGvZ88bNB4GOfw7n1pXoF+F4iipjZ4UDTuFIEYmgtl9wsLehpkUmTcesjQmLk35VM wDez+H09A+8zHg189zNo5ysBNZbft4+GtIJOGWzolbvEQTfiPzU2o2hEy7AlxZs4rhbP QSxsjksKP9oh1de7mLLQGeik6MJYBm6yW7IrK/0+84FXqgwmlhtnaukYXPQtT77BLXOA FHRZ2X+uKNvfGub3dpUS1QfJO2v0CV2r2YhUT0oiZansPIZAtKzPtkRnl0beCQPKU8aE 1SmTJaK2AFTvaslywU5Kj1Z4mMF/R6aUk12AKF+bP5VrK6u5XuQ8aKzUOOMhVl7Rzh7o 3+Fg==
X-Gm-Message-State: AOAM533I7CC5MgblS2BOaf66cBpV2GCw7t52sl1cWgLWzoWVfAZtbqhn b1SeLLhTdIJJ4m/huQJJZXza9Ih7y9Qn/GZZny8gfRul+YFZ2n6t
X-Google-Smtp-Source: ABdhPJxzb/rETg2+wjxpI/DJSMjIqbXzxMEreSNzEMSY9u9/d1lWB2tg5u0AWabWKtJ1Dy6snUOA+PKTvs0b131SWdM=
X-Received: by 2002:a2e:7d0c:: with SMTP id y12mr1809946ljc.199.1607019319914; Thu, 03 Dec 2020 10:15:19 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoATi+jFy53x5W4T6ai=xjH4VufhWaoABT5g_w=_72N8HA@mail.gmail.com> <CAOgPGoDJP8RNxjyrYWvPzvWOrkmDs9ssqFxvF1+mqtWg9BMF=w@mail.gmail.com> <24904640-192F-4557-98B6-094455D88CF5@akamai.com>
In-Reply-To: <24904640-192F-4557-98B6-094455D88CF5@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 3 Dec 2020 10:14:42 -0800
Message-ID: <CABcZeBOvCXKfu=ENLfPyutgbDem7KuXBQPrju-B9_YuogFEXBg@mail.gmail.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Joseph Salowey <joe@salowey.net>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b60d7705b59357e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ioMEA1neBoytFlghT1DGCHPzqRU>
Subject: Re: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 03 Dec 2020 18:15:24 -0000

Document: draft-vvv-tls-cross-sni-resumption-00.txt

I think we should adopt this draft. Some review comments below.

S 1.
   Section 4.2.11).  However, in the absence of additional signals, it
   discourages using a session ticket when the SNI value does not match
   ([RFC8446], Section 4.6.1), as there is normally no reason to assume
   that all servers sharing the same certificate would also share the
   same session keys.  The extension defined in this document allows the
   server to provide such a signal in-band.

"session keys" is a weird term here. Perhaps "same session cache"?


S 3.
   The server MAY send the extension if it reasonably believes that any
   server for any identity presented in its certificate would be capable
   of accepting that ticket.  The server SHOULD NOT send the extension
   otherwise, since, if the client follows the single-use ticket policy
   recommended by [RFC8446], sending the ticket results in it being no
   longer usable regardless of whether resumption has succeeded.

Would a MUST be cleaner here? "Reasonably believes" is already pretty
weak.

I think we should say you can't use this with 1.2, even though it's
kind of obvious.


 S 4.
 It seems like a cite to https://www.mitls.org/downloads/vhost_confusion.pdf
 and an explanation of any impact this mechanism has would be in order
 here.


   If a client certificate has been associated with the session, the
   client MUST use the same policy on whether to present said
   certificate to the server as if it were a new TLS session.  For
   instance, if the client would show a certificate choice prompt for
   every individual domain it connects to, it MUST show that prompt for
   the new host when performing cross-domain resumption.

This seems like it only applies with post-handshake auth, right, given
that you can't do resumption + client auth.

-Ekr




On Tue, Dec 1, 2020 at 5:49 AM Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
wrote:

> I support the draft and will review.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>