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

Eric Rescorla <ekr@rtfm.com> Tue, 07 November 2017 17:18 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 8E6A2120724 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 09:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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, 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 JoIb1N7bamxd for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 09:18:15 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 C4046132A1A for <tls@ietf.org>; Tue, 7 Nov 2017 09:18:14 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id q1so11527703ywh.5 for <tls@ietf.org>; Tue, 07 Nov 2017 09:18:14 -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=SkGEt2CvOUSK8IDrXHp9+g+Jxpky+t7NyXoGm53KP4k=; b=k+bFTfIOK0juKNC9Z32O1me/kyEFEBpnwtBphiCxANDwJC1uLjxfMbNpSiB7iNbha8 Pcx0ZttZyS7o4Vu2fd8exXQHJSsGrmTX9h5rztwvMKYwKH8UZogGhLCoMG9vHAHLh43D P6zrSuW0PH3K7E0gUWeY58ENd5dh8ZwdXwOpKXfp+6nPlq8cU+bM3lsrTQ7QjL+eosoe VHln408eX6nUQ/0naVZT9/+/TFoC7v9da2RuY3Er4H216miZ4gkwAzlmq+Y41xk+9Hym fifn6obOh7U9LpAF5I/PNLP6g/Q6Bjn0oc5qUBf8wpzlc8vUwmtuJmwvAkZnIulk0cIX dK2Q==
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=SkGEt2CvOUSK8IDrXHp9+g+Jxpky+t7NyXoGm53KP4k=; b=Xv1IDNuOKk0qY59akmA+RGMOPL82S+S1Z3/Wsfqdo3LdD1n4kl5EdjhsD5UmNxqI6a 5xclj0aJF9hFKzKg51G0oLIsNEwBxDC4mC3aEMnxzZXnlw3LaieAXIpXQhLpXH3PVio2 8wiYaKUI7o1a0TgVOJTDkkj7TofTM5qYpeUPgaRituVLmLZbfO6sDO6kCwt4YXr7O+DU 7vNL/xM+2gsHvksSy0p+GMnrfRcfK4FEmJOH45zv0OqIF2W6Y7Divfe+e4VwZ70ytWZt 5G8hIdu3nDUquDg5ETE2TSu20ncxr1iyGmUKJHwT6JaiC3fXAW0DumUz9jh3YKoCmKX2 xeHA==
X-Gm-Message-State: AMCzsaUo/P0cfTq61Vj3mQFG0KJbzdFRxwLtYZeFYojz0VLvFa9u5KdJ Buu00cPAdZ8KLgI6txyt+T6miDNoXSa5KNOpQnuvbwlS
X-Google-Smtp-Source: ABhQp+TuBq/g3O/Zsr/4HPwA+PaCs5vvLUygI3RSdW2EV2mnfe3siVS9uRfIB0EEtb87yVqq1qoMJDjyDsMjlWmRPFA=
X-Received: by 10.37.188.18 with SMTP id i18mr11717046ybh.419.1510075094063; Tue, 07 Nov 2017 09:18:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 09:17:33 -0800 (PST)
In-Reply-To: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com>
References: <CABcZeBNm4bEMx0L6Kx-v7R+Tog9WLXxQLwTwjutapRWWW_x9+w@mail.gmail.com> <4406543.RZChgRkkf9@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 7 Nov 2017 09:17:33 -0800
Message-ID: <CABcZeBOxEAVUAq6+cSD9P+e0VHvgJHvrgj6uENbvf9aWnZooKg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e08247eb490f315055d67c11c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qNcrFNnB10apP7OuAdXFHKTF4bk>
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 17:18:17 -0000

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