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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 16 November 2019 11:04 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 1CCA4120019 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2019 03:04:30 -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 OJfC11OfeEGT for <tls@ietfa.amsl.com>; Sat, 16 Nov 2019 03:04:26 -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 2E8FC120026 for <tls@ietf.org>; Sat, 16 Nov 2019 03:04:26 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 574FF32E6D5; Sat, 16 Nov 2019 06:04:25 -0500 (EST)
Date: Sat, 16 Nov 2019 06:04:25 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20191116110425.GR34850@straasha.imrryr.org>
Reply-To: tls@ietf.org
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> <20191116103855.GQ20609@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191116103855.GQ20609@akamai.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q4NSz2yKA8nOQmJe5lODus3cESM>
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 11:04:30 -0000

On Sat, Nov 16, 2019 at 02:38:55AM -0800, Benjamin Kaduk wrote:

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

Do you have an alternative suggestion?  I am indeed optimizing for a minimally
invasive change that keeps the encoding simple/efficient, at the cost of some
indirection between intended signal and its representation.  As with most
things, there are trade-offs here.

We could indeed have a separate flags field, or separate counts for various
conditions:

    - # to issue on full handshake
    - # to issue on STEK rollover
    - # to issue if server supports/does-not-support reuse
    - ...

But ultimately I think it boils down to whether the client:

    - can keep reusing an existing session with the ticket it already has
    - needs a single new ticket to keep reusing that session
    - is establishing a new session (full handshake) and wants to
      use parallel connections, so may want multiple fresh tickets.

Likely the simplest mechanism that handles the above is enough, and I think the
"-1" suggestion plus a server cap at 1 ticket on resumption, pretty much
handles all three cases.

Perhaps I'm missing some important cases, and if so, it would be good to flush
those out and understand their trade-offs.

-- 
    Viktor.