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

[Benjamin Kaduk <[e-mail]>]

On Thu, Mar 05, 2020 at 09:27:47PM -0500, Viktor Dukhovni wrote:
> On Thu, Mar 05, 2020 at 05:30:04PM -0800, Benjamin Kaduk wrote:
> 
> > > No it does not, because he specifically emphasised treating 0 in the
> > > resumption count as issue no tickets, whereas PR#18 says that that that
> > > don't support reuse (perhaps all if that's the present consensus, until
> > > such time as reuse becomes specified) need to treat both 0 and 1 as 1.
> > 
> > Is this actually the case, though?  If we keep the signal from server to
> > client in the echoed extension, the client will know whether or not the
> > server supports resumption, and thus can ask for the appropriate value 0 or 1
> > in subsequent handshakes.
> 
> Yes, if the signal from the server is reliable (e.g. required of servers
> that support reuse), and clients are updated to store that signal along
> with issued tickets, rather than treating each exchange de-novo, then
> yes, you're right the 0->1 becomes inessential.  I addressed this in
> response to your pull-request comments.
> 
> > It seems like this would avoid the trap of alternating full and resumption
> > handshakes that was discussed downthread for the case where client supports
> > reuse but server does not.
> 
> Yes, there is some wiggle-room here.  What's your sense of the best
> way forward?

So far as I know, either version will meet the technical needs, so it's to
large extent a matter of style and "philosophical consistency with the
rest of the protocol".  My personal thoughts are that "make zero mean zero"
makes a lot of sense, and there doesn't seem to be much burden from the
"return whether the server supports reuse" part of things, so if I held the
pen that's what I'd go with.  But I will take whichever version the WG
sends to me for publication.

-Ben