Re: [TLS] DTLS Handshake race condition

After looking over the RFC a bit, wouldn't the client be expecting a
HelloVerifyRequest
after its ClientHello?

On 12 August 2013 01:17, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>wrote:

> Dear all,
>
> while fixing a bug in OpenSSL regarding the DTLS handshake, I thought about
> the following scenario (both sides decide to renegotiate at about the same
> time):
>
> * A DTLS connection is established.
> * The server sends a HelloRequest(MsgSeqNo = 0) and starts the
> retransmission
>   timer, since this is a flight.
> * The HelloRequest is dropped by the network.
> * The client sends a ClientHello(MsgSeqNo = 0) and start a retransmission
> timer,
>   since it is its first flight.
> * The server receives the ClientHello, stops the retransmission timer
>   and sends the next flight starting with ServerHello(MsgSeqNo = 1)
>   since it considers the received ClientHello as an ack for the flight.
> * The client doesn't process the ServerHello, since it expects the
>   MsgSeqNo == 0.
>
> Therefore the client retransmits its ClientHello and the server retransmits
> its flight containing the ServerHello. Am I missing something?
>
> The problem is that the server has no way to figure out if the received
> ClientHello is a reaction to a HelloRequest or not.
> The only way out I see is that the client accepts ServerHellos with
> MsgSeqNo=0 and MsgSeqNo=1.
> I don't think this is covered in http://tools.ietf.org/html/rfc6347
>
> Any opinions?
>
> Best regards
> Michael
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Regards

Andy