Re: [TLS] TLS 1.3 draft 22 middlebox interaction

R du Toit <> Wed, 06 December 2017 01:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D8881273E2 for <>; Tue, 5 Dec 2017 17:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Status: No, score=-4.799 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_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DvrZ9q4Srf_A for <>; Tue, 5 Dec 2017 17:01:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 541721200F1 for <>; Tue, 5 Dec 2017 17:01:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1512522055; s=zoho;;; h=Date:Subject:From:To:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=9455; bh=XaLip5ievsXy/UE9xUng6l9n+EBcdOHQfNDdD9Tn75U=; b=BTqBKtundWqieu7II2T3qSnRAohAWdSYqe3ek7t3IeiKBTYgHefuZkCiEHGjJnMR SGPUTXghCxfHk2YoBGEm7mf36/d2X7Sdg2Jmyq+jwYFEEqegbdDtWI9vJLhKc4oxVDK XkRtDwZHFaNYEWEi/T5QtkeULNulDnYYrBkpxYXY=
Received: from [] ( []) by with SMTPS id 1512522055743249.4272374754022; Tue, 5 Dec 2017 17:00:55 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Tue, 05 Dec 2017 20:00:53 -0500
From: R du Toit <>
To: <>
Message-ID: <>
Thread-Topic: [TLS] TLS 1.3 draft 22 middlebox interaction
References: <> <20171203155552.GA8097@LK-Perkele-VII>
In-Reply-To: <20171203155552.GA8097@LK-Perkele-VII>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3595348855_381150038"
X-ZohoMailClient: External
X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Dec 2017 01:01:04 -0000

Thank you for the thoughtful responses so far.  I have been working in the middlebox arena for more than 20 years, and I am also concerned about the state of certain implementations.  I would like to think that the TLS stack that my team and I maintain have no serious security flaws, but vulnerabilities in TLS stacks have shown that even people with the best of intentions get things wrong at times.  Security conscious middlebox vendors would certainly like to fix their bugs, while at the same time improving interoperability with TLS 1.3.  The middlebox in my original post, for example, has already fixed the 0-RTT draft-22 interop issue.


Anyway, that is my way of saying that there are many people like myself following the TLS WG email threads, and we all want to help make TLS a success for consumers and enterprises.  It would be good if middlebox vendors could actually participate in experiments - especially to iron out some of the corner cases.


I also want to reply to some specific comments:


>> If you're a protocol enforcing middlebox (ugh, these shouldn't exist) you should get out of the way.

Middleboxes often need to decide if they want to be a MITM or not on a per-session basis.  This requires parsing the CH as if the middlebox is a TLS server.  It should always be safe to parse the CH, but while the middlebox is in this “server phase” it might receive unexpected data before TLS versions have been negotiated, or before the middlebox has even decided to terminate the TLS session.  I agree that the middlebox should not try to enforce protocol checks beyond what is certain.  Up until TLS 1.3, any record that follows a CH before SH is received was a protocol error.  It was also a possible indication of attack.  For example, many simple attack scripts looking to exploit Heartbleed would send a heartbeat record immediately after the CH, without waiting for a reply from the server.  I agree that the right place to fix Heartbleed is on the server, however there are still vulnerable servers out there, and this sort of protocol validation does in fact help.


>> Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reign to change everything past the ServerHello again.

The questions here were actually with regards to 0-RTT data, which occurs before the ServerHello.  If the middlebox supports only TLS 1.2, and it terminates TLS, is it correct for the middlebox to break the connection when it sees 0-RTT data?  Will this be counted as a middlebox “causing” a failure, because it does not seem like there is another option for the middlebox if it is terminating the TLS session.


>> If any of these happens, you are dealing with Undefined Behavior ...

Indeed, and I can imagine other fields being overloaded.  Who would have thought at the time that cipher-suites would one day be used as backwards compatible signals that can propagate through poorly implemented middleboxes; "random" bytes already have special meaning; unknown record types were used in attacks; etc.


>> However, note that none of the above actually covers 0-RTT. This is because no earlier version envisioned anything like 0-RTT.