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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 January 2020 12:40 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 B702C120099 for <tls@ietfa.amsl.com>; Thu, 23 Jan 2020 04:40:58 -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 Y7UDt1RuI4ZW for <tls@ietfa.amsl.com>; Thu, 23 Jan 2020 04:40:56 -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 4BDA012008F for <tls@ietf.org>; Thu, 23 Jan 2020 04:40:56 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 6BB2D4B46B; Thu, 23 Jan 2020 07:40:55 -0500 (EST)
Date: Thu, 23 Jan 2020 07:40:55 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200123124055.GF73491@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com> <fd37bd2a-c799-4bf4-95b3-65943681683b@www.fastmail.com> <20200121055411.GJ73491@straasha.imrryr.org> <97de6364-c628-45aa-8613-ba1a32cc41b2@www.fastmail.com> <A5448AC9-6EBB-48F9-A1B0-A787FBBCFF05@akamai.com> <08A4B0CD-9903-4027-B672-E8C7AFB34B4D@akamai.com> <20200123005528.GA12073@localhost> <CAN2QdAH7t4fPgBfBSO7Ni1As2bVB9QvCw1s9j0ggqvTRUATE8A@mail.gmail.com> <20200123021455.GA73491@straasha.imrryr.org> <87427017-551e-4633-a0d3-75f378879aa9@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87427017-551e-4633-a0d3-75f378879aa9@redhat.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/E6q9P6-PpLoDzGESZE5JlrXa4Nk>
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: Thu, 23 Jan 2020 12:40:59 -0000

On Thu, Jan 23, 2020 at 12:57:31PM +0100, Hubert Kario wrote:

> > The deployed base of Postfix servers issues multi-use tickets (always,
> > there's no extension to tell me otherwise), and sends zero tickets
> > on resumption, so I need to not just throw away tickets that are
> > still valid.
> 
> I wonder if the approach with a database with strict ACID-ity is the 
> correct one for ticket storage.

It isn't "strict acidity", but there never more than one ticket per
peer, stores replace the existing entry, loads read the latest entry
stored.

> What I mean, is that, especially in postfix case, using slightly older 
> ticket that it could will have minimal impact on the connection.

Slightly older is unavoidable, because time passes between configuring
an SSL connection to use a particular session and actually using it.

If tickets rotate too fast, busy Postfix SMTP clients will frequently
end up with stale tickets, and will fail resumption much of the time.

The server accepts reuse, and defaults to assuming that the client is
willing to reuse.

If the extension provides a tiny bit more signalling at no cost to
applications that have no use for reuse, then I'll be able to also
support clients that explicitly signal non-reuse (e.g. MUAs talking
to a service that is both MSA and SMTP relay).

> Thus a database that is basically append only, with clients that look
> for newest ticket (and disregard races on this lookup) and a
> garbage-collection process that removes old tickets every few hours
> will work ok.

There is indeed a GC process, but we're using off-the-shelf indexed
file dabases (Berkeley DB or LMDB), which are not append only.  And
in any case, this is rather tangential.

The real issue is that I'd like to offer clients that don't reuse a
fresh ticket, but allow clients that do reuse to continue to do that.

Anyway, I wanted to avoid TL;DR, and just present an argument based
largely on:

    - No actual complexity to those that don't ever want reuse
    - Pontential savings to those who for some reason do reuse.

That really ought to be enough, given that ignoring the reuse
case and always issuign a ticket is *free*:

    /* Hande non-use, ignore reuse, and impose local limit */
    if (ticknum == 0) ticknum = 1;
    else if (ticknum == 255) ticknum = 0;
    else if (ticknum > ticklimit) ticknum = ticklimit;

    /* now proceed as in previously solved problem */

  v.s. extension as-is:

    /* Impose local limit */
    if (ticknum > ticklimit) ticknum = ticklimit;

That's a totally trivial change that yields status-quo, but allows other
implementations to do something more intelligent with "ticknum == 0".

-- 
    Viktor.