Subject: [TLS] DTLS HelloVerifyRequest.server_version

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Mon, 21 Jul 2014 19:17:32 +0200

Hi,

Sorry if I'm just being dense and fail to understand something very
obvious, but I have trouble understanding how the server_version field
of HelloVerifyRequest should be handled, according to section 4.2.1 of
RFC 6347.

More precisely, I'm under the impression that the last paragraph of page
15 and the first of page 16 contain contradictory statements:

                      DTLS 1.2 server implementations SHOULD use DTLS
   version 1.0 regardless of the version of TLS that is expected to be
   negotiated.

                                          The server MUST use the same
   version number in the HelloVerifyRequest that it would use when
   sending a ServerHello.

It seems to me that if a server obeys the MUST of the second sentence,
it cannot obey the SHOULD of the first one (unless of course it never
negotiates DTLS 1.2, which I assume is not the intention of the RFC).

                DTLS 1.2 and 1.0 clients MUST use the version solely to
   indicate packet formatting (which is the same in both DTLS 1.2 and
   1.0) and not as part of version negotiation.  In particular, DTLS 1.2
   clients MUST NOT assume that because the server uses version 1.0 in
   the HelloVerifyRequest that the server is not DTLS 1.2 or that it
   will eventually negotiate DTLS 1.0 rather than DTLS 1.2.

                           Upon receipt of the ServerHello, the client
   MUST verify that the server version values match.

It seems to me that verifying the server version values match (between
HelloVerifyRequest and ServerHello) is actually using the version for
another goal that "to indicate packet formatting", something that seems
to be forbidden.

Am I misinterpreting the text?

Thanks,
Manuel