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

Tommy Pauly <tpauly@apple.com> Wed, 20 November 2019 03:53 UTC

Return-Path: <tpauly@apple.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 DAEF912002E for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 19:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, 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=apple.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 MHcr2SJUmM1c for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 19:53:22 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 1B5ED120232 for <tls@ietf.org>; Tue, 19 Nov 2019 19:53:22 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAK3lp4l040276 for <tls@ietf.org>; Tue, 19 Nov 2019 19:53:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=lIhk5Ky59lbbjNrYyJ9iue+KsccymC8FNwL6gnHGQ3Y=; b=VTQFoCBXN6xmXISZ+W7te+1jN4mqGlwlFfa89VLcZCVuvqYs/mX0ChS71SWgz6zpw/P8 aibShuf5M7F5XoPMHklOADMlIUet9MIh6lqmmSAcAl9hhBYNg8OGGbt43+zlJc2wDX2G AvKmBuybF31Ufp5xgeeSvhat+KC3rVBuA0IyocvczwCj4yva1v4zXBwq0GbocJssZ+db /2HYARpgsS5zqyJD1dwwM1cOwVee0+I9ANZke6wQLmews0o0tl4k4wktTznh8yscSlHC RRCAhNGrfqTM/NBIyjRCQpXtRB6m6DE7e/nK+tcabTWHaUnunhdmmhFFK8hsK0KYS+rT TQ==
Received: from sg3-postinop-sz01.asia.apple.com (sg3-postinop-sz01.asia.apple.com [17.84.80.96]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2wagyymhfa-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <tls@ietf.org>; Tue, 19 Nov 2019 19:53:20 -0800
Received: from sg3-mmpp-sz01.asia.apple.com (sg3-mmpp-sz01.asia.apple.com [17.84.80.93]) by sg3-postinop-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1900KG21GT4D00@sg3-postinop-sz01.asia.apple.com> for tls@ietf.org; Wed, 20 Nov 2019 11:53:17 +0800 (+08)
Received: from process_milters-daemon.sg3-mmpp-sz01.asia.apple.com by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1900K0015A4T00@sg3-mmpp-sz01.asia.apple.com> for tls@ietf.org; Wed, 20 Nov 2019 11:53:17 +0800 (+08)
X-Va-A:
X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: 44859b2b-4836-4899-b4db-3777c0255122
X-V-A:
X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: 2a93f7d2-c5f9-4361-9291-b9f254056437
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-19_08:,, signatures=0
Received: from [17.235.144.89] by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q19005CQ1GOQP20@sg3-mmpp-sz01.asia.apple.com> for tls@ietf.org; Wed, 20 Nov 2019 11:53:14 +0800 (+08)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Wed, 20 Nov 2019 11:53:08 +0800
References: <caa6f6b4-537c-46bb-a04b-28d2b59f8ecd@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <CADZyTkmaUVj=sFdgg93MuM2au0B=1M1k3yCA1XDoaAneVDmnNw@mail.gmail.com> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org>
To: tls@ietf.org
In-reply-to: <20191120034812.GQ34850@straasha.imrryr.org>
Message-id: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/y4gd3qPxeBQ_TO_n0V3YsSHNaww>
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: Wed, 20 Nov 2019 03:53:24 -0000


> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote:
> 
>>>    - 0x01-0xfe => client wants single-use tickets:
>>>        + send up to that many tickets on full handshake,
>>>        + however, generally send just 1 ticket on resumption, or when
>>>          replacing tickets during long-lived connections.  This helps to
>>>          reduce chronic ticket "oversupply".
>> 
>> Having a recommendation to generally just send one ticket
> 
> You left out the key qualification: "on resumption".  Now perhaps
> that strategy is only needed in the *absence* of any signal from
> the client, and with the extension the onus is perhaps on the client
> to send "1" once it has enough tickets, in which case the server
> does not need to apply the heuristic that helps it to avoid chronic
> ticket oversupply.  In which case, the "generally send just 1" can
> be left out, it is a side comment, not essential to the overall
> proposal.

That would be great to leave that out.
> 
> Somebody should try to avoid ending up with N new tickets after
> every connection, but in could well be the client.

Yes, I think that can and ought to be the client. The client is really the only party that can know how many tickets have been "consumed" by potentially failed attempts to connect that the server didn't see in time or got dropped.

Thanks,
Tommy
> 
>> doesn't address the motivating use case for the document, which is Happy
>> Eyeballs (connection racing). Having multiple tickets is required in a steady
>> state, so we shouldn't recommend against that.
>> 
>> Any client that wants to only do the reuse case can just not use this extension.
> 
> No, the extension is *very* useful to such clients, to signal to the server
> that that's what they want to do, so that the server then only issues new
> tickets when necessary.
> 
> -- 
>    Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls