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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 21 November 2019 05:59 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 049EC120143 for <tls@ietfa.amsl.com>; Wed, 20 Nov 2019 21:59:54 -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 No2AT6i3y68m for <tls@ietfa.amsl.com>; Wed, 20 Nov 2019 21:59:51 -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 CDC0F1200FB for <tls@ietf.org>; Wed, 20 Nov 2019 21:59:51 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3CD82332921; Thu, 21 Nov 2019 00:59:51 -0500 (EST)
Date: Thu, 21 Nov 2019 00:59:51 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20191121055951.GV34850@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPDSy+6DFJ+OYRtYK6eEiUt1noiik4KxqrGFx0ro_RL2Mft_VA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0_afZCFDRkQhI7WqfqHKUGQD3YE>
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, 21 Nov 2019 05:59:54 -0000

On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote:

> Daniel has a IoT use-case where due to memory constraints,
> a client knows it can only handle a certain number of tickets,
> and therefore Daniel was wondering if it would make sense to
> make the requested number of tickets a required maximum
> (as in a RFC 2119 MUST).

I agree.  I am also looking for servers to not oversupply clients with excess
tickets, and not expecting any obligation on the server to return as many as
requested.

> Additionally,
> Daniel would prefer to see the document move forward.

I am also keen for the document to move forward, it adds a very useful signal
from the client to server.

> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal,

There is no additional complexity in the protocol. The same extension
structure is sent, and its interpretation is almost identical.  The
only difference is:

    * 0xff is the new zero (client declines use of tickets)
    * 0x00 is a new value to signal optional (reusable) tickets
      as-needed.
    * 0x01-0xfe are interpreted exactly as in the original draft!
      (But clients should be *encouraged* to send 1 on resumption).

> and I don't see use-cases compelling enough to warrant that complexity. I
> would rather keep this proposal as simple as possible.

There are millions of Postfix MTAs that only support a single slot ticket
cache, and where a server that sends more than 1 ticket causes multiple writes
to the single-slot cache (hence part of the enthusiasm for the extension), but
also writes to the cache (which is an external Berkeley DB) create excessive
overhead.  Also the server wastes CPU and network bandwidth sending unwanted
tickets, but the client must not simply decline tickets, since it wants stale
tickets to be refreshed.

I have a hard understanding why a relatively simple proposal that meets the
needs of many deployed MTAs is not a valid use-case.

If you don't feel like authoring the text to make the requested change,
I can probably contribute a pull request.  At this time the details
seem to have been ironed out in principle.

-- 
    Viktor.