On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: > On 12 October 2016 at 19:50, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > I also noticed another edge case: What is to prevent server from > > omitting key share group (emitting a cookie, so the restart is > > not spurious), presumably causing the client to blank its key_share > > and then proceed to accept DH versus client's previously sent share? > > How about: If key_share isn't in the HRR, the client should replay > it's old key_share verbatim. Though I agree that the text should say > as much.
Yeah, would work. > Maybe we should require text for every extension that can appear in > the HRR: what to do if the extension is in the HRR, and what to do if > it isn't. Or have every extension be "no change" if not present, and do the specified thing to CH if prsent and known, abort if present and unknown. That would waste a bit of space with extensions signaling support for some rewrites if the server doesn't use those but retries the handshake. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
