Re: [TLS] consensus call: (not precluding ticket request evolution)

[Viktor Dukhovni <[e-mail]>]

On Thu, Mar 05, 2020 at 10:42:09AM +1100, Martin Thomson wrote:

> I have been somewhat convinced by the arguments about how resumption
> is different and can tolerate the complexity of the additional
> counter.  That is, endpoints can request replacement of consumed
> tickets (1 for when a connection attempt succeeds, N if they race N
> connections and only keep one; 1 + M if they want to replace M wasted
> tickets from M previous failed connection attempts).
> 
> The text about reuse in PR 18 is not good, however.  (PR 18 is also
> very wordy, but that's something I will leave to the editors of the
> draft.)

I'm open to suggested improvements, and would probably reread and
apply some polish in any case.

> I can live with a solution that has two numbers, but only on the
> understanding that 0 means "no tickets".

But not in a way that forecloses interoperability with a client that
tries to negotiate reuse via a to-be specified mechanism in a later
draft.  We can stop short of specifying/supporting/... reuse, but
deliberately precluding adding it later seems a step too far.

Which means:

    - A zero in the new_session_count really does mean no tickets,
      since then the client ends up with no tickets on an initial
      handshake.

    - However, a zero in the resumption_count can only be in scope
      when a resumption is happening, which means that in fact the
      client did present a ticket, and given a non-zero value in
      the new_session_count, a zero here can *only* mean an attempt
      to negotiate reuse.

      Given that servers presumptively do not support reuse (after
      all we're not specifying it at present) such an attempt can
      be *politely* declined by vending one ticket instead.

      Actually vending zero would in fact be what servers do when
      (perhaps some day) they do support reuse, and the client
      would conclude that the presented ticket is reusable.

> That means no text on reuse, except to discourage it.

If that's the consensus, so be it, but a resumption count of
zero does need to be treated as 1 then, otherwise we're not
just deferring a decision on reuse, but unequivocally foreclosing
any posibility of adding it later in a compatible way.

> It means implying that resumption=0 means that the client plans to
> initiate a full handshake in future rather than explicitly endorsing
> reuse.

No, that would be a tragic and deliberate roadblock, which I don't think
is merited.  The client can signal that by setting the both counters to
zero.

> As Russ mentions, we might cite the relevant sections of RFC 8446 when
> it comes to reuse, but for me that would have to be in the context of
> saying not to do that.

That's fine, if that's the consensus, but we should not sabotage the
possibility of defining reuse later in a backwards compatible manner.

-- 
    Viktor.