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

[Matt Caswell <[e-mail]>]

On 28/12/17 17:42, Eric Rescorla wrote:
> 
> 
> On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <[e-mail]
> <mailto:[e-mail]>> 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