Re: [TLS] TLS 1.3 draft 22 middlebox interaction

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 03 December 2017 15:56 UTC

Return-Path: <ilariliusvaara@welho.com>
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 3AA641243FE for <tls@ietfa.amsl.com>; Sun, 3 Dec 2017 07:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 eZ46X4-Bvkoe for <tls@ietfa.amsl.com>; Sun, 3 Dec 2017 07:55:58 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5B712009C for <tls@ietf.org>; Sun, 3 Dec 2017 07:55:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DCD8D97B55; Sun, 3 Dec 2017 17:55:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id UW7oHWRhw0mr; Sun, 3 Dec 2017 17:55:55 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2A3BF28E; Sun, 3 Dec 2017 17:55:53 +0200 (EET)
Date: Sun, 3 Dec 2017 17:55:52 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: R du Toit <r@nerd.ninja>
Cc: tls@ietf.org
Message-ID: <20171203155552.GA8097@LK-Perkele-VII>
References: <DB4A1029-DBE2-44D1-97F5-DFFF13BAB52A@nerd.ninja>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <DB4A1029-DBE2-44D1-97F5-DFFF13BAB52A@nerd.ninja>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lp2oP1J8K1fiYSCkz6TWVWL7omE>
Subject: Re: [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: Sun, 03 Dec 2017 15:56:01 -0000

On Fri, Dec 01, 2017 at 09:47:45AM -0500, R du Toit wrote:
> 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.
>  
> Obviously the middlebox will soon have support for draft 22, but it
> does raise some questions:

Some rules are:

If any of these happens, you are dealing with Undefined Behavior
w.r.t. what is implemented, and the remainder of handshake can not be
parsed, because it may have been altered in arbitrary ways.

- The first client message is not of type 1
- The ClientVersion is not "SSL 3.x" (first byte in CH is not 3).
- The first server message is not of type 2.
- The ServerVersion is not known.
- Any unknown extension is accepted by the server.
- Unknown value is accepted in server extension.

For example about just how devastating unknown extension can be,
consider what the supported_versions from TLS 1.3-draft22 does...

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


In certain environments, it might make sense to require ClientHello to
be parseable (e.g., for non-standard end-to-path signaling). There is
much less reaso to try to parse ServerHello.

 
> 1. [...]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.

As noted elsewhere, 0-RTT failures are much less severe than full
handshake failure.

Dropping 0-RTT is not a security problem (in fact, might just be the
opposite). It is at worst minor performance problem. But downgrading
versions absolutely is a security problem.


> 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? 

What are you doing trying to parse ClientHello? And more importantly,
what are you doing trying to parse anything after that?


> 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?

Well, speaking of the library I maintain, I do not have plans on
dropping support for drafts. This includes support for draft-18 (e.g.
Firefox 52 ESR).

However, once TLS 1.3 hits RFC-ed-q, I plan on adding "draft-255"
(TLS 1.3 final; 0x0304) and hardcoding FLAGS0_ENABLE_TLS13 to true.



-Ilari