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

Eric Rescorla <ekr@rtfm.com> Wed, 08 November 2017 13:39 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 A58DA126CD8 for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 05:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWCbvrgliZ_j for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 05:39:07 -0800 (PST)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 6DBCF1201F2 for <tls@ietf.org>; Wed, 8 Nov 2017 05:39:07 -0800 (PST)
Received: by mail-yw0-x230.google.com with SMTP id t71so2294435ywc.3 for <tls@ietf.org>; Wed, 08 Nov 2017 05:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mZnkQk0Ry7TE7yBvyiYkxR34Gu5SjCjJyQE5Go3iDPc=; b=WXV0qw34BuETPFe5KHRfTLiSHOjPKKnlqSHLUn8a1ZfiljI6gyCixfkfv3bi9Svl0V tb4k9KN+RUzoAgL0xPrwUqxkKKamAFoCrNLE6a05MpsHFKdBFtP4mu6P2wQbAu73dPKR uDIsvPEHtub6CMjlwajTvPKfKkPl3AvcHx/t31qqNBwN870hCy99/rBSKQDbn2E6BX1m 2YIXkGT3jN0wynumpkb2D2fD+0/s2fr3OG7AwrSYaIcpz0nxlPkmj7x1X5+4XjLh+RFL sUCRVHy7zdyJ1nO3ZWDFl6lbZ/lQ8XLaMqBXfcCv2CWYasKCMG1VNeENSLCFoZuEoKql wI7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mZnkQk0Ry7TE7yBvyiYkxR34Gu5SjCjJyQE5Go3iDPc=; b=tTY9xaLmgnRnJQOOun7yFbx7IQGzEkO/Vcq5Jb6A3NJ9sxF5OCLNNczNowsp/cKLl7 NQk4C03RnLgaRBjCYecc8gUxQofuMHPpw3iSN5wxubY7EwYCD7LODaaJrH/7qNqFlcpU A2R1nn0jaOWOevP1uG8KHN7ERwDBWirk2uZLrbq9mVWtNCTS2Ir6Njk5e/H3e2IniRYL x36+SO3m5pLLcK9Oq/Z4e5zr9yuOQDKrsbONKLEYYBiZElTksz6pnAfwZ9BsDie9T4uS Y0lAkgpiW/5d3efYAAdCfjGSjolTTXUSxbNuBV0FYqj676goARrGg0fqQMMKdRjbD/d1 gLhA==
X-Gm-Message-State: AJaThX7Tb4KCK2ZrngkwZog9tmtrCQUeayeAW78StH/BWSuDP60qD46N +SPxIahGJh+mH82QECj3+WsOcWz+UPl4z4fvUjXcmw==
X-Google-Smtp-Source: ABhQp+S5p6PCgifVk4qLZng0r9eM4x0zyPVdCQzQgB9DbRtw/iSESSvzJ1/5oJkackTmFLuJgXoBImOkNahlynV9yk0=
X-Received: by 10.37.230.200 with SMTP id d191mr325851ybh.348.1510148346690; Wed, 08 Nov 2017 05:39:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 05:38:26 -0800 (PST)
In-Reply-To: <4651345.7yjsJ4Y0gv@pintsize.usersys.redhat.com>
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <CABcZeBNcn8ZyrSLnCSME9aGANwQrydKx4q4Lts6G8pvCSm5hBA@mail.gmail.com> <4651345.7yjsJ4Y0gv@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 8 Nov 2017 05:38:26 -0800
Message-ID: <CABcZeBOzMiiXN-9BU7u+WS8S1qOpB2B1nJvQnuscD=S7VoU3dA@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0afb14c35693055d78cfa4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_4zF4p4dEmuyNFc4dGEasjC7MVc>
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, 08 Nov 2017 13:39:15 -0000

On Wed, Nov 8, 2017 at 4:01 AM, Hubert Kario <hkario@redhat.com>; wrote:

> On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote:
> > On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario <hkario@redhat.com>; wrote:
> > > 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
> >
> > Given that this is (a) not encrypted (b) just discarded and (c) only
> > allowed during the handshake, this
> > doesn't seem like much of a DoS.
>
> same could have been said about the warning alert handling, yet not even a
> 10mbps flow could completely lock up 4 cores of a 3GHz Haswell CPU
>
> yes, it all depended on how they were handled, but point still stands, 2
> major
> implementations got it wrong
>

We already have plenty of places where you can send an arbitrary number
of dummy messages, including the special case of padding-only packets which
we explicitly allow.


and given the information we were provided, I don't see a need to send
> multiple CCS messages
>

Yes I might be OK with forbidding it. My objection is rather to requiring
that receivers
check.


> > 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
> >
> > I might be fine if it were required in this way, but not fine if it was
> > required that one enforce it.
>
> by "enforce" you mean "enforce CCS being sent" or "enforce that a single
> CCS
> was sent"?
>

See above.


And to answer the "Don't the servers control the middleboxes they are
> behind?":
>
> No, they do not. And with B2B communication you never know what will be
> looking on-route on the connection. It's not inconceivable that even a 3rd
> party that is _not_ an ISP controls those middleboxes is involved. Let
> alone a
> different team that has different priorities that people that need that
> connection working.
>
> In the web world you may think that we're already in the 2020s. In some
> enterprise networks people just recently noticed that we crossed to the new
> millennium.
> (I'm of course joking, but the internal networks and Internet work on
> completely different timescales)


They don't have to *control* those middleboxes. The point is that servers
have
a stable elationship with the middleboxes and therefore should be able to
determine
whether they can safely do TLS 1.3 or not and simply not negotiated.
Clients do
not have that luxury.

-Ekr



--
> 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
>