Re: [TLS] Murray Kucherawy's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 14 December 2020 06:41 UTC

Return-Path: <kaduk@mit.edu>
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 68FEA3A0A83; Sun, 13 Dec 2020 22:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y9TAq5THEsSc; Sun, 13 Dec 2020 22:41:05 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 956343A0A7E; Sun, 13 Dec 2020 22:41:05 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BE6evUJ020276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Dec 2020 01:41:02 -0500
Date: Sun, 13 Dec 2020 22:40:57 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Murray Kucherawy <superuser@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-ticketrequests@ietf.org, tls-chairs@ietf.org, Sean Turner <sean@sn3rd.com>, tls@ietf.org
Message-ID: <20201214064057.GC64351@kduck.mit.edu>
References: <160792704100.7346.5362009681286111098@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <160792704100.7346.5362009681286111098@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YX353GSb3cQ6wjCVQPfnBiKmTpw>
Subject: Re: [TLS] Murray Kucherawy's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)
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: Mon, 14 Dec 2020 06:41:08 -0000

On Sun, Dec 13, 2020 at 10:24:01PM -0800, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Some places in this document use "reuse", others "re-use".  I'm not sure which
> one is right, but it should be consistent throughout.

Both are (or, rather, can be) correct, if you treat "reuse" is a noun and
"re-use" is a verb.

> In Section 3:
> 
>    A client starting a new connection SHOULD set new_session_count to
>    the desired number of session tickets and resumption_count to 0.
> 
> Since it's only SHOULD, I'm curious about why an implementer might decide to do
> something other than this.

IIRC there's not currently any other behavior that particularly makes
sense, but since we had some extreme contention about sending particular
combinations of values there was not much desire to attempt to nail this
case down.  (It also leaves some flexibility for potential future work,
though I'm not entirely sure what shape that would take.)

-Ben