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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 21 January 2020 05:54 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 59FD5120096 for <tls@ietfa.amsl.com>; Mon, 20 Jan 2020 21:54:15 -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 UTdgppmAKLk0 for <tls@ietfa.amsl.com>; Mon, 20 Jan 2020 21:54:11 -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 CAFA3120071 for <tls@ietf.org>; Mon, 20 Jan 2020 21:54:11 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2A77348FFB; Tue, 21 Jan 2020 00:54:11 -0500 (EST)
Date: Tue, 21 Jan 2020 00:54:11 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200121055411.GJ73491@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <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> <20191120064819.GR34850@straasha.imrryr.org> <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com> <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/obArH_cZul4UaEO1X9x20dZbgGk>
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: Tue, 21 Jan 2020 05:54:15 -0000

On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote:

> On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
> > Regarding Viktor's suggestion, I personally believe it would increase the
> > complexity of the proposal, and I don't see use-cases compelling enough
> > to warrant that complexity. I would rather keep this proposal as simple as
> > possible.
> 
> I see that I didn't respond to this.  I support David's view.
> 
> Even the suggestion that clients that resume only request one assumes
> that clients only want one.  The client probably knows better than we
> do.  I would rather say nothing about the number and keep it simple. 0
> means 0, 1 means 1, N means N.

The proposal has since been simplified. With 1 meaning 1, 2 meaning 2,
...  The only change is that 0 and 255 become special, with 255 meaning
definitely no tickets, and 0 meaning tickets only if the server sees a
need a replace the presented ticket.  Otherwise, the client has no way
to request refresh only if needed, and must ask for 1 just in case.

Unnecessary tickets are a waste server and client resources and
bandwidth, and make external caches "hot" on clients that are perfectly
fine with a slowly changing series of multi-use tickets.


> FWIW, the cost of oversupply is often marginal, depending on
> circumstances.  In a client-speaks-first protocol with no client
> certificate, the server can occupy the first round trip with tickets
> and generally gain a performance advantage (as sending more will
> increase the congestion window in most cases).

This is useless for clients with just a single mult-use slot in their
ticket cache.  Not everything is a web browser.

> Otherwise, there are usually quiescent periods that can be exploited
> for sending tickets.  And tickets are small, and cheap to generate.
> With one exception: if you are relying on client authentication and
> packing that into tickets, I'm sorry.

There's no need to exclude valid use-cases.  The refined proposal
is rather non-invasive, and handles this case cost-effectively
on clients that re-use tickets (and don't use early-data, ...).

-- 
    Viktor.