[TLS] Update on TLS 1.3 Middlebox Issues

Eric Rescorla <ekr@rtfm.com> Fri, 06 October 2017 20:17 UTC

Return-Path: <ekr@rtfm.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 89CBF132195 for <tls@ietfa.amsl.com>; Fri, 6 Oct 2017 13:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 KsAY4ydH76qr for <tls@ietfa.amsl.com>; Fri, 6 Oct 2017 13:17:18 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC7A134C8F for <tls@ietf.org>; Fri, 6 Oct 2017 13:17:18 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id k1so22622491qti.2 for <tls@ietf.org>; Fri, 06 Oct 2017 13:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6692tIeuoSA0pdAD1SkU3jiTWzgz2NF292CtVyWylno=; b=cNcV4i/Px3J+5dtly4/K/H72fZCRqsNHHHMVPNcJY3GSKCC+J/jPKTsL9DAA79cys+ KWxzg6C0se7SqdjpuuvysN2HZcbzcfzDt+JrPWcLsV1xrsCX1OTeIyvjhC+Io0qm+Ak/ uooA4QcsxL8RB2VGKvnb0bbKl2DVoenCBmuAmntdaiGJHeDuva89t8XdWKzlZPfu3G7P cGQkNq8be7yle7xVHA2bf0FgIFXw8ecDpJWU82yBx45vdEyye/NFhaHoN0gCVGlE2aUq I4+KlBa4EbWXkX6Le+/QiLKuxfU7QxgweJCnjfkUPHTwJr1PrTuASq0P3if/Nprm6Zp7 bLjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6692tIeuoSA0pdAD1SkU3jiTWzgz2NF292CtVyWylno=; b=jTZbf53BhZx9cAz0zQj6Z3kM9x9TQ46wModHk6UeTDE4JB3Ij1MCAjlLcCkRmJewqi yjcnTdn0YbsvyNpEE4JSLHjD5Ah1cY+F/rzlKRXM/FLf2DCJ3E3QsclmozC8PgNpDnE1 pWMMfTX+72RF0HFSKF8nEXGtGfKedSHboFhGCjwR64ltFRwKDPSoqgEp7He2gqm77W+5 CRa6UkfeqSr5Dyv7Yf+jlimBjsPECTVxxaZNtjfVxg0zjhc1e+2lQsutP0evtMtmbOIP MmeE1hxseZ8ze5AgebVdrsrc6RBjtcxs735wHFxkn3JS5APfh8FD/XT99W4PkJt0sR9Z rrvg==
X-Gm-Message-State: AMCzsaWa224LNFzMhPDYDi1ODSY8dioqMKiVSjEAdyfhlTnrd5eKpvzV Fgk+EJsINqKjMZv9jI8+q5w1zv5OzODWfNe2+pkTVMn7
X-Google-Smtp-Source: AOwi7QDRFvswS6H2izJ6NwbQIxLZFxNn/0hyidOS5RNmGhtpmKgP/fS52aT+ZKzuDVKvctys5EUUfBkYdDgNr95k/zY=
X-Received: by 10.37.105.203 with SMTP id e194mr2553410ybc.71.1507321037644; Fri, 06 Oct 2017 13:17:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Fri, 6 Oct 2017 13:16:37 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 06 Oct 2017 13:16:37 -0700
Message-ID: <CABcZeBMoW8B78C5UmLqAim4X=jQ8jVRYTP-L7RVnU3AScdFvFw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c14ebc80301ff055ae687bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yt4otPd5u_6fOzW02TEe2e-W5G0>
Subject: [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: Fri, 06 Oct 2017 20:17:20 -0000

Hi folks,

In Prague I mentioned that we were seeing evidence of increased
failures with TLS 1.3 which we believed were due to middleboxes. In
the meantime, several of us have done experiments on this, and I
wanted to provide an update.

The high-order bit is that *negotiating* TLS 1.3 seems to cause
increased failures with a variety of middleboxes (it’s generally safe
to offer TLS 1.3 to servers which don’t support it). The measured
incremental error rates vary quite a bit, ranging from minimal
(Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using
a slightly different methodology (organic versus forced traffic) and
different populations (mobile, desktop, enterprise, etc), but it does
seem like there is a nontrivial failure rate. At this point, we have
two options:

- Fall back to TLS 1.2 (as we have unfortunately done for previous releases)
- Try to make small adaptations to TLS 1.3 to make it work better with
middleboxes.

The Chrome team has been working on angle #2 and has been having
success with an approach of trying to make TLS 1.3 connections look
more like TLS 1.2. Their current experiments get them down to about 1%
incremental failures and they are currently measuring some changes
they hope will shave that down more. These changes are a bit annoying
but basically superficial; they do not affect the cryptography.

Separately, Firefox and Facebook have been experimenting with the new
content type described in PR#1051 (Google’s and Facebook’s results
conflict, so this is a bit of a mystery). We hope to have results from
both sets of experiments by end of October, at which point we should
be able to discuss the best way forward as a group.

-Ekr