Expand comment that details why two DTLS tests currently fail.

Two tests currently fail (and are disabled) due to a flaw in the DTLSv1.0
specification - this flaw was addressed in DTLSv1.2, however our DTLS
server code still needs to support the fix.

Quoting RFC 6347 section 4.2.4:

"This requirement applies to DTLS 1.0 as well, and though not explicit in
 [DTLS1], it was always required for the state machine to function
 correctly."

In otherwords, both the original DTLS implementation and the DTLSv1.0
specification have a broken state machine, resulting in possible dead lock.

1 files changed, 5 insertions, 2 deletions

diff --git a/src/regress/lib/libssl/dtls/dtlstest.c b/src/regress/lib/libssl/dtls/dtlstest.c
index d7f2f4b2de..becc500c90 100644
--- a/src/regress/lib/libssl/dtls/dtlstest.c
+++ b/src/regress/lib/libssl/dtls/dtlstest.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: dtlstest.c,v 1.10 2021/06/19 15:33:37 jsing Exp $ */
+/* $OpenBSD: dtlstest.c,v 1.11 2021/06/19 15:52:41 jsing Exp $ */
 /*
  * Copyright (c) 2020, 2021 Joel Sing <jsing@openbsd.org>
  *
@@ -705,7 +705,10 @@ static const struct dtls_test dtls_tests[] = {
         /*
          * These two result in the server accept completing and the
          * client looping on a timeout. Presumably the server should not
-         * complete until the client Finished is received...
+         * complete until the client Finished is received... this due to
+         * a flaw in the DTLSv1.0 specification, which is addressed in
+         * DTLSv1.2 (see references to "last flight" in RFC 6347 section
+         * 4.2.4). Our DTLS server code still needs to support this.
          */
         {
                 .desc = "DTLS with dropped server CCS",