Re: [TLS] ClientHello record header version

R du Toit <r@nerd.ninja> Fri, 02 February 2018 21:01 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 81A6C129C6C for <tls@ietfa.amsl.com>; Fri, 2 Feb 2018 13:01:28 -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 4GsfyCyr5N8g for <tls@ietfa.amsl.com>; Fri, 2 Feb 2018 13:01:27 -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 043C91243FE for <tls@ietf.org>; Fri, 2 Feb 2018 13:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1517605284; 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=4134; bh=h0oiDkXIGKUSKsbs1s62L+JMf6hmOBxjTRsGLq8cFFg=; b=wWDAmtN8vqi3ecJviAiq6ntAfv+DUddZXXckQi951UQjgFQGlR4IeVdkjp+Qtu5B hPTMCtF0XV0E11i0SrptqAgnfPc46IHYT5FCUVqt+e5eHsfHIZcLIqEHeCkq/tM8d8T A9B9wTvn4Y0uwloqmsQpsJgFfbRUMIVfbEKzhaSk=
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 1517605284203829.5514056304032; Fri, 2 Feb 2018 13:01:24 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Fri, 02 Feb 2018 16:01:21 -0500
From: R du Toit <r@nerd.ninja>
To: David Benjamin <davidben@chromium.org>
CC: "tls@ietf.org" <tls@ietf.org>
Message-ID: <EE2AE064-3880-4F07-906C-65FA9237482A@nerd.ninja>
Thread-Topic: [TLS] ClientHello record header version
References: <389CDA50-B152-473B-84BA-CCE226F1EF40@nerd.ninja> <CAF8qwaA+f=EH_qux-HgAe9-xcejXHzPpNaJi7VN7KQB6u8Xi9g@mail.gmail.com>
In-Reply-To: <CAF8qwaA+f=EH_qux-HgAe9-xcejXHzPpNaJi7VN7KQB6u8Xi9g@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3600432084_2060546240"
X-ZohoMailClient: External
X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZQfVtVBCZbMiBgS9mtIPrjz1ycE>
Subject: Re: [TLS] ClientHello record header version
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: Fri, 02 Feb 2018 21:01:28 -0000

> What implementation are you working on? 

Proprietary, closed-source TLS stack.

 

>  Section 5.1 says that, in TLSPlaintext, the legacy_record_version "MUST be ignored for all purposes". 

Agree.  The interop issue was definitely on my side, and I was just using it as background for my question.

 

Section 5.1 also says: "This value MUST be set to 0x0303 for all records generated by a TLS 1.3 implementation other than the ClientHello".  With my "implementer's hat" on the word "MUST" implies that it must be enforced.

 

 

> And, of course, any pre-1.3 middleboxes which hit this case are non-compliant.

Indeed.  If BoringSSL already uses 0x0303 on the retry CH while OpenSSL uses 0x0301 then some (non-compliant) thing-a-ma-jig-in-the-middle will cause issues... and trigger the Universal Law of Users.