Re: [TLS] DTLS Handshake race condition

[Andy Wilson <[e-mail]>]

Section 4.2.2 states:

The first message each side transmits in each handshake always has
   message_seq = 0.  Whenever each new message is generated, the
   message_seq value is incremented by one.  Note that in the case of a
   rehandshake, this implies that the HelloRequest will have message_seq
   = 0 and the ServerHello will have message_seq = 1

This would imply that the client WOULD process the ServerHello with seq==1
as this is a re-handshake.

That's the way i'm reading the spec..




On 12 August 2013 05:08, Michael Tuexen <[e-mail]>wrote:

> On Aug 11, 2013, at 4:19 PM, Andy Wilson <[e-mail]> wrote:
>
> > After looking over the RFC a bit, wouldn't the client be expecting a
> HelloVerifyRequest after its ClientHello?
> I don't think this is necessary, since the client and the server have
> already
> a relation. So there is no need to use the cookie mechanism.
>
> However, the question is the same. In your case
> * 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 sends a HelloVerifyRequest(MsgSeqNo = 1)
> * The client doesn't process the ServerHello, since it expects the
>   MsgSeqNo == 0.
>
> Therefore, the server retransmits the flight consisting of the
> HelloVerifyRequest
> and the client retransmits the flight containing the ClientHello.
> So the solution would be that the client accepts
> * ServerHellos with MsgSeqNo=0 and MsgSeqNo=1.
> * HelloVerifyRequest with MsgSeqNo=0 and MsgSeqNo=1.
>
> Am I missing something?
>
> Best regards
> Michael
> >
> > On 12 August 2013 01:17, Michael Tuexen <
> [e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> >
> > --
> > Regards
> >
> > Andy
>
>


-- 
Regards

Andy