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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 20 November 2019 06:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 B181C120255 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 22:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 MubXEcPq4qLo for <tls@ietfa.amsl.com>; Tue, 19 Nov 2019 22:48:21 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02768120125 for <tls@ietf.org>; Tue, 19 Nov 2019 22:48:20 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 416AC331BB8; Wed, 20 Nov 2019 01:48:19 -0500 (EST)
Date: Wed, 20 Nov 2019 01:48:19 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20191120064819.GR34850@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <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> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EQcaY5NmWdHM_G3-UrP_bdKJV6Y>
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 06:48:23 -0000

On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote:

> > 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.

OK, in that case, the proposal, is that on resumption, if the proposed
extension is *absent*, then the server should generally send just one rather
than any larger default.

If the extension is present, it is up to the client to not blindly ask for N
tickets each time, and generally ask for just one ticket on resumption, once it
has sufficiently many tickets for the desired concurrency level, with each
parallel thread obtaining one replacement ticket its next connection.

As discussed clients that prefer to reuse tickets, can ask for zero, and get 1
only as-needed.  If the server supports reuse then all is well.

If the server does not support and refuses reuse, then it will issue a new
ticket each time and may only accept it once, but the client may have a
single-slot cache.  If the client makes only one connection at a time, this
also works, but if/when its handshakes with the server overlap (a narrow window
of ~1RTT) and two connections attempt to resume with the same ticket, one of
them will end up doing a full handshake, but only when the client and server
applications have incompatible ticket reuse expectations.  Some friction
when the client and server are mismatched is not the end of the world.

So on the whole I think the proposal still works with just a numeric signal
(tweaked with 0xff == none and 0 == reuse), and the onus to "generally send 1"
on resumption moved to the client (i.e. clients that don't solicit ticket reuse
should request only 1 ticket once they have enough).

-- 
    Viktor.