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

Nico Williams <nico@cryptonector.com> Sun, 02 February 2020 19:05 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 44ADF120125 for <tls@ietfa.amsl.com>; Sun, 2 Feb 2020 11:05:00 -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 SrCZysC6GBJ1 for <tls@ietfa.amsl.com>; Sun, 2 Feb 2020 11:04:58 -0800 (PST)
Received: from crocodile.birch.relay.mailchannels.net (crocodile.birch.relay.mailchannels.net [23.83.209.45]) (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 6C8521200B1 for <tls@ietf.org>; Sun, 2 Feb 2020 11:04:58 -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 B307121B0B; Sun, 2 Feb 2020 19:04:57 +0000 (UTC)
Received: from pdx1-sub0-mail-a94.g.dreamhost.com (100-96-217-4.trex.outbound.svc.cluster.local [100.96.217.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 38C1321019; Sun, 2 Feb 2020 19:04:57 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a94.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); Sun, 02 Feb 2020 19:04:57 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Tangy-Squirrel: 6d66dae10c5545b6_1580670297468_1797400246
X-MC-Loop-Signature: 1580670297468:3827458789
X-MC-Ingress-Time: 1580670297468
Received: from pdx1-sub0-mail-a94.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a94.g.dreamhost.com (Postfix) with ESMTP id 0C9DFB0D5A; Sun, 2 Feb 2020 11:04:52 -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=A5Ef1C+DO9i/XN UR+V1kdb7L2iE=; b=BIC6IGp4kl1I6/hYlLDEbNGv57rfykGqRL9IHoWWvcwT5e /HtUAgQXkNF64FOxUcuYjr+NPsCJyhaAMMEu97UnKcZjJz1Ov5jKM16ukzljH9AN jgu/ypHsKE1FKK9pyKoTcArMZ8YPcxFdYfFAbHz2fxss890yHJa9TW6K0TCig=
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-a94.g.dreamhost.com (Postfix) with ESMTPSA id 3D5CBB0D61; Sun, 2 Feb 2020 11:04:51 -0800 (PST)
Date: Sun, 02 Feb 2020 13:04:48 -0600
X-DH-BACKEND: pdx1-sub0-mail-a94
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20200202190447.GG18021@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> <CABcZeBP=BetaxVo5v-khdykP0U3P6j-e+hL307o8Wn3KC9rmhA@mail.gmail.com> <20200121224610.GR73491@straasha.imrryr.org> <CABcZeBOq+mvY4mx+VT0QB08b67noqZyvr0NE-_YMGsz5VoSDuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBOq+mvY4mx+VT0QB08b67noqZyvr0NE-_YMGsz5VoSDuA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrgeehgdduudelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BScc96c9i9SEi9HFUoEINtEN458>
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: Sun, 02 Feb 2020 19:05:00 -0000

On Sun, Feb 02, 2020 at 09:08:17AM -0800, Eric Rescorla wrote:
> I'm sorry to say that I'm not that sympathetic to this position. I
> appreciate that it's inconvenient for Postfix to have frequent writes
> to the ticket cache, but what you propose to do is hoist this
> implementation idiosyncracy into the specification, and I don't think
> that that's a good tradeoff, both for complexity and because the

We've done this a lot though, haven't we.  For example, we've striven to
avoid reconnects because SChannel can't really handle them.

So I'm not that sympathetic to not being that sympathetic to specific
implementation issues.

Nico
--