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
- [TLS] PR#1091: Changes to provide middlebox robus… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Hubert Kario
- Re: [TLS] PR#1091: Changes to provide middlebox r… David Benjamin
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Hubert Kario
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Salz, Rich
- Re: [TLS] PR#1091: Changes to provide middlebox r… Martin Thomson
- Re: [TLS] PR#1091: Changes to provide middlebox r… Salz, Rich
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yuhong Bao
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Jana Iyengar
- Re: [TLS] PR#1091: Changes to provide middlebox r… Watson Ladd
- Re: [TLS] PR#1091: Changes to provide middlebox r… Salz, Rich
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Martin Thomson
- Re: [TLS] PR#1091: Changes to provide middlebox r… David Benjamin
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yoav Nir
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yoav Nir
- Re: [TLS] PR#1091: Changes to provide middlebox r… Nikos Mavrogiannopoulos
- Re: [TLS] PR#1091: Changes to provide middlebox r… Hubert Kario
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Benjamin Kaduk
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Tapio Sokura
- Re: [TLS] PR#1091: Changes to provide middlebox r… David Benjamin
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yuhong Bao
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yuhong Bao
- Re: [TLS] PR#1091: Changes to provide middlebox r… Peter Saint-Andre
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yuhong Bao
- Re: [TLS] PR#1091: Changes to provide middlebox r… Andrei Popov
- Re: [TLS] PR#1091: Changes to provide middlebox r… Yuhong Bao
- Re: [TLS] PR#1091: Changes to provide middlebox r… Alex C
- Re: [TLS] PR#1091: Changes to provide middlebox r… Eric Rescorla
- Re: [TLS] PR#1091: Changes to provide middlebox r… Alex C