Re: [TLS] Interaction between cookies and middlebox compat mode

[Matt Caswell <[e-mail]>]

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. 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. However, we add
additional words around what stateless servers do with "junk" they
receive that doesn't look like a ClientHello (i.e. they ditch it). That
"junk" would include a CCS. That seems like a much cleaner solution.

Matt