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: =?windows-1252?Q?Manuel_P=E9gouri=E9-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
>