IETF Logo Mail Archive

Re: [TLS] ServerHello extensions

R du Toit <r@nerd.ninja> Thu, 18 January 2018 22:07 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 0BC9812D7F0 for <tls@ietfa.amsl.com>; Thu, 18 Jan 2018 14:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xmwOYPPIbv8g for <tls@ietfa.amsl.com>; Thu, 18 Jan 2018 14:07:05 -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 8775D12D7E5 for <tls@ietf.org>; Thu, 18 Jan 2018 14:07:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1516313222; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:CC:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=9145; bh=hZm162GDixjJg9nOVHcky5SNbRb10KqvGdYo0LjGR6M=; b=VJI1AF6wAh8NUl1RXN564oimK+iLuDEat3ZkIL3QMprh3LSf32nS509zlcf5kY5H 7QXiTM4Dh4RmgjcNfw2lyZgvtkgZrA7BLfMPzmyWyNZY3jdUar0QzCFFD4ziYnhCCYI 92ZvJKnN1thbap8bHGtG/zXR68PhHkvx+mpbrGgs=
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 1516313222296667.3506158664442; Thu, 18 Jan 2018 14:07:02 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Thu, 18 Jan 2018 17:06:59 -0500
From: R du Toit <r@nerd.ninja>
To: Eric Rescorla <ekr@rtfm.com>
CC: "tls@ietf.org" <tls@ietf.org>
Message-ID: <D35AD71E-5FEE-470F-BD57-3FC84769E612@nerd.ninja>
Thread-Topic: [TLS] ServerHello extensions
References: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> <CABcZeBNN+_yiTqa4=_mn5x+nxjLoJmhq8d0suUaNcpkJnzXu=w@mail.gmail.com>
In-Reply-To: <CABcZeBNN+_yiTqa4=_mn5x+nxjLoJmhq8d0suUaNcpkJnzXu=w@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3599140022_1319248582"
X-ZohoMailClient: External
X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hICsBAe7Z_y3AoXnW8x_mm3PLSY>
Subject: Re: [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 22:07:07 -0000

https://github.com/tlswg/tls13-spec/pull/1143

 

 

From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday, January 18, 2018 at 1:25 PM
To: R du Toit <r@nerd.ninja>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ServerHello extensions

 

Thanks. These are good points. I would welcome a PR.

 

On Thu, Jan 18, 2018 at 10:21 AM, R du Toit <r@nerd.ninja> wrote:

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

 


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email