[TLS] DTLS HelloVerifyRequest.server_version

Manuel Pégourié-Gonnard <mpg@polarssl.org> Mon, 21 July 2014 17:17 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349FF1A009E for <tls@ietfa.amsl.com>; Mon, 21 Jul 2014 10:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.394
X-Spam-Level:
X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfSjqfRR948q for <tls@ietfa.amsl.com>; Mon, 21 Jul 2014 10:17:54 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B2F1A02DB for <tls@ietf.org>; Mon, 21 Jul 2014 10:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=7vnZu/i2jgy3Km+AuzeVm9SC8erNP4YZXMahYq/Lu60=; b=okdzQ8CILIJOUY66ZXkWkqEMGV2kWZZQaSUIy7L00JLs5+7KYJ/t/H7vvU9960z+DWgeBzifsZ5tP5uOqTzXJUOtVxEEpDMhpGnOnsBfFMNP9KJnTKph7BF0vOHtvRW1u9HKCVgR8Oz7qTuUOK0UDCKxnHv1eH3JNwC5lonY7y4=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1X9HDc-0001Dy-SO for tls@ietf.org; Mon, 21 Jul 2014 19:17:45 +0200
Message-ID: <53CD4B2C.5080906@polarssl.org>
Date: Mon, 21 Jul 2014 19:17:32 +0200
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rRSiR1s55E6CoP0ZM37AKxWezd0
Subject: [TLS] DTLS HelloVerifyRequest.server_version
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 17:17:55 -0000

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