Re: [Gen-art] Genart last call review of draft-ietf-tls-ticketrequests-06

Alissa Cooper <alissa@cooperw.in> Wed, 16 December 2020 15:15 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5313A0A9C; Wed, 16 Dec 2020 07:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=cooperw.in header.b=HTdg2RDs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jn142Auz
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 m2SI4RqJ9HMQ; Wed, 16 Dec 2020 07:15:00 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27D03A0EFF; Wed, 16 Dec 2020 07:14:59 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B396BAEA; Wed, 16 Dec 2020 10:14:58 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 16 Dec 2020 10:14:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=t bb0iFw/Hm05VmAmr6xeEss0z1QfnN0Bes0AvpbWSC8=; b=HTdg2RDsYSZbL1XV6 UoIlG8PEFGiymKylb5cz4psx/rrs4X5Bl6/AMurNCFVX9c3uxD++cDsjZu9kyPyf P3KImjbwCnjHXQml0znr6rOpomU67YtcJvNVRr2rI91V8ihWoqZilZ0USu3auZJA AOH3UregDLQn2aKzF0ZjG7YlujGbECmX9uacjwUPhfs/j0pU4MTm0KHkSDdMPKEn rb0jh+X2Z+LFdkPJHAOZyJRIzGTyj2VGhfhlRNGuz3HMMHfd7jgvGqx5q2Gmh0q5 i2LeLZmVvuARMwKOjAYcGXtVvfKq8nryUC+xifqyv+XKDp9qmMDYFqW/91kL/qRY 0RKNg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=tbb0iFw/Hm05VmAmr6xeEss0z1QfnN0Bes0AvpbWS C8=; b=Jn142AuzsRFsRmw/tF2AXnXCE7SjBiEAe5EzM/MYh6BYkNC5j2uywAlfu NO87AaT41N07TofqLIVcLyydBXcboRODTfYNCgmUgM+wC1riflE0LP/6fhjpwwQO LHzBpqc20ORe9RLyv/R0N595AMB7kJ49BbKCUKrQe+t1kezlJg2ip2esjAk66ILW 0Mb6asvQFiaMf3Nfl+02dUHUd5JE1l5KwuxIrvqVgmlWHbE0WOspxLCZwwvTINR4 sPKNrmp87KZNexbIeP6InS3fYyFfpj1HkmXSc4ZgEncQDhr3A8y/ENcXNY9teh2J EKO4jiqcqpoN9jYi1bFTDo8xiBXmQ==
X-ME-Sender: <xms:cSTaX_23lFWm7by5rA_9gbkECB62h06igals-pTwqxAK711YM02mXA> <xme:cSTaX-HA0VgknOLvPOmi7zi-k9FRmhz1W39oWpVRzCiXiQU6Hrcn1WpGNqv1QAmK5 qBrek7medQuWATUAQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelvddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpefguedtkeethfekleehheethedvkeektedtvddvjefghfeikeffgeegveef ueegtdenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtud drleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:cSTaX_6dZSn2lgkHvdYR5RH_TJte-kFYKJL57iUZsRsotpXKshjV-Q> <xmx:cSTaX03lQRsGh2vwl8xsh0FwV7Bikz4VNcsCVU8pjBrFTeOnCwcuLA> <xmx:cSTaXyGUUTTJsD1qjWLZ3RX9atYmDqse_g5H2Unw4idWvjFNx2WWtQ> <xmx:ciTaX-BGecx4V6yP81BQ62lmwSB7UZwxVmQYHDpQGAhvWRt5PX2Vew>
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id A0E16108006B; Wed, 16 Dec 2020 10:14:57 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <f53bd799-1a13-443e-bbdb-9dc89f13aeae@www.fastmail.com>
Date: Wed, 16 Dec 2020 10:14:57 -0500
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-tls-ticketrequests.all@ietf.org, Last Call <last-call@ietf.org>, "TLS@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <684B8EB3-A7B6-4E03-AA31-E06B84C90E5E@cooperw.in>
References: <160653564435.9376.7782618547521054521@ietfa.amsl.com> <f53bd799-1a13-443e-bbdb-9dc89f13aeae@www.fastmail.com>
To: Christopher Wood <caw@heapingbits.net>, Dale Worley <worley@ariadne.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ZT9I8-hoJ_oCtUSIbGKqUnEBzVw>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-tls-ticketrequests-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2020 15:15:02 -0000

Dale, thanks for your review. Chris, thanks for addressing Dale’s comments. I entered a No Objection ballot.

Alissa


> On Dec 3, 2020, at 10:22 PM, Christopher Wood <caw@heapingbits.net> wrote:
> 
> Thanks for the feedback, Dale! We addressed your comments and updated the draft. The diff is available here:
> 
>   https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-ticketrequests-07.txt
> 
> Best,
> Chris
> 
> On Fri, Nov 27, 2020, at 7:54 PM, Dale Worley via Datatracker wrote:
>> Reviewer: Dale Worley
>> Review result: Ready
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>> 
>> Document:  draft-ietf-tls-ticketrequests-06
>> Reviewer:  Dale R. Worley
>> Review Date:  2020-11-27
>> IETF LC End Date:  2020-12-03
>> IESG Telechat date:  Not known
>> 
>> Summary:
>> 
>>    This draft is ready for publication as a Standards Track RFC.
>> 
>> Editorial comments:
>> 
>> 2.  Use Cases
>> 
>>   *  Parallel HTTP connections: To minimize ticket reuse while still
>>      improving performance, it may be useful to use multiple, distinct
>>      tickets when opening parallel connections.
>> 
>> To the naive reader, the ordering of the phrases doesn't seem to match
>> the logical ordering of the concepts.  Perhaps
>> 
>>   *  Parallel HTTP connections: To improve performance, a client
>>      may open parallel connections.  To avoid ticket reuse, the client
>>      may use multiple, distinct tickets on each connection.
>> 
>> --
>> 
>>   *  Decline resumption: Clients can indicate they have no intention of
>>      resuming connections by sending a ticket request with count of
>>      zero.
>> 
>> "have no intention" seems to me to suggest a decision that will not
>> change.  Since the future cannot be guaranteed, perhaps better wording
>> is "do not intend to resume", suggesting a current state that might
>> possibly change in the future.
>> 
>>   new_session_count  The number of tickets desired by the client when
>>      the server chooses to negotiate a new connection.
>> 
>>   resumption_count  The number of tickets desired by the client when
>>      the server is willing to resume using a ticket presented in this
>>      ClientHello.
>> 
>> If I understand the processing which is suggested correctly, when the
>> client sends a ClientHello, the server can choose to either negotiate
>> a new connection, or (if a ticket is present in the ClientHello) the
>> server can choose to resume the previous connection represented by the
>> ticket.  These two parameters provide the requested ticket count for
>> the two situations.
>> 
>> Assuming the above is correct, I would recommend changing the wording
>> slightly, as "when" suggests a fact which is true over an extended
>> period of time, whereas the provided counts are applicable in just this
>> one instance:
>> 
>>   new_session_count  The number of tickets desired by the client if
>>      the server chooses to negotiate a new connection.
>> 
>>   resumption_count  The number of tickets desired by the client if
>>      the server chooses to resume (using the ticket presented in this
>>      ClientHello).
>> 
>> (Change "the" to "a" in the last sentence if the ClientHello can
>> present more than one ticket among which the server can choose.)
>> 
>> [END]
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art