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

Benjamin Kaduk <bkaduk@akamai.com> Sat, 16 November 2019 10:39 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 A8D26120026 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2019 02:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 6szPyJo6z8F4 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2019 02:38:59 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 A81A4120019 for <tls@ietf.org>; Sat, 16 Nov 2019 02:38:59 -0800 (PST)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAGAYljQ010484 for <tls@ietf.org>; Sat, 16 Nov 2019 10:38:58 GMT
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=kjDKcMTxiUssIxnWru6QiCB/yvubiL16Ss2ODvhWCtI=; b=dKdzEBOkRQzdsFz83OMtJ/eEOnsYjMdxIUqOhKDzL1nysGFssBMdNBSSQEi0bQnaDcM0 DNIKNVJMECVhqfzqOZ65TiIZzmFD9zhVCkMk9UEIt+NPmPwfqok7VAuERWMyYpXqO8xI SA9Cy5BWboE4JCU6l60QesIzKe88ntMRCTg3jvkKMGP2FFlei3Lc4GNrOeOyxnbZvwMh No6s1jMkCgw3cbh935qd9NZdrHlfjmID8NPmYUJm6MlVBgNTnyBi+V/9yBGau9Fkvo2b wjzte/fCn1AyR5+eaY+2WnwwXvtplxM4NRzX/oSyJeHAJ+Wn+1I9B38DvIKmIf6xw4nJ VA==
Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2waffv00e4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Sat, 16 Nov 2019 10:38:58 +0000
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAGAWg89027969 for <tls@ietf.org>; Sat, 16 Nov 2019 05:38:57 -0500
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint7.akamai.com with ESMTP id 2wadb29evs-1 for <tls@ietf.org>; Sat, 16 Nov 2019 05:38:57 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 4217580E1D for <tls@ietf.org>; Sat, 16 Nov 2019 10:38:57 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1iVvTk-0004pz-3q for tls@ietf.org; Sat, 16 Nov 2019 02:38:56 -0800
Date: Sat, 16 Nov 2019 02:38:55 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: tls@ietf.org
Message-ID: <20191116103855.GQ20609@akamai.com>
References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <caa6f6b4-537c-46bb-a04b-28d2b59f8ecd@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20191116100546.GP34850@straasha.imrryr.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-16_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911160097
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-16_02:2019-11-15,2019-11-16 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 spamscore=0 adultscore=0 malwarescore=0 phishscore=0 clxscore=1015 suspectscore=13 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911160098
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Q12N0LvJg-UQSbEPKfxliKMMuGI>
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: Sat, 16 Nov 2019 10:39:02 -0000

On Sat, Nov 16, 2019 at 05:05:46AM -0500, Viktor Dukhovni wrote:
> On Thu, Nov 14, 2019 at 08:05:34AM -0800, Christopher Wood wrote:
> 
> > The only comment that was not integrated was the desire to use the hint
> > to express not only a count, but also a bit indicating whether or not
> > clients will accept a ticket if the server needs to send one (e.g., if its
> > STEK is about to rotate and any old tickets would expire). The authors did
> > not incorporate that into the document since it added complexity and there
> > didn't seem to be much support for it.
> 
[...]
> 
>     The -03 draft added a sentence suggesting that clients should ask for just
>     one ticket on resumption, but I would like to suggest that this logic
>     belongs in the server.

We should probably be emphasizing that *all* policy belongs on the server, and
we are just defining a signal for the client to convey some information as input
to the server's decision.  In that mindset I'm not sure that the "subtract one"
signal is the most satisfying design (though I concede that it is probably the
most efficient encoding).

-Ben