[gnutls-devel] GnuTLS | DTLS handshake restarted by ClientHello using invalid message sequence numbers (#1233)

[Read-only notification of GnuTLS library development activities]

Paul commented:


I opened a similar [issue for Scandium](https://github.com/eclipse/californium/issues/1620), which also exhibited this behavior. From the discussions I had there, it appears the DTLS 1.2 RFC may provide some ground for accepting ClientHello messages with increased message sequence numbers based on the [quote](https://www.rfc-editor.org/rfc/rfc6347.html#page-18):

> If a server receives a ClientHello with an invalid cookie, it SHOULD
> treat it the same as a ClientHello with no cookie. This avoids
> race/deadlock conditions if the client somehow gets a bad cookie
> (e.g., because the server changes its cookie signing key).

> Note to implementors: This may result in clients receiving multiple
> HelloVerifyRequest messages with different cookies. Clients SHOULD
> handle this by sending a new ClientHello with a cookie in response to
> the new HelloVerifyRequest.

If this is indeed the reason for accepting such ClientHellos, then I think the issue can be closed. I am leaving this issue open to to ensure the behavior is intended (a dev may close it if that is the case), as it does appear to be a bit of an edge case.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1233#note_574085248
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20210512/1a27a7d6/attachment.html>