On Thu, Dec 28, 2017 at 08:54:45AM +0000, Matt Caswell wrote: > > So, do you believe that the correct interpretation of "any time during > the handshake" includes the first message? I think it would be helpful > to be more explicit in the text if that is the case, i.e. identify the > first point in the handshake and the last point in the handshake where > CCS is valid. There probably should also be some words about how servers > implementing older TLS versions should handle a CCS that comes first. > > However, I'm concerned about the added complexity of interpreting things > that way. Suddenly a CCS arriving is no longer handled by just dropping > it and forgetting it - you now have to store state about that and > remember it later on in the process in other TLS versions. The CCS > workaround was supposed to be a simple no-op to implement and it no > longer appears that way in this interpretation.
To me it seems like if you are doing a stateless retry, you can not fail the handshake if you receive CCS between the two CHs. In fact, more generally you can not fail the handshake if you receive arbitrary junk between the two CHs (as long as the junk does not mess framing of the later CH). Here "can not fail" does not mean requirement on implementation, it is fundamential constraint due to stateless implementation (because failing would require keeping state!). I think there should be note about this in the specification (that stateless implementations need to ignore arbitrary junk records and messages before the ClientHello message). However, this causes problems if the junk contains any handshke messages that are fragmented. Especially so if the underlying transport not reliable. This is the same problem as why fragmenting ClientHello is a bad idea. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
