Re: [TLS] Session resumption ticket reuse considered harmful

Nico Williams <nico@cryptonector.com> Thu, 05 March 2020 22:55 UTC

Return-Path: <nico@cryptonector.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 7F6563A0DCC for <tls@ietfa.amsl.com>; Thu, 5 Mar 2020 14:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 eJjhV624vTNP for <tls@ietfa.amsl.com>; Thu, 5 Mar 2020 14:55:05 -0800 (PST)
Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21E93A0DCA for <tls@ietf.org>; Thu, 5 Mar 2020 14:55:05 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 04B19341100; Thu, 5 Mar 2020 22:55:05 +0000 (UTC)
Received: from pdx1-sub0-mail-a85.g.dreamhost.com (100-96-42-19.trex.outbound.svc.cluster.local [100.96.42.19]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 86D3B340FAC; Thu, 5 Mar 2020 22:55:04 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a85.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 05 Mar 2020 22:55:04 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Abiding-Robust: 63ecdfb70da5463d_1583448904831_2516509901
X-MC-Loop-Signature: 1583448904831:4212393060
X-MC-Ingress-Time: 1583448904830
Received: from pdx1-sub0-mail-a85.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTP id 110FB80A5F; Thu, 5 Mar 2020 14:55:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=pOej7ZcsKL+fuS Nob8DeIp4pXVo=; b=ghrkyy6cjn/+S9NoQOx+22Mzjn4uEn2SHsUH/GjHRop4tX ww4wG+sHjUncxyrDDhJ1X/J2VFB9Q/F+VRdk0rjQKs/TbTpn+bDSbi/fXc32y6ga rbGyV9Zcp2oDsdFNfUGF+q4uj+diTEEi4GPLu6RbRhX+1PLvd6BpTXFUTEsFc=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 6035980A4F; Thu, 5 Mar 2020 14:54:58 -0800 (PST)
Date: Thu, 05 Mar 2020 16:54:55 -0600
X-DH-BACKEND: pdx1-sub0-mail-a85
From: Nico Williams <nico@cryptonector.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: tls@ietf.org
Message-ID: <20200305225454.GT18021@localhost>
References: <20200305205524.GR18021@localhost> <78240ee1-20ea-45b2-bd0e-e967077c509e@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <78240ee1-20ea-45b2-bd0e-e967077c509e@www.fastmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudduuddgtddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3FfL8E-aaToLlRXc8Ob4txNG4KY>
Subject: Re: [TLS] Session resumption ticket reuse considered harmful
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, 05 Mar 2020 22:55:08 -0000

On Fri, Mar 06, 2020 at 08:35:07AM +1100, Martin Thomson wrote:
> On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> > .... unless both parties agree.  It takes two to agree.
> 
> RFC 8446 says:
>    Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
>    a ticket allows passive observers to correlate different connections.
> 
> Are you arguing that there are exceptions that justify not respecting
> the "SHOULD NOT", or that the "SHOULD NOT" is too strong?  Because no
> one is violating any specifications when they reuse tickets, just
> recommendations.

Good question.

RFC2119 is very clear about what "SHOULD NOT" means, and that is
different from "MUST NOT":

   4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
      there may exist valid reasons in particular circumstances when the
      particular behavior is acceptable or even useful, but the full
      implications should be understood and the case carefully weighed
      before implementing any behavior described with this label.


> (In other words, I don't understand the strength and vehemence of the
> arguments being used.)

Well, suppose the RFC said PFS is a SHOULD, not a MUST, but we became
certain that PFS should be REQUIRED (same as MUST).  We could start
rejecting proposals that preclude that change to the RFC, and we could
go update the RFC.

If we liken ticket non-reuse to PFS, then the vehemence of opposition
we're seeing to any ticket reuse makes sense even though RFC8446 says
"SHOULD NOT" reuse tickets rather than "MUST NOT".

It is fair to boil this down to just a question of how strongly we do /
should feel about ticket reuse.

It would not be fair to exclude SMTP as an application from
consideration of whether ticket reuse ever makes sense.  SMTP does not
use early data, and SMTP between MTAs does not present the kind of
client tracking concerns that HTTP user-agents do.  SMTP is precisely
the sort of "particular circumstance" that RFC2119's description of
"SHOULD NOT" is about.

Nico
--