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

David Benjamin <davidben@chromium.org> Wed, 22 November 2017 13:02 UTC

Return-Path: <davidben@google.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 223D5129439 for <tls@ietfa.amsl.com>; Wed, 22 Nov 2017 05:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 Yw3YUNC7nI6c for <tls@ietfa.amsl.com>; Wed, 22 Nov 2017 05:02:29 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 BB4B8129436 for <tls@ietf.org>; Wed, 22 Nov 2017 05:02:28 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id j202so16615307qke.10 for <tls@ietf.org>; Wed, 22 Nov 2017 05:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vDDWolFDEfZg4pDmfr5IYtjnGaRKzT09DndaLDG2afc=; b=gwLqByH+aCZCnObXNukDFi4ZurG2uUNvTzD2kXJn/n/P/7ok+CW/08NbS1NZZ/R49C o2hUv2WcEgaByqoz6fHHduDDzBBz5647YZ9gs5HHKpPY5LHQsVU9eRMhRE5EcBcE8WXH UNKMf61ReNgZsMVve1Hl9xDYMa0u7DHjHinIg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vDDWolFDEfZg4pDmfr5IYtjnGaRKzT09DndaLDG2afc=; b=oxdkpK0x1LG53eOZjFUxmiBwd6clPDkXzoSpYaY1CCym1clwadHcdIYol2l5Uw9SUW fSGPeYpfyshoR/sS7agkq6PprtJjtAEjpg6UG9M8Faw/fzWeXwfyTZ4m3stNNc8o0wgm AMJ1Wx2D7URsP6KXN974kyRTI0L8wslwT3dxiXBLBGp4wXiMjNVwvLBr8RCCRiuPYt6H wISzyroKm38rc82o+TqDBaPJlRPfkKx+LC6kbjE0BllmgQtQKlmjkUa/6vtBAkYgXC9s ryxEB+5uwh4YIUmUYNZL2jbxGgLGVFMBsHPiOAmjdNOI5SFgubk1aXRAIfsgMjQHmTSO cJMA==
X-Gm-Message-State: AJaThX7CIIqnbnIqvh1xJq9jmUE3JCSeVC1oKl7aqKEjsU8BWDczWxCF oc5VU7MkQ+2RF3CQVgmo99lu9gHIC6xg7t4SYZL5
X-Google-Smtp-Source: AGs4zMYXEzLthdYyAeN8IyvdfmZ+/KstCBNIq+iZmbgcOcuXZzrc/xoMr7mn3ZxVf/eScAhfawCGo7iL8UUJCuO+dWk=
X-Received: by 10.55.21.213 with SMTP id 82mr33762066qkv.110.1511355747353; Wed, 22 Nov 2017 05:02:27 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com> <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
In-Reply-To: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 22 Nov 2017 13:02:15 +0000
Message-ID: <CAF8qwaC8bJhKoZBraoqM9qTStQxAkouV5=qXXurX8yPMDppV3A@mail.gmail.com>
To: Tapio Sokura <tapio.sokura@iki.fi>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a1147b58474076e055e91eeb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cKItfbjoo8WcxvsZReUNino5QJY>
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 13:02:36 -0000

As a source of some of those numbers, someone interested in actually
deploying TLS 1.3, and, most importantly, someone who would have to deal
with the fallout of that deployment, I can unequivocally say those are not
"very good" figures. They are completely implausible by orders of
magnitude. TLS 1.3, the secure upgrade to TLS 1.2, is not even close to
being deployable today.

Unchanged, deployment would require a unsecured version fallback, the same
one that gave POODLE. An attacker could silently downgrade us to TLS 1.2.
That ServerHello.random anti-downgrade signal would have been purely
wishful thinking and never implemented. I think this would be a huge step
back. A de facto fallback would also send the same signal as tweaking the
protocol. There isn't enough incentive for middleboxes to ship updates or
for administrators to deploy those updates when doing nothing works just
fine. For 21 years, since SSL 3.0, we didn't really change TLS's handshake
and left it all unencrypted. In retrospect, it's probably to be expected
the network latched onto it. Ignoring the problem won't erase those 21
years.

These changes are certainly ugly, but they are only ugly. They have no
impact on security, unlike the fallback which does. There is a complexity
impact, but, having implemented it, the impact is actually quite small.
Making the first server message more uniform between versions and
HelloRetryRequest is even a small convenience.

This is indeed baggage, but that is not new. When I think of the
consequences of buggy middleboxes, I am actually less concerned that our
first roundtrip needs to look a little funny, and more that we are wasting
three bytes in front of *every* record (PR762). That we have entirely lost
TCP and my colleagues on QUIC needed to start over on UDP for improvements.
That even then QUIC ran into ossification later on. That every protocol
change is risky and requires endless experimentation. That the reality of
engineering on the Internet appears to be: if it was observable over time,
it has ossified.

I share the justified frustration with this picture, but it's reality.
There are two questions now:

1) What we do need to do to deploy a change today? (Our handshake
versioning joints have rusted shut, and we need to break them free.)
2) How do we avoid needing to do worse tomorrow? (We've got it moving
again, and we want to keep it that way.)

PR1091 seems to answer (1). (2) is harder. We need to think about how to
avoid ossification. Writing versioning invariants[*] clearly is an easy
step, but text alone isn't enough. Reducing unencrypted portions is also
obvious and valuable in itself, but TLS has a bootstrapping problem here.
We also need to think more in the direction of GREASE, but perhaps further
as GREASE itself only tried to prevent buggy endpoints.

This is a difficult question we won't fully explore immediately, and
solving it is not going to magic away (1) anyway. So I think our first step
is clear: get through the accumulated rust.

David

[*] TLS's versioning rules are quite restrictive. We promise you can parse
newer ClientHellos. Everything after that is fair game to change. If you
produced the ClientHello, you can reasonably assume the peer won't send you
anything that will confuse you. If you are forwarding a ClientHello you did
not produce, you MUST NOT process the response in any way. It will contain
incompatible messages in the future. Alas, reality shows that the network
did not observe these rules.

On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura <tapio.sokura@iki.fi>; wrote:

> 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>