Re: [TLS] PR#1091: Changes to provide middlebox robustness

Tapio Sokura <tapio.sokura@iki.fi> Wed, 22 November 2017 02:40 UTC

Return-Path: <tapio.sokura@iki.fi>
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 D9E12129477 for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 18:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 uvexhRnmGEvq for <tls@ietfa.amsl.com>; Tue, 21 Nov 2017 18:40:57 -0800 (PST)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0273120713 for <tls@ietf.org>; Tue, 21 Nov 2017 18:40:56 -0800 (PST)
Received: from woodstock.owlhill.net (a88-112-88-23.elisa-laajakaista.fi [88.112.88.23]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id D16DA40089 for <tls@ietf.org>; Wed, 22 Nov 2017 04:40:53 +0200 (EET)
Received: from [192.168.0.158] (dhcp-158.owlhill [192.168.0.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTPSA id 65D2CC7CF65C0 for <tls@ietf.org>; Wed, 22 Nov 2017 04:40:53 +0200 (EET)
To: tls@ietf.org
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com>
From: Tapio Sokura <tapio.sokura@iki.fi>
Message-ID: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
Date: Wed, 22 Nov 2017 04:40:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CeeM1F1s-VssieHNZJ3mxGsHPSk>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
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: Wed, 22 Nov 2017 02:40:59 -0000

Hello,

On 6.11.2017 20:19, Eric Rescorla wrote:
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.
> 
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).

The discussion in Singapore on middlebox issues during the WG session 
woke me up on this. I don't post much on this list, but here I have to 
say that this dance to work around middleboxes looks seriously like 
putting the cart before the horse.

I'm not arguing that the cryptographic properties/security of TLS 1.3 is 
affected by these changes. I'm saying that this messing around with 
making 1.3 look like 1.2 adds unnecessary complexity that will just hurt 
everyone in the long run. In the short term you get a few % more 
successful 1.3 handshakes, but once it's in the spec, it will bother 
implementers for years to come.

Sometimes you have to let some things break to be able to move forward. 
If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes 
already go through without 1.2 emulation / middlebox compensation in the 
protocol, I find that a very good number for this point in time.

It's the middleboxes that should adapt to be 1.3 compatible, not the 
other way around. This is not sending a good signal to the industry.

Sorry if I'm beating a dead horse (behind the cart). But my 
interpretation of the comments made during the WG session indicate that 
if there's consensus on incorporating these middlebox compatibility 
changes, it's a very rough consensus.

   Tapio