TLS 1.3 is pretty firm about what you can change in a second ClientHello. It lists a small set of allowed changes to extensions (cookie, PSK binder, key shares, early data, and padding). For the rest it says that nothing can change. So clearly a client is in the wrong if it changes, adds, or removes an extension that isn't on this list.
The first question is whether a server should be required to check that only permitted changes are made to a second ClientHello. The second question is - if the server is not required to check for consistency - which ClientHello the server uses. The third question is - if we allow checking at all - what the consistency check looks like. My position is that the check cannot be mandatory, but we should allow servers to check. One feature that we put significant effort into supporting was the notion of a stateless HelloRetryRequest, which I believe to be incompatible with checking (or at best extraordinately inconvenient). With that answer in mind, if the second ClientHello might differ, I assert that the server uses that. Hubert observes that this behaviour is not specified at all, which is entirely true. I think that using the first ClientHello would be nonsensical, because the server needs to use the second ClientHello for those extensions that can change, like key share. If we require or allow checking - and I think that we should definitely allow a check - the details of the conditions under which a check might fail aren't completely obvious for new extensions. A new extension might be defined that has special handling in HelloRetryRequest, so it might be reasonable to allow new extensions to be changed. Conversely, we might assume that anything that changes is going to be present in the HelloRetryRequest. Therefore, only extensions that the server understands and includes in HelloRetryRequest can change. That's not true for the early data extension, which is removed after HelloRetryRequest without any requirement for a server indicating support, but we might assume that extensions in the core spec have special status in this regard. The simplest thing here seems to be a prohibition on checking unknown extensions for consistency between ClientHello1 and ClientHello2. A final observation about checking extensions: it's not clear that we require consistent extension ordering. If the key share extension changes, can it be reordered? Can unchanged extensions be reordered? Clearly neither results in a semantic change, but if a server that is required to check, might need to aggressively compress information about the first ClientHello in order to comply and extension ordering is an obvious thing to erase to save space in the cookie. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
