Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 01 October 2019 17:06 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 0B00E120AC5 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 10:06:42 -0700 (PDT)
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 QrPOXRNYRhUw for <tls@ietfa.amsl.com>; Tue, 1 Oct 2019 10:06:38 -0700 (PDT)
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 69B0D120A8A for <tls@ietf.org>; Tue, 1 Oct 2019 10:06:05 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 5C45F2A5CD1; Tue, 1 Oct 2019 13:06:03 -0400 (EDT)
Date: Tue, 1 Oct 2019 13:06:03 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20191001170603.GX21772@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191001145600.GU21772@straasha.imrryr.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YCoZfJZyaANfxOLB7QVdEzUNu1o>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt
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, 01 Oct 2019 17:06:46 -0000

On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:

> I've read the draft, it looks quite useful and reasonable.  It would
> be good to see this published.
> 
> I have one idea (implemented in OpenSSL 1.1.1 on the server side)
> that may be worth mentioning in this context (and perhaps even the
> draft):
> 
>    - By default, OpenSSL TLS 1.3 servers only vend multiple (two)
>      tickets on full handshakes.  Resumed sessions issue just one
>      ticket.

Thinking about this some more a related issue comes to mind.  A
client with (what it believes to still be) a valid reusable ticket
may want to tell the server that does not *need* a new ticket, ...

But, this should not preclude the server from issuing an updated
ticket when the presented ticket has expired (necessitating a full
handshake) or will soon expire and should be replaced.

For example:

    The Postfix SMTP server maintains a sliding window of two STEKs,
    one for encrypting/decrypting new session tickets, and another
    just for decrypting older tickets.  A fresh STEK is created
    once an hour (by default), and the current active STEK becomes
    the old STEK.

    When a client presents a ticket encrypting with the current
    STEK, no replacement ticket is issued, but when a client presents
    a ticket encrypted with the old STEK, a replacement ticket is
    issued under the fresh STEK.

A server that has a similar STEK rotation approach should be able
to conditionally refresh a client's ticket that is stale, while
otherwise honouring the client's signal that it does not need
more tickets at present.

Therefore, there is I think a need for two separate "no new tickets
required" signals.

    A.  The client has no intention to perform (further?) resumptions,
	No tickets at all required.

    B.  The client is happy to keep using the current ticket so long
	as it is still fresh, but would like periodic refresh if the
	ticket gets stale from the server's perspective.

	i.  If the presented ticket is expired or stale and a new
	    one is needed, the server is asked to return just one
	    ticket.

	ii. If the ticket is fresh, return no tickets.

Therefore, it would be useful for the extension to distinguish
between these two use-cases, perhaps an optional flags field, with
use-case B indicated via one of the flag bits?

-- 
	Viktor.