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

Eric Rescorla <ekr@rtfm.com> Mon, 06 November 2017 18:19 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E84F213FC5E for <tls@ietfa.amsl.com>; Mon, 6 Nov 2017 10:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rJ65_csmH6Ys for <tls@ietfa.amsl.com>; Mon, 6 Nov 2017 10:19:43 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 69F1813FB8E for <tls@ietf.org>; Mon, 6 Nov 2017 10:19:43 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id k11so8641208ywh.1 for <tls@ietf.org>; Mon, 06 Nov 2017 10:19:43 -0800 (PST)
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=6Qcc8GEY4rFzaDKxwlryb1dILLqxGqhguGrcBbzT/cU=; b=mUwxjejxeH5U7kDZl84YvIwSbov8DJBWo141wSYNKJEqFQjSLm3xKGXJ/iVM0ngmXH avNvikW9k6FyRs62uW9DMZWaZWG6aLZj0koMPvc1iDqnUS2OmR8h4AUz/gMpc717crrj KtIyyn1sKjR3XP+KNsLN20FI7W0biaEx6QasNUvQa5LxTO068ShroqwT2d1dYhjI8apZ q8TPF0NoOSD8PVzRvkEIc8rsWN+LnSt8MTMQoutdrS7JSjSQlQ+aatWBG/YaS24RTjol EMRRuh6Qz0Ul7MeELyWMZZdiz+rKhBBS2Nnzat8j6CVI4h2/qAqZXsL0LwnBE+3dVu4X IX5w==
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=6Qcc8GEY4rFzaDKxwlryb1dILLqxGqhguGrcBbzT/cU=; b=CtPb31eAtxS8I9zFmjqWteDKzZUYkwb1MBSLrms5ZbpKDOtReHA7/JZAs8HhIrT29h 7zbfM2a3HBU155AUY7qHO54Qmm7NkpquR6oUqaGQfVRWd9Ad6opPqGylP1yQyVYe8ZoJ LgCzxz0Xn7Wesz0XDwtDvrgPt7n3VNiT5O2cEzYats488WM8NnSNLZ5H/Wt0ID+nJWe3 cErAJDxmZ8HIHrvop7QKGU1jjLz/b7xQvG+FXAKXtMnFM9SHnHpwjpPoj4Qe0xIMTB++ Y9gVO8vLHU225Oyo0GpJSvovACSMEWvyFTD9JWyeIIrIMrCImCRkLzKEJm97J5OJQUjl GXWw==
X-Gm-Message-State: AMCzsaU8jBOi/tPM8A4lnupAaSEl8Hdb8kKiOTaP11fkDPKD1h8o+56c 95KS19S680DC2ocbVr6SGXc7yxOuysNUkFGSu5DfsNHum14=
X-Google-Smtp-Source: ABhQp+RNpbHDm/zTkzA5EiVLJqfAaJcrtLjXbRE/Feu96SHpL2CkeBkLj7meWceuIG0LVaaCEK8gAXvuNTfJwlgzeAE=
X-Received: by with SMTP id t62mr10037301ybf.71.1509992382288; Mon, 06 Nov 2017 10:19:42 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Nov 2017 10:19:01 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 06 Nov 2017 10:19:01 -0800
Message-ID: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d7db28f671b055d547f8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KTGrScK0h2kYvhegeI3rPVeL010>
Subject: [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: Mon, 06 Nov 2017 18:19:45 -0000


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
- The client sends a fake session_id and the server echoes it
- The server sends ChangeCipherSpec messages after
  (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.
- Merge HRR and ServerHello into a single message with the semantics
  distinguished by a special ServerHello.Random value.
- Switch the record layer version to 0x0303 for post-ClientHello
  messages to match ServerHello.

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).
Several of the most unpleasant changes (sending fake session id and
sending ChangeCipherSpec), are only needed in compatibility mode,
and if you don't have to worry about middleboxes, you can just
omit them.

There are implementations of these changes (except for HRR) in both
BoringSSL and NSS, and Google has preliminary measurements with these
changes that show comparable error rates to TLS 1.2 (I expect them to
publish those shortly). We expect to have further measurements from
Chrome as well as from Firefox by the WG meeting.

Please take a look and hopefully we can close on this in Singapore.