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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
