Re: [TLS] PR#1091: Changes to provide middlebox robustness
Hubert Kario <hkario@redhat.com> Tue, 07 November 2017 18:11 UTC
Return-Path: <hkario@redhat.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 DD7B6132939 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 10:11:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 6mAqTEooUqFY for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 10:11:26 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B85126B6D for <tls@ietf.org>; Tue, 7 Nov 2017 10:11:25 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7360EC04AC49; Tue, 7 Nov 2017 18:11:25 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7360EC04AC49
Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1B85E60BF2; Tue, 7 Nov 2017 18:11:25 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 07 Nov 2017 19:11:17 +0100
Message-ID: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com>
In-Reply-To: <CABcZeBOxEAVUAq6+cSD9P+e0VHvgJHvrgj6uENbvf9aWnZooKg@mail.gmail.com>
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com> <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <CABcZeBOxEAVUAq6+cSD9P+e0VHvgJHvrgj6uENbvf9aWnZooKg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart7419152.k1SlU32ZQM"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 07 Nov 2017 18:11:25 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/u1zxfcT96i_fVai9pg8UTb03gRs>
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: Tue, 07 Nov 2017 18:11:28 -0000
On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario <hkario@redhat.com> wrote: > > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > > failures as rare as possible is a good way to make that happen. > > > > that being said, I have few comments: > > > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > > > As I mentioned a while back, we've been seeing evidence of middlebox > > > intolerance. I just posted PR 1091, which is based on a bunch of work > > > by the BoringSSL team and an original suggestion by Kyle Nekritz that > > > should significantly decrease the rate of these errors. > > > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > > resumption. The major changes are: > > > > > > - Move version negotiation entirely into "supported_versions", and hence > > > > > > ServerHello.version == 0x0303 (TLS 1.2) > > > > > > - Restore the missing session_id and compression fields in ServerHello > > > > less special cases in parser code - big +1 > > > > > - The client sends a fake session_id and the server echoes it > > > - The server sends ChangeCipherSpec messages after > > > ServerHello/HelloRetryRequest > > > > > > (so that the middlebox ignores any "encrypted" data afterwards), > > > and the client sends ChangeCipherSpec after ClientHello. Either > > > side has to ignore ChangeCipherSpec during the handshake. > > > > That's the part I have a bit of a problem with. > > If the CCS is necessary to make middleboxes work, and given that > > lack-of-CCS- > > intolerance is not something that we can detect reliably (not in a way > > that > > can be simulated by an attacker), I think the CCS should be baked in the > > TLS > > 1.3 as deep as it was baked into TLS 1.2. > > You don't detect it on an individualized basis. Rather, you measure whether > it's > necessary and if/when the necessary level of CCS becomes low enough, you > just stop sending it ever. > > > That is, the standard should make it a mandatory message to send, fully > > parsed > > and validated, requiring aborting connection if it is received at any > > unexpected moment, in duplicate, omitted or malformed. Not only as part of > > the > > "compatibility mode". > > Yeah, I'm not enthusiastic about this. It's more stuff in the state machine > that > we hope to eventually eliminate. And as David says, it's totally unnecessary > for QUIC and DTLS > > -Ekr what I was getting at is that if you want to be compatible with middleboxes, you send that CCS always, as you never know what thing will be between you and the peer that means that all the large implementations will be sending them always that means that new middleboxes will likely end up expecting it either way and existing ones won't have much incentive to update/fix secondly, if we allow for sending CCS at any point, we will end up with the same bug as the Alert processing DoS there was in some implementations — one that allowed the peer to send unlimited amount of warning alerts so even if we mark it as optional, I still think we should allow for it to be sent at only very specific moments and only once per side -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- [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