Re: [TLS] DTLS HelloVerifyRequest.server_version
Manuel Pégourié-Gonnard <mpg@polarssl.org> Sat, 09 August 2014 15:12 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 DA01E1A0458 for <tls@ietfa.amsl.com>; Sat, 9 Aug 2014 08:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.294
X-Spam-Level: **
X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[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 3lBPgfAXzTNo for <tls@ietfa.amsl.com>; Sat, 9 Aug 2014 08:12:16 -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 4C8501A0427 for <tls@ietf.org>; Sat, 9 Aug 2014 08:12:16 -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:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=XZ+R9dhFj0h+hI49QyFtRMQH6O+uknn2Ho4qC0aWioE=; b=bB8Sn9SM2ocD/pGNjVKddZjl6/Ox4QMFXR3Zg+YUg6Lk2Wzobv3528HeomqRF335o+HBGNVanKtQNU0SZ/K837WZa/ipriSHxC9lNLV9jtLw1J+G0Cgt5wx7yPo2erKwjHvPsvsWljDWmmP2XMYRI5cUAIme3pgZdEKlpeGudBI=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XG7wN-000401-KB; Sat, 09 Aug 2014 16:48:16 +0200
Message-ID: <53E63465.4040907@polarssl.org>
Date: Sat, 09 Aug 2014 16:47:01 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "<tls@ietf.org>" <tls@ietf.org>
References: <53CD4B2C.5080906@polarssl.org>
In-Reply-To: <53CD4B2C.5080906@polarssl.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
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/35hkS4VKeSYqgUuQlR88L3-MvWY
Cc: Nagendra Modadugu <nagendra@cs.stanford.edu>
Subject: Re: [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: Sat, 09 Aug 2014 15:12:18 -0000
Hi again, I'm sorry to insist (cc-ing authors of RFC 6347) but unless these statements are clarified, as an implementer I'll have to just pick whatever behaviour looks most reasonable to me, a situation that standards are supposed to avoid. Manuel. On 21/07/2014 19:17, Manuel Pégourié-Gonnard wrote: > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] DTLS HelloVerifyRequest.server_version Manuel Pégourié-Gonnard
- Re: [TLS] DTLS HelloVerifyRequest.server_version Manuel Pégourié-Gonnard
- Re: [TLS] DTLS HelloVerifyRequest.server_version Nikos Mavrogiannopoulos