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

"Martin Thomson" <> Tue, 21 January 2020 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84A62120048 for <>; Mon, 20 Jan 2020 21:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=RAcjn9gR; dkim=pass (2048-bit key) header.b=ApKPDTJ5
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N5wXhS1O4jjV for <>; Mon, 20 Jan 2020 21:04:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0812F120045 for <>; Mon, 20 Jan 2020 21:04:12 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 040F121F85 for <>; Tue, 21 Jan 2020 00:04:12 -0500 (EST)
Received: from imap2 ([]) by compute1.internal (MEProxy); Tue, 21 Jan 2020 00:04:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=ntl2dFBnG2KyRBN2+l/eDqHF+BRdPC/ epio64iH9YxY=; b=RAcjn9gRqFGcSjb0fi3busl1QBVOCeiYTI2ySxQSd9bF9Dj G+aveVMiPceX3QehY/NXlEW0sO2xiIYzegwTF3ILwyahnug4fGFXl3yQePtboNOd t2FiuhUOS2A3GuijhNMiIl9+mERjSr9RaE3akDzNsjjEjI1gsQQ02Cg8HhgnGoKo OqjLVYNUlH3WXKJPCerteFTtNce1BwFlzGZkOvlLLkWCSAKTFwRN1pFtQ+LwTZt7 xbRSQNUv+EjuF3fgMUIByouueClwOaKXvhNbYHaGRXo4HaZZ4JP7oDdANqMj7M3q +l1QzBLsGDNwXu6U1TbUBBk69hC3ia6Eu+OH2VQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ntl2dF BnG2KyRBN2+l/eDqHF+BRdPC/epio64iH9YxY=; b=ApKPDTJ5lnvFP1w3Z13KVu ojB5aY9Icji0wl6cfJeb0u8pHKTjMQiCwVjQVRW4lOLtBEH0enlcODnzZBgdN4Ah ti2OFbTPrzy4hTfWB2YMJcS8I6hsj/vNWzdmpUbdKdJawsN1vyldNimeTdIr9eGo mpBpAD85HmbbRu5GVrZth9qQjCCmUpgdhWiQWlxRc7GAEmC1zNjUnbUMqezaOQF7 UNpLs9k28mEwcXflTLqSgaeqBiSiCsScpjFxsGDf7HdHJLD5j7rXbf2dhY4SdhV/ b0YmJQPevBJ5lwwwn/mPb0NXFOhLZDnxzb47XDFVBJTrU3Gbr8Z32Q+f9854FIjg ==
X-ME-Sender: <xms:S4YmXlHdVHpRFNR2qxgE3TDsFNferv8F1RR5-8y9lGXt8GRSjyxWig>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudejgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:S4YmXun2yTr90N_dbgYq15zyMr-TRH6ExTDCJQq_IrQ411sBPa5HeQ> <xmx:S4YmXiJkSuqd71r1wTRvFunCPL-LGngcRcpCbrFNXvQzm6uqqar1uA> <xmx:S4YmXvY3-nFJolAx4BHNOU32JUFTQtOOxYO1JUoEbG5-HvwzSnGaPw> <xmx:S4YmXtNx8Gkw_Pe9gcuwhW3dFH73FjEF--UlD7osmPegEzLIfqiyDw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79C1DE00B0; Tue, 21 Jan 2020 00:04:11 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 21 Jan 2020 16:03:46 +1100
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2020 05:04:15 -0000

On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal, and I don't see use-cases compelling enough
> to warrant that complexity. I would rather keep this proposal as simple as
> possible.

I see that I didn't respond to this.  I support David's view.

Even the suggestion that clients that resume only request one assumes that clients only want one.  The client probably knows better than we do.  I would rather say nothing about the number and keep it simple. 0 means 0, 1 means 1, N means N.

FWIW, the cost of oversupply is often marginal, depending on circumstances.  In a client-speaks-first protocol with no client certificate, the server can occupy the first round trip with tickets and generally gain a performance advantage (as sending more will increase the congestion window in most cases).  Otherwise, there are usually quiescent periods that can be exploited for sending tickets.  And tickets are small, and cheap to generate.  With one exception: if you are relying on client authentication and packing that into tickets, I'm sorry.