Re: [TLS] Ticket request PR#20

Benjamin Kaduk <bkaduk@akamai.com> Fri, 01 May 2020 18:50 UTC

Return-Path: <bkaduk@akamai.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 C56DE3A19D2 for <tls@ietfa.amsl.com>; Fri, 1 May 2020 11:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=akamai.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 4igu17kkMp8Z for <tls@ietfa.amsl.com>; Fri, 1 May 2020 11:50:25 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 69F403A19D0 for <tls@ietf.org>; Fri, 1 May 2020 11:50:25 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 041Ih1Bb009886 for <tls@ietf.org>; Fri, 1 May 2020 19:50:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=RJkXYK5wGe5ZrqfZcvWQ/UHocgGqkXWYPigKupWQvOc=; b=X8KR/dHn2bXb+Y2MeW6neS0JauHmIQJiZ0xzMY8Jpg8tEr0jgn/PZum4En7tGzfFzabO P+Oi03Tyet9H3fLOY2ZzOWd3AMnGxR1xF5gkWf7OKSwmcABlhbPTyXmGFQl269xLJt3i SplfJyCxpA7Q7YX3uBYb4V5MAnbQbqRumSgBi3i/TRy4PPES2TLdjCWW0balxWM7dw/Y +CnNMBkLFjSAntMkEARXMASwySOsWpBRt9fEDZB4Vrwj5jmYPVZ94ROVPz/96JmalJoj X60FhMQzxv087Nn8Jy9S2KcJUFgEVeJVqakpL2ldRNZdVryqBBDMroIS2x9frX7SBF7m iw==
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 30r7jqbb7c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Fri, 01 May 2020 19:50:24 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 041Ilbg9017364 for <tls@ietf.org>; Fri, 1 May 2020 14:50:24 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 30rqj0rcbg-1 for <tls@ietf.org>; Fri, 01 May 2020 14:50:23 -0400
Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 7781A85B92 for <tls@ietf.org>; Fri, 1 May 2020 18:50:23 +0000 (GMT)
Date: Fri, 01 May 2020 11:50:22 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: tls@ietf.org
Message-ID: <20200501185022.GG3811@akamai.com>
References: <20200419222318.GY41308@straasha.imrryr.org> <CBE68A19-EBBE-4BF6-97B0-F6CEE9A90363@sn3rd.com> <20200501181131.GA76674@straasha.imrryr.org> <20200501181858.GF3811@akamai.com> <20200501183958.GB76674@straasha.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200501183958.GB76674@straasha.imrryr.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-01_11:2020-05-01, 2020-05-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=492 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2005010141
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-01_11:2020-05-01, 2020-05-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 mlxlogscore=476 suspectscore=1 clxscore=1015 impostorscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2005010141
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KlQ50xqRuA1RshZd4BW7qbX4UWk>
Subject: Re: [TLS] Ticket request PR#20
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: Fri, 01 May 2020 18:50:27 -0000

On Fri, May 01, 2020 at 02:39:58PM -0400, Viktor Dukhovni wrote:
> On Fri, May 01, 2020 at 11:18:58AM -0700, Benjamin Kaduk wrote:
> 
> > > Declining this comes across hostile to me.  I read the objections to
> > > "only {0, 0} means zero" as a blocking counter-measure against the
> > > deferred discussion, and not a material objection on the merits. :-(
> > 
> > I don't think it's right to say that "only {0,0} means zero" -- after all,
> > this is a *request*, not a command from the client to the server.
> 
> And yet, RFC 8446 C.4 says servers SHOULD always send at least one, and
> so this draft is modifying that to say that it is now "OK" to sometimes
> send no tickets based on the applicable counter.  All I am asking for is
> that the "OK" condition be made more strict, requiring both counters to
> zero before C.4 is overriden.

I don't see how this draft is modifying that SHOULD -- SHOULD is for cases
where "do this if you don't know any better, but in some circumstances
doing the other thing is okay".  I see this draft as defining a mechanism
to convey information from client to server, so that the server can know
whether it's one of those "some circumstances" when "doing the other thing
is okay".  But that doesn't modify the SHOULD, and it's still up to the server.

> The server can still start WW-III upong seeing the extension, but that
> does not preclude clarity about the *intended* meaning.  That's what
> the MUSTs/SHOULDs/MAYs etc. are for.

I actually think that in this case prose is going to be better at conveying
the intended meaning than normative keywords will, but should probably
refrain from commenting further until I actually do the AD Evaluation.

-Ben