[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
From:       Nico Williams <nico () cryptonector ! com>
Date:       2020-01-31 23:55:35
Message-ID: 20200131235533.GA18021 () localhost
[Download RAW message or body]

On Fri, Jan 31, 2020 at 09:06:12AM -0800, Tommy Pauly wrote:
> First off, thanks for the lively discussion on ticket reuse! I think
> it's a valid use case and something that should continue to be
> discussed.
> 
> However, for the purposes of the WGLC for this draft,
> draft-ietf-tls-ticketrequests, it may be best to separate the
> conversation. It seems that the negotiation of ticket reuse would be
> best served by another document that could be adopted by the WG. The

Viktor's comment came before the end of WGLC, so the WG needs to
consider his comments, and needs to reach consensus.  Considering the
fact that cosensus has not yet _obviously_ been reached (there have been
positive and negative responses), the WG's chairs may need to make a
call for consensus (or maybe the chairs think consensus is obvious?).

Consider this my encouragement to the chairs that they make a call for
consensus.

> ticket request document, as it was adopted, was specifically a
> mechanism to request multiple tickets so as to *avoid* ticket reuse.

TLS 1.3 already does that.

The adoption call is nowhere near as specific -- in fact, it says
nothing about purpose of the extension.

The TLS WG charter doesn't mention it.

The abstract of this I-D says, among other things:

   This extension aims to provide a means for servers to determine the
   number of tickets to generate in order to reduce ticket waste, while
   ^^^^^^^^^^^^^^^^^
   simultaneously priming clients for future connection attempts.

That number could be zero, and indeed, that's allowed.  "Zero unless you
won't allow me to reuse this one" seems clearly in-scope to me.  That
you have no need for it, doesn't make it out of scope or a bad idea.

Moreover, I posted an explanation of why this extension will cause
Postfix trouble.  That deserves a substantive response (and IETF process
may even demand it).

Nico
-- 

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]