Hi Martin, On Thu, Mar 05, 2020 at 10:42:09AM +1100, Martin Thomson wrote: > I have a third option (mu?) which differs from previous proposals. > > 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 can live with a solution that has two numbers, but only on the > understanding that 0 means "no tickets". That means no text on reuse, except > to discourage it. It means implying that resumption=0 means that the client > plans to initiate a full handshake in future rather than explicitly endorsing > reuse. 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.
I'm not sure that I understand why you feel a need to require that 0 is interpreted as an implication that the client plans to initiate a full handshake in the future. It's not clear to me that we need to make any statement about the client's intent, but can rather describe the semantics of what different values in different protocol fields mean, while reiterating the recommendation of RFC 8446 to not reuse tickets. It seems like we should be able to specify flexible technical mechanisms without dictating policy. Other than this bit about giving resumption_count of zero additional semantics than "I am requesting zero tickets if resumption succeeds", I actually think this proposal is quite good. The comments I left on PR 18 are effectively advocating for something like this. For an example of mechanism without policy, if a client successfully resumes and asks for zero tickets in the resumption case, but the server issues a ticket anyway, we can pretty reliably conclude that the original ticket is no longer valid for resumption. Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
