IETF Logo Mail Archive

Re: [TLS] Update on TLS 1.3 Middlebox Issues

Hanno Böck <hanno@hboeck.de> Sat, 07 October 2017 15:35 UTC

Return-Path: <hanno@hboeck.de>
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 E43D613457D for <tls@ietfa.amsl.com>; Sat, 7 Oct 2017 08:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ddjPqnLogcPZ for <tls@ietfa.amsl.com>; Sat, 7 Oct 2017 08:35:50 -0700 (PDT)
Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09D213490F for <tls@ietf.org>; Sat, 7 Oct 2017 08:35:50 -0700 (PDT)
Received: from pc1 ([::ffff:82.214.239.4]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 07 Oct 2017 17:35:47 +0200 id 0000000000000033.0000000059D8F454.00006B01
Date: Sat, 07 Oct 2017 17:35:30 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20171007173530.34cfc216@pc1>
In-Reply-To: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com>
References: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com>
X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fcE4dmZ0FGCMU-31VNvgd96v-nA>
Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues
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: Sat, 07 Oct 2017 15:35:53 -0000

Hi,

On Fri, 6 Oct 2017 13:16:37 -0700
Eric Rescorla <ekr@rtfm.com> wrote:

> - Fall back to TLS 1.2 (as we have unfortunately done for previous
> releases)

Thinking about this I honestly hope nobody is considering this
seriously. This would be an unfixable security design flaw. And it also
quite significantly differs from previous fallbacks.

There were workarounds in the past for version intolerance by using
SCSV and early versions of 1.3 used some trick with the server random
value. However that was for nonconformant servers that allowed
conformant servers and clients to prevent downgrade attacks.

Such workarounds won't work if we talk about middleboxes, because
what's proposed here is to fallback to TLS 1.2 even if both the server
and the client speak TLS 1.3.

In other words: It's a proposal to make all security advantages of TLS
1.3 irrelevant, as we have a universal downgrade to 1.2.

Given that this would also mean there's no visible incentive to fix
things it would very likely mean keeping this broken workaround for
many years to come.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

v2.23.0 | Report a Bug | By Email