[TLS] ServerHello extensions

R du Toit <r@nerd.ninja> Thu, 18 January 2018 18:21 UTC

Return-Path: <r@nerd.ninja>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F4A12895E for <tls@ietfa.amsl.com>; Thu, 18 Jan 2018 10:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.12
X-Spam-Level:
X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja
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 o-u1xRpZ5zBJ for <tls@ietfa.amsl.com>; Thu, 18 Jan 2018 10:21:20 -0800 (PST)
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61249129C53 for <tls@ietf.org>; Thu, 18 Jan 2018 10:21:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1516299674; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=5277; bh=Ij99CF8ebxTX8MTyOe5NSaycGDg+QGOAto7ySUfqLj4=; b=atoNbRleT6IRJfz6vnoQMvBJBZc5cGaOyiE3dvdZzJAHYtg2rzBGLgZHAU/qIvJb OqDL67QwUGDkxEo5fFg+nodvn9hs2YwNyfCggUWwxasM8xIeMF9YiFrZVEFw3iiocbi Kg9Nrw4hMr253eJuHfabQCL/YMibMYcw7/fr/O5k=
Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1516299673481570.4428154151128; Thu, 18 Jan 2018 10:21:13 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Thu, 18 Jan 2018 13:21:11 -0500
From: R du Toit <r@nerd.ninja>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja>
Thread-Topic: ServerHello extensions
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3599126473_1111136330"
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g8nOECbNCcttSiEmQkTGRFaqh_k>
Subject: [TLS] ServerHello extensions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 18 Jan 2018 18:21:22 -0000

Issue#1: Section "4.1.3 Server Hello" currently states:

extensions   A list of extensions. The ServerHello MUST only include extensions which are required to establish the cryptographic context. Currently the only such extensions are “key_share” and “pre_shared_key”. All current TLS 1.3 ServerHello messages will contain one of these two extensions, or both when using a PSK with (EC)DHE key establishment. The remaining extensions are sent separately in the EncryptedExtensions message.

 

"supported_versions" should be added to the list of required extensions for a session that negotiates TLS 1.3.

 

 

Issue#2: Section "4.1.4 Hello Retry Request" currently states:

Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an “illegal_parameter” alert.

 

There is no rule about checking that SH.supported_versions.selected_version matches HRR.supported_versions.selected_version.   I am currently adding draft 23 support, and want to enforce that rule to make sure the protocol state machine does not have to jump back and forth between TLS 1.2 and TLS 1.3.

 

I can add a PR for both issues, if you agree.

 

--Roelof