On 28/12/17 17:42, Eric Rescorla wrote: > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > > > On 28/12/17 12:28, Eric Rescorla wrote: > > 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. > > > > > > I could add those. > > > > > > 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. > > > > > > Well, it seems like the issue here is you want the client to send CH1, > > CCS, CH2 > > so we need the server to accept that. Am I missing something? > > The point is a stateless server will not know about CH1 at the point > that it receives CCS. > > > Well, sort of. > > Specifically, there are three valid things that a server (whether stateless > or stateful) can receive: > > - CH1 [I.e. a CH without a cookie] > - CH2 [i.e., a CH with a cookie] > - CCS > > It should respond to any other message with an alert and abort the > handshake. > A stateful server should also tear down the transport connection, so > that subsequent > messages are considered an error. This obviously isn't an option for a > stateless server, > so, yes, a stateless server might in principle receive arbitrary amounts > of junk > before CH1 or between CH1 and CH2, and it would still survive, albeit by > sending alerts. > > > > Actually, as Ilari points out, there could be any > junk (including partial records) arriving between CH1 and CH2. So this > feels more like a special case for stateless servers. > > In other words I would prefer to say that a CCS that arrives first is > not allowed. That simplifies the general case and requires no special > coding for servers implementing older versions of TLS. > > > This issue only seems to arise for people who are both doing TLS 1.3 and > TLS 1.2 *and* doing stateless implementations, which is kind of an odd > configuration because a number of the conditions in TLS 1.3 that involve > HRR (and thus can be stateless). It doesn't arise for QUIC (because no > TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of > junk). Or am I wrong?
Correct, although technically the wording of draft-22 (in your interpretation) *requires* that a server receiving a CCS first MUST ignore it - even though that should never happen except in the weird scenario above. That is why I prefer to say that a CCS arriving first is always an error for the general case. Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
