On 11/17/17 11:17, Daniel B Giffin wrote:
Is your concern that these two peers can get "stuck" in a state where they repeatedly fail a mutual attempt at resumption, thus forever falling back to no encryption?In the case of a hash-collision of resumption identifiers, it seems we don't get stuck because the active opener will advance to the next session secret on the next connection: When proposing resumption, the active opener MUST use the lowest value of `i` that has not already been used (successfully or not) to negotiate resumption with the same host and for the same pre-session key `ss[0]`.
Ah, you're right -- this will prevent issues with hash collisions. I suppose there's still a small chance of this situation arising due to implementation errors, but I suspect it's not worth decreasing the incidence of resumption to account for those.
/a _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
