Re: [TLS] DTLS Handshake race condition

[[e-mail] (Martin Rex)]

Michael Tuexen wrote:
> 
> I think the RFC does not cover the race condition I'm referring to...
> What if the HelloRequest(message_seq=0) is lost and the client sends
> a ClientHello(message_seq=0) on its own (since the local user initates
> a re-handshake). The server accepts the ClientHello and responds with
> a ServerHello(message_seq=1). The client however expects a
> ServerHello(message_seq=0), since it never saw the HelloRequest.
> The HelloRequest is also not retransmitted, since the server considers
> it acked by the ClientHello.
> 
> It is only the collision case I'm considering and I think which is
> not covered by the RFC.

Your observation seems correct.

The original TLS handshake is only half duplex.  Properly dealing
with renegotiation is therefore non-trivial.  The original TLS spec
addresses the overlapping of the renegotiation handshake by

  - omitting HelloRequests from the Handshake message hash computation.

  - require the TLS client to ignore any HelloRequests that
    are be received during the handshake (which includes the one
    received after the client has already requested a new handshake
    by sending a ClientHello from your scenario.


Another "grey" area, that may not work particularly well with
some TLS implementations, is what happens if one side requests
a renegotiation while the other is still sending application data.


While the TLS spec itself this should be OK when renegotiation handshake
messages are interleaved with application data, it may not actually
work with all implementations.  Taken to the extreme, with TLS APIs
that perform peer certificate validation in an event-based fashion,
it may open a potential vulnerability (for servers doing delayed
client authentication) when the client starts the renegotiation
handshake, but stops sending handshake messages after the
client's certificate handshake message and then continues sending
application data under the original/enclosing TLS session.


-Martin