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

[Matt Caswell <[e-mail]>]

On 28/12/17 17:55, Eric Rescorla wrote:
> 
> On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
> 
> 
>     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]>
>     > <mailto:[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.
> 
> 
> Well, you can receive a CCS first any time you're stateless. What's unusual
> is having to subsequently reject it if you are stateless and *then*
> negotiate
> 1.2. My point is that this doesn't seem like a very big hardship for the
> reasons
> above.

I must be missing your point. According to the spec as it stands even
with a stateful server I MUST ignore a CCS that comes first. Since this
is a stateful server it may end up negotiating TLSv1.2 - which requires
us to abort the handshake if the CCS comes first. No sensible
implementation will ever send a CCS first in this scenario, so why am I
required by the spec to ignore it and implement the extra complexity in
TLSv1.2 handling?

In reality I wouldn't bother to implement this which would make me
technically non-compliant. I would prefer it if the wording were fixed
to not require this.

Matt