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

David Benjamin <> Tue, 07 November 2017 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23CD8132D41 for <>; Tue, 7 Nov 2017 08:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TSeuh0FJ5GAl for <>; Tue, 7 Nov 2017 08:59:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0136313295C for <>; Tue, 7 Nov 2017 08:59:34 -0800 (PST)
Received: by with SMTP id k31so16051660qta.6 for <>; Tue, 07 Nov 2017 08:59:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u2NryuciW4MxfWUlvGpB8bsFD+P2RpVCyP5jXj2vsY8=; b=loWYDD3IoAgzN9oocE7/lnno3ouGtYXGaNN07dKjE3idt6TcvEC6xwVq/9rdIW5KwD nqJf2fswCYtrpq+A93h5M0eQT/zRj2nqMSmF2IJVnxH6I766BJXJfHhsWeUIUj+IYywu NZNUzVa/zNo5QZbOcsJla+Qsfg1IVj24G6qh0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u2NryuciW4MxfWUlvGpB8bsFD+P2RpVCyP5jXj2vsY8=; b=DnIc1H6DAGMdV8VJtxXC2OKv+GA9fs99zLPJaqguJsRp1cg4Gd/UHIjgvz3QVZTudi l9Qs0SIHtZrRTD5/14ZBSIJ9geLsWWECf9nGZmX4/D/4dEcd1+6SaUgrG+BGx5kX47D1 IbbK5lzcBpLOG7MPvCSLj8nhH7vJH4dp/w1xR8X+DsK42GeaPGqg0EJHDINwcQh1ilzD aAa8kGIWDaMyhEA3Hm88+And6J0rml5jbYx9CvbsqvjnZB5HWYQWzwzpsK5cp+s1dIvr mkZAcdzwhD5NzWqZS+lBzRNAN64HX7gz6aAHQuU2GR5dtBDdcZEovMIEuOLaV8jnfi37 eqxQ==
X-Gm-Message-State: AJaThX7Exw2u/GH5SpCxRi4KtYrz4J5C1apwcyYHEz0Aueo5y+1vnhBI Da1079NDwdGjPkhYWV1e0fFUpXt9NkNkSjE8J97s
X-Google-Smtp-Source: ABhQp+SKquxDsl0KFFm5XmkXnpbskHWwywv/BOAkPUky3VumURKcCEULZ57UU/EJ/GbaOVlI/6MSf7sbgMnVi/6Xrc4=
X-Received: by with SMTP id t22mr30097722qtb.117.1510073973934; Tue, 07 Nov 2017 08:59:33 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 07 Nov 2017 16:59:21 +0000
Message-ID: <>
To: Hubert Kario <>
Content-Type: multipart/alternative; boundary="001a113b908ecd94fe055d677e38"
Archived-At: <>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Nov 2017 16:59:37 -0000

On Tue, Nov 7, 2017 at 10:53 AM Hubert Kario <> 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:
> >
> >
> > 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
> 1.3 as deep as it was baked into TLS 1.2.
> 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".

Having the receiver check would work for us (it's what our prototypes do).
And it's true that, were receivers to enforce this, it would be more likely
that implementations reliably work in these environments despite not
testing against them directly.

But we got feedback that this would be too much complexity for some folks.
Getting CCS/handshake synchronization right is a little subtle. And indeed,
I think CCS in TLS 1.2 was generally considered to have been a mistake.
Having the receiver ignore CCS also allows use cases without this kind of
baggage (consider QUIC's embedding of TLS 1.3) to unilaterally disable this
compatibility mode.

So I think I prefer the formulation in the PR.

> > - 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.
> So I have this crazy idea... What happens if the first message sent by
> client
> and server is the CCS?

We didn't test that variant, but we did try turning off the
client-generated session ID to see if that was necessary and it was if I
recall, the failure rate without that was comparable to draft-18 if not
higher. Additionally, we know that making the record layer say TLS 1.2 was
necessary once we made ServerHello.version say TLS 1.2. (We'd have had a
proposal for the working group sooner had we not missed that difference
first time around! :-( )

This makes me doubt just sticking a CCS in front would suffice. It suggests
that middleboxes are actually parsing out TLS more deeply than that. Which
is also what one can expect. I think the clear conclusion one can draw from
this issue and similar elsewhere is that every reliably observable property
of network traffic will, over time, become ossified. The Internet is very
change-averse, and TLS 1.2 gave it far too many bits to latch onto.

> > 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.
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web:
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list