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

[Eric Rescorla <[e-mail]>]

On Thu, Dec 28, 2017 at 12:54 AM, Matt Caswell <[e-mail]> wrote:

>
>
> On 27/12/17 19:33, Eric Rescorla wrote:
> >
> >
> > On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Consider the scenario where a server is operating statelessly (i.e.
> >     using the cookie extension) and a client is operating in middlebox
> >     compat mode.
> >
> >     In that case the client sends an initial ClientHello and receives a
> >     ServerHello(HRR) back with a cookie in it. Before it sends its second
> >     ClientHello it first sends a dummy CCS.
> >
> >     >From the server perspective it is operating statelessly so until it
> >     gets
> >     a ClientHello with a valid cookie in it, any message it receives is
> >     considered the "first" one. Therefore, because the server has
> forgotten
> >     about the initial interaction with the client, the first message it
> sees
> >     is a CCS.
> >
> >     Draft-22 says this:
> >
> >       "An implementation may receive an unencrypted record of type
> >        change_cipher_spec consisting of the single byte value 0x01 at any
> >        time during the handshake and MUST simply drop it without further
> >        processing."
> >
> >     Does "any time during the handshake" include the very first message
> it
> >     receives? If so then this has implications for servers that accept
> >     connections from TLSv1.2 (and below) clients (regardless of whether
> the
> >     server is stateless or not), i.e. an incoming connection that starts
> >     with a CCS and then goes on to negotiate TLSv1.2 would be accepted
> which
> >     seems odd.
> >
> >     If it doesn't mean that then a stateless server will receive a CCS as
> >     the first message and not know how to handle it.
> >
> >
> >
> > The way that NSS handles this is to remember that the CCS was received
> > and then if it turns out that you negotiate TLS 1.2, you throw an error
> in
> > that case. With that said, in most of the cases where you are stateless,
> > you're probably going to want to ignore bogus records anyway, which would
> > include unexpected CCS.
>
> So, do you believe that the correct interpretation of "any time during
> the handshake" includes the first message?


Yes, this is how we have interpreted it



> 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?

-Ekr