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