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

Eric Rescorla <ekr@rtfm.com> Tue, 07 November 2017 18:32 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 4E656132355 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 10:32:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 a9NkaZRuqOlI for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 10:32:05 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 B44241320DC for <tls@ietf.org>; Tue, 7 Nov 2017 10:32:04 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id k11so158693ywh.1 for <tls@ietf.org>; Tue, 07 Nov 2017 10:32:04 -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=3BwWvIHlVFPT5uyJB1FLGUAtE8g9eGTN6gD+jG1Rf6Y=; b=ztFYE4zF1b17toHKyKxGidgkwtOYDnQmKrWROP8+RHFR5DREfYDhiJilce6jBeWLes qPNNavA5YQK9OXvsBGbsjkJxZloNGMft6qUylnU4oL5ICVgS5WPMa+a8QNYY1zmXFGXj rxh9AsCNUkXgxfNy9hDhXHY3rt8XDd/beZBpN+rN1o8gZ1ZoJf3YgnFasXDWxuyqrlCo xAPvgaa5ZKY4eiAzN63oaj7sQSPz95x6TNlUnqSf9s5whphaL3bTXjWM61dP5gL2LApy pt5sEV2fudKUrGk+ZLclC8Jy6cPsWI12XU95mYmGhghGiKGigE+6vA44/IG9W40LZdn2 NviQ==
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=3BwWvIHlVFPT5uyJB1FLGUAtE8g9eGTN6gD+jG1Rf6Y=; b=DQpPDrzJfhtlPbzKZY2ch0+5GYoDo0Rz5uL0WgOpC3LMo6mwifxi6awvDezVJ89G/O L58re7VJ+5roq60ARr2SQ69+XCrCzG28yN5DZ0VEpiMv4bQhXO2W1cX8WKw1VtFQfZYp FkQ0a+sixJn9qIQwGe068X8c7mDOccVsnKHRPd8+hbzACsw4p3DQRIaeWlczM/oVM60K Gk2Ylv+/JkIkhPAU0OFDmq7BymhcO7uPF6F3w5bIzFOp0WAxoWBcoJt0hAOShadFbdZw UvDk6EuwsCC8syEzghRFlHrUDkqvMbvFM4MbWVjteXZLzimeqNAG1aobAnmRTi7hUXH2 /gyw==
X-Gm-Message-State: AMCzsaWmm4ej5FWy1tTWvnqXYVJGjjUQ1kimihXtZJaNIt78P8SwJh2j 4A4xiP4BzEDewy85eP001YPUUxTcE/7C+cotuJbaDq2x
X-Google-Smtp-Source: ABhQp+Q0oNplqLGHS16gE+3o5DeO8y8oGKmyE/UqFzjILi0D/CrL+aqRCNaa8ldD/z5AqB+xgLNqEXh9JFtb/q3Nuso=
X-Received: by 10.37.195.65 with SMTP id t62mr12153053ybf.71.1510079523997; Tue, 07 Nov 2017 10:32:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 10:31:23 -0800 (PST)
In-Reply-To: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com>
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com> <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <CABcZeBOxEAVUAq6+cSD9P+e0VHvgJHvrgj6uENbvf9aWnZooKg@mail.gmail.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 7 Nov 2017 10:31:23 -0800
Message-ID: <CABcZeBNcn8ZyrSLnCSME9aGANwQrydKx4q4Lts6G8pvCSm5hBA@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d7db29c5b79055d68c97e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rfURZxZ1V82LSf7oi0lViOGz8lU>
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: Tue, 07 Nov 2017 18:32:07 -0000

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.


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.

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