On Thu, Mar 5, 2020, at 11:42, Viktor Dukhovni wrote: > 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.
Nothing we say here will prevent either: a) someone from ignoring the recommendation, as they already do b) someone from defining an extension that modified behaviour, superceding this mechanism So I can't see why you would be unhappy with this. All I am asking for is either no text on reuse (leaving it to 8446), or a brief recapitulation and reference to the text in 8446. This does not sabotage any future attempt to define something that reuses tickets. The text in 8446 needs no such defense because it stands on its own. > - 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. This is disagree with. I offered other alternatives in my original mail. I know that you might infer that a client intends to reuse from this signal, but that's different than it expressly meaning that the client will be reusing the ticket. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
