Re: [TLS] DTLS HelloVerifyRequest.server_version

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 11 August 2014 07:24 UTC

Return-Path: <nmav@redhat.com>
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 CB7F01A0350 for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 00:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.371
X-Spam-Level:
X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 6FsbX0ndaTSP for <tls@ietfa.amsl.com>; Mon, 11 Aug 2014 00:24:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9677A1A034E for <tls@ietf.org>; Mon, 11 Aug 2014 00:24:43 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7B7OgrE027653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Aug 2014 03:24:42 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7B7OdH5020219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2014 03:24:41 -0400
Message-ID: <1407741884.2390.3.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= <mpg@polarssl.org>
Date: Mon, 11 Aug 2014 09:24:44 +0200
In-Reply-To: <53CD4B2C.5080906@polarssl.org>
References: <53CD4B2C.5080906@polarssl.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EnJEFZXexm_VBFWGxJHkOr9od04
Cc: "<tls@ietf.org>" <tls@ietf.org>
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: Mon, 11 Aug 2014 07:24:44 -0000

On Mon, 2014-07-21 at 19:17 +0200, 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.

If I remember well the reason for that is that the HelloVerifyRequest is
sent without any state being considered. That is, it is very likely that
the server does not know the protocol that will actually be negotiated
in the handshake (remember that HelloVerifyRequest is sent in a
stateless way to prevent DoS on the server).

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

I'd fill an errata for that, the text as you notice looks inconsistent.

regards,
Nikos