Re: [TLS] 1rtt thoughts

[Michael StJohns <[e-mail]>]

On 7/14/2014 1:49 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns
>     <[e-mail] <mailto:[e-mail]>> wrote:
>     > A
>     > TLS1.2 server receiving things in this order discards the
>     ClientKeyExchange
>     > with an out of sequence error, and then starts the handshake
>     normally with
>     > the receipt of the ClientHello.
>
>     I've never encountered a TLS 1.2 implementation that will discard an
>     unexpected handshake message like that as opposed to sending a fatal
>     alert (maybe) and closing the connection.
>
>
> Indeed, it's required by TLS.

Umm...

Part of the problem I have at times in discussions about TLS is the 
confusion between what happens as part of the transport connection and 
what happens as part of the TLS connection.  I think of TLS as a record 
connection over a bearer transport service.  They interact, but not 
strongly, and usually not without intervention from the client or server 
application.  The TLS thing (server, message processor, etc) attached to 
the server side of the transport connection snarfs up individual TLS 
records one by one and processes them according to its current state.

While you're both correct that TLS requires the "connection" to be 
closed in the event of a fatal error  (and here I'm referring to 7.2.2 
of RFC5246), the context of the word "connection" in that section 
doesn't appear to be same as closing the "transport" (see just above 
that where the two different terms are used).   It appears to only refer 
to closing the current TLS connection.

Nothing in section 7.2.2 suggests either the requirement to close the 
transport, nor the requirement to discard pending data in the transport 
connection.  I'm not arguing that implementations don't do exactly that 
though - I don't actually know.   if you're arguing that the standard 
says to close the transport and discard the pending TLS records, can you 
point me at that section?

I also can't find anything that says that a new connection can't be 
opened on the same transport connection after a fatal close.

So I would suggest that even with 7.2.2 you get this as an error case 
between a 1rtt TLS1.3 client and a 1.2 server:

Client                                                      Server
ClientKeyExchange ----->
ClientHello ---->
                                                            [Server 
notices data waiting on the transport
                                                             Server 
begins a connection state
                                                             Server 
receives and processes unexpected ClientKeyExchange
                                                             Server 
sends a fatal alert and discards the connection state]
                                        <--------------- Error Alert 
(unexpected_message) (plus close_notify??)
  [Client receives the error alert
    checks for type and discards it as expected]
                                                            [Server 
notices data waiting on the transport
                                                             Server 
begins a connection state
                                                             Server 
Receives and processes ClientHello
                                                             Server 
sends its part of a TLS1.2 handshake]
                                         <--------------- ServerHello, 
ServerKeyExchange etc
[Client receives the Server Side messages and processes
   them...
  Client resends the ClientKeyExchange that was ignored above]
ClientKeyExchange  ------>
etc --->
  .............................  Continue through the normal connection 
process.



 From the server's side this looks like two different connections. From 
the client side, it's just negotiating to the right suite.

Mike


>
> -Ekr
>
>     We could refine TLS 1.2 processing, of course, but if you were
>     expecting that to be backwards compatible with existing code then I
>     fear it won't work.
>
>
>
>
>     Cheers
>
>     AGL
>
>     --
>     Adam Langley [e-mail]
>     <mailto:[e-mail]> https://www.imperialviolet.org
>
>     _______________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>
>