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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 16 November 2019 10:05 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 5734E120119 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2019 02:05:50 -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 tFNQI1BMkUOc for <tls@ietfa.amsl.com>; Sat, 16 Nov 2019 02:05:48 -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 AF278120019 for <tls@ietf.org>; Sat, 16 Nov 2019 02:05:47 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id C318332E666; Sat, 16 Nov 2019 05:05:46 -0500 (EST)
Date: Sat, 16 Nov 2019 05:05:46 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20191116100546.GP34850@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <caa6f6b4-537c-46bb-a04b-28d2b59f8ecd@www.fastmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CeXeZyjldd_mIP5Bmow4zd8NmFQ>
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:05:50 -0000

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.

I was hoping Matt Caswell would chime in with his perspective on this topic, as
he and I together refined the ticket generation logic in OpenSSL 1.1.1.  But,
it seems he has not been able to find the requisite cycles, so I'll post my
summary comments as best I can:

1.  The tentative proposal was a client-side indication that new tickets are
    optional, and only needed when the presented ticket requires replacement.
    If still re-usable, accept it without issuing a new one.

    The goal was to make it possible for a client and server to "negotiate"
    re-use, rather than have that be a static feature of the application or a
    given implementation.

2.  The specific suggestion of reserving a bit is more complex than needed, it
    would suffice to simply "subtract 1" from the client's hint:

        0 - (effectively -1), client unconditionally wants no new tickets.

        1 - (effectively 0), client prefers to reuse tickets.  Only issue
            a new ticket if necessary (STEK rotation, ticket expiration, ...),
            or server does not support any ticket reuse.

        n - (effectively n - 1), client would like up to n-1 fresh tickets on
            any full handshake.

    This looks simple enough to me, and allows the client to clearly communicate
    that tickets are optional when reusable.

3.  As noted previously, servers SHOULD NOT generally issue multiple tickets on
    successful resumption, at that leads to unbounded oversupply of tickets.
    Only the server knows whether resumption will happen, or a full handshake,
    and so clamping of the ticket count to 1 on resumption is best a
    server-side decision.

    A client can continue to request the same number of tickets (say hint 3 =>
    2 wanted, per the above), with the server returning that number on full
    handshake, but 1 or zero on resumption.  When the client's presented ticket
    is not suitable for resumption, cleary the client needs new tickets (fresh
    start) and the behaviour should be the same as on an initial connection
    with no tickets from the client.

    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.

-- 
    Viktor.