[TLS] TLS 1.3 draft 22 middlebox interaction

R du Toit <r@nerd.ninja> Fri, 01 December 2017 14:51 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 8972E126C3D for <tls@ietfa.amsl.com>; Fri, 1 Dec 2017 06:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.589
X-Spam-Level:
X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 tnyhOEreQg7m for <tls@ietfa.amsl.com>; Fri, 1 Dec 2017 06:51:47 -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 B29C1126B71 for <tls@ietf.org>; Fri, 1 Dec 2017 06:51:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1512139903; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=8134; bh=xbLxN6mqZJXH++57/dGr4vO12DqoiF5QZEL//fGxCm0=; b=JsfDc4BVE2yAedlI/VBK5ZJtJ9vjre2gaCHld2nFDNncU8sIK6tWX83izXiEc5y/ 3utnyR7iekTQ/6wf/6mPjAlaa4bB3FC49K3x+pJuGSX9959m4W1jERFXpe1YqXB9it0 79iTiwCgma+Tij8uu0HS25lpdUAqjQx0HsWNRqRI=
Received: from [10.253.10.77] (72.23.5.194 [72.23.5.194]) by mx.zohomail.com with SMTPS id 1512139901098613.6164486861028; Fri, 1 Dec 2017 06:51:41 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Fri, 01 Dec 2017 09:47:45 -0500
From: R du Toit <r@nerd.ninja>
To: <tls@ietf.org>
Message-ID: <DB4A1029-DBE2-44D1-97F5-DFFF13BAB52A@nerd.ninja>
Thread-Topic: TLS 1.3 draft 22 middlebox interaction
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3594966701_747600041"
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7T5ASvLddS5uZODU9ycPW0xszIY>
Subject: [TLS] TLS 1.3 draft 22 middlebox interaction
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, 01 Dec 2017 14:51:49 -0000

I want to provide some feedback that might be useful to the TLS WG:  Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org is triggering an interesting failure in at least one middlebox.

 

The middlebox in question supports TLS 1.3, but only drafts 18 through 21.  The FF Nightly ClientHello supported_versions extension advertises support for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox then interprets as only advertising support for TLS 1.2, ignoring the 0x7f16 as if it is a "grease" value.  The middlebox only perfoms protocol checks and does not actually modify anything - the session completes without any issues, which shows that the draft 22 middlebox measures are effective.  FF Nightly then starts a resumed TLS 1.3 (draft 22) session that includes 0-RTT early data.  The middlebox performs a protocol check on the ClientHello and determines that the client is trying to negotiate TLS 1.2 (per the logic of the first session).  Shortly afterwards the 0-RTT AppData record arrives, which then triggers a protocol error in the middlebox.   "D.3. 0-RTT backwards compatibility" of the draft 22 specification describes the problem, but in the context of "older server" bei
 ng "only supports up to TLS 1.2".  This particular middlebox can also be thought of as "older" because it only supports TLS 1.3 drafts 18 through 21.

 

Obviously the middlebox will soon have support for draft 22, but it does raise some questions:

 

1. I understand that some of these transition effects will go away as soon as draft support is replaced with actual 0x0304 support, but were 0-RTT sessions used in the recent TLS 1.3 middlebox resiliency experiments?  The scenario above shows that some middleboxes might (by luck?) not break full TLS 1.3 sessions, but those same middleboxes might fail with subsequent 0-RTT early data.

 

2. Should middleboxes that understand the supported_versions extension get out of the loop immediately (as in ignore traffic after ClientHello) when it sees 0x7fNN, where NN is larger than the highest draft version supported by the middlebox?  How would that be different from other "grease" values?   I understand that this might just be a temporary measure until 0x7fXX goes away (hopefully soon!).

 

3. Is there a plan for phasing out draft support once TLS 1.3 is finalized as RFC?  Servers can stop supporting 0x7fxx as soon as 0x0304 is ready, but what should a middlebox do if 0x7fxx is seen post RFC?

 

 

--Roelof