Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Nico Williams <nico@cryptonector.com> Thu, 23 January 2020 00: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 CEA2912010E for <tls@ietfa.amsl.com>; Wed, 22 Jan 2020 16:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 7NY61UYlGEru for <tls@ietfa.amsl.com>; Wed, 22 Jan 2020 16:55:57 -0800 (PST)
Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (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 E5DBE12004E for <tls@ietf.org>; Wed, 22 Jan 2020 16:55:56 -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 2FBC48C1A1B; Thu, 23 Jan 2020 00:55:56 +0000 (UTC)
Received: from pdx1-sub0-mail-a13.g.dreamhost.com (100-96-89-22.trex.outbound.svc.cluster.local [100.96.89.22]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B264D8C1BB1; Thu, 23 Jan 2020 00:55:55 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a13.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, 23 Jan 2020 00:55:56 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Wipe-Inform: 4c73a1683689753b_1579740955975_484427585
X-MC-Loop-Signature: 1579740955975:1975952418
X-MC-Ingress-Time: 1579740955974
Received: from pdx1-sub0-mail-a13.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a13.g.dreamhost.com (Postfix) with ESMTP id C6816816CA; Wed, 22 Jan 2020 16:55:53 -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=xOsoHN1hgLFA5a TqvMS8vfcUz2U=; b=fc22TVVXIfrcYbOmDVy0Dg2wwOd5d2x8/VBvm8fb63x+jd YA38VdYXJ54mgM4YfGQO9UDtIF5Wmb0UzKsbDa0oZpYRVWXp8cge5f1KDIXwCYTP v2Qs2KelGHMvmqdjX5ojtz2O0r9r/LO9Zow3vNNB47ziRMFGCeign8ni1PQBc=
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-a13.g.dreamhost.com (Postfix) with ESMTPSA id 2F279816C6; Wed, 22 Jan 2020 16:55:51 -0800 (PST)
Date: Wed, 22 Jan 2020 18:55:49 -0600
X-DH-BACKEND: pdx1-sub0-mail-a13
From: Nico Williams <nico@cryptonector.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Martin Thomson <mt@lowentropy.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20200123005528.GA12073@localhost>
References: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com> <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com> <20200121055411.GJ73491@straasha.imrryr.org> <97de6364-c628-45aa-8613-ba1a32cc41b2@www.fastmail.com> <A5448AC9-6EBB-48F9-A1B0-A787FBBCFF05@akamai.com> <08A4B0CD-9903-4027-B672-E8C7AFB34B4D@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08A4B0CD-9903-4027-B672-E8C7AFB34B4D@akamai.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrvddugddvhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9ki7NP9it_UbdD9fJDf_QXDqzz8>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
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, 23 Jan 2020 00:55:59 -0000

On Tue, Jan 21, 2020 at 06:19:23PM +0000, Salz, Rich wrote:
> Viktor and I spoke in more detail.  The use-case he brings up makes
> more sense to me now. The key observation is that this is not about a

I also spoke to Viktor, and he explained the motivation in detail.  He
really should have done so on the list, but it is this:

    TL;DR: Postfix multi-process ticket cache DB thrashing pain.

 - Postfix (which he co-maintains) is a multi-process service (with
   client and server functionality -- it's an MTA, after all)

 - Postfix needs a multi-process ticket cache w/ concurrency

 - OpenSSL provices no such thing, only a single process in-memory
   cache, and also callbacks the app can use to implement its own cache,
   which then Postfix uses to implement a multi-process ticket cache

 - So, getting unnecessary tickets thrashes Postfix's shared cache,
   which costs a fair bit due to synchronization


There are two ways to make this tolerable for Postfix:

 - either the TLS server says "here's a ticket and you MUST or MAY
   replace the one you already had"

   or

 - the TLS client gets to ask for no unnecessary new tickets

Now the first alternative would be infeasible to adopt because it would
require new OpenSSL callback APIs, and anyways would be a more invasive
change to TLS than the ticketrequest extension makes.

That's why Viktor would prefer the other way: let the client ask for no
unnecessary new tickets.  This has the benefit of saving some bandwidth
and server cycles.

Now, as to the privacy issue.  The server can simply always issue a new
ticket, even if the client didn't want it -- presumably MTAs wouldn't,
but HTTP servers would.  And there is no way for -say- a great firewall
to force you to not get new tickets as the server can still always hand
the client one, and anyways, this extension can be (should be!)
encrypted, so the firewall can't know anyways.  All a great firewall
gets to see is that your connections can or can't be linked.  Especially
given Viktor's use case, we can assume (and require, evven) that only
SMTP MTAs might request no new unnecessary tickets, so that great
firewalls really can make no assumptions about this in HTTP use cases,
say.

> "client" in the conventional (or browser) sense, but rather more like
> a peer-to-peer kind of thing, where the client is just the one who
> initiates a connection and might be multiple processes running on
> multiple instances sharing an identity.
> 
> I'm in favor of his suggestion.

Me too.

It's really very simple.  There is no legitimate "unnecessarily complex"
argument; such arguments come across as unnecessarily dismissive.

There is a privacy non-issue, addressed as above, though it's fair to
demand that it be addressed.

Regarding the "define your own extension" responses...  That's fine, I
suppose, but why ever bother with WGLCs for these if changes that
benefit others will generally be rejected out of hand?  Why require TLS
WG review of extensions?  Why not just make an Expert Review registry?
I think the answer to the last question is that we're not ready for that
-- we want some WG review, and, presumably, we want some commonality.
So, unless we're going to go with Expert Review only, then please do not
make this "define your own" argument -- it's at the very least impolite.

Nico

PS: Viktor tells me that hey, I've advised him to keep posts pithy, thus
    he elided all the above explanation, but really, IMO, he should have
    explained in detail.