Re: [TLS] TLS 1.3 draft 22 middlebox interaction

Eric Rescorla <> Fri, 01 December 2017 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D583E1293F3 for <>; Fri, 1 Dec 2017 07:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WcE6f12ARfw4 for <>; Fri, 1 Dec 2017 07:18:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C69B21293EE for <>; Fri, 1 Dec 2017 07:18:43 -0800 (PST)
Received: by with SMTP id g191so4147378ywe.7 for <>; Fri, 01 Dec 2017 07:18:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=567P87Ee+4zCJLbWd0ZyiLgVzNlxGEgh30j+GyyrO9w=; b=1x/UtIAccmIbmNQFle3eK1mZncxqWTucGg0faR3VssDASoUVwkPnSNaVJ4sopjuYFR o43zoq3w9zvEgg8Rq46t9dxaTd7Tg/EoPF8R+HAdRqb1fgU+AFFevyGIEnHlhMCV3rnZ oouWfHcbpFaKM/CvGLA8TyMvpxudJ3rgmZkmKKZC2C7bRipmU0GSwAaHkuyMm6H/DTih wZpvC2WUzlfB3SYdJkj1DP5If9sX0BF4jvOrRyuSAPLJs95dqMr8LrtMEJJLKGATlGOx EXF24ozMaFArhvNmWKPf9IRMnn84kf0hdUzbU3SReuaCL/kX6xI4idGDwl1E9apyEuUv LxSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=567P87Ee+4zCJLbWd0ZyiLgVzNlxGEgh30j+GyyrO9w=; b=SHmqqQlYvkC0cxhMT3PTSdQCSxv4JICD+zRqgX0uSAF7RBwrcgUTIcYshsqKZeKZDo ENixiiukbL4pMl+h5SUPtSGGjR4q1J5aa025CitNDVUgmbNqrlIJ0WjPCO2581QWJ106 2RnJvzylwoVUDRitTxQFo4+eaK23baZdeJX3Sjn7yLKbpsw+PVz20zSK/tDpmJR+i12Z sVetZz7f2LOZxxqR2nYntTCUg/b88afvdXSTJDh0L9kiKUYszdv8Kc6nT6GShRvcxTav nNGw3b4l9eJyBsVGi0iKHtPKzHZgsZmd0gooITDRu59A6xtCm4mH7wN454GFFKrrwpuC 4kCA==
X-Gm-Message-State: AJaThX4UJ83O4pIyefwMa5bv2/ZRatbsMmswW/ydsk8Hv0uBhTOguLQQ tTnlOkkiG8jKegUNA43IBvgg33zU8O4VmkrTDl+1M0rF
X-Google-Smtp-Source: AGs4zMZxlWsfZnCJ/mIWMydzRbFj1KvKHlzef7s05gHXP9WoXPUEFjKqZmoh+MJOKShg7n5nCMkJgln7hXTb7vLVW9g=
X-Received: by with SMTP id k9mr4212769ywj.47.1512141522932; Fri, 01 Dec 2017 07:18:42 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 1 Dec 2017 07:18:02 -0800 (PST)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Fri, 1 Dec 2017 07:18:02 -0800
Message-ID: <>
To: R du Toit <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="f403043d0488532b70055f48e221"
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction
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: Fri, 01 Dec 2017 15:18:52 -0000

On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <> wrote:

> I want to provide some feedback that might be useful to the TLS WG:
> Firefox Nightly TLS 1.3 (draft 22) sessions to
> is triggering an interesting failure in at least one middlebox.
> The middlebox in question supports TLS 1.3, but only drafts 18 through
> 21.  The FF Nightly ClientHello *supported_versions* extension advertises
> support for TLS 1.2 and TLS 1.3 (draft 22), which the middlebox then
> interprets as only advertising support for TLS 1.2, ignoring the 0x7f16 as
> if it is a "grease" value.  The middlebox only perfoms protocol checks and
> does not actually modify anything - the session completes without any
> issues, which shows that the draft 22 middlebox measures are effective.  FF
> Nightly then starts a resumed TLS 1.3 (draft 22) session that includes
> 0-RTT early data.  The middlebox performs a protocol check on the
> ClientHello and determines that the client is trying to negotiate TLS 1.2
> (per the logic of the first session).  Shortly afterwards the 0-RTT AppData
> record arrives, which then triggers a protocol error in the middlebox.
> "D.3. 0-RTT backwards compatibility" of the draft 22 specification
> describes the problem, but in the context of "older server" being "only
> supports up to TLS 1.2".  This particular middlebox can also be thought of
> as "older" because it only supports TLS 1.3 drafts 18 through 21.
> Obviously the middlebox will soon have support for draft 22, but it does
> raise some questions:
> 1. I understand that some of these transition effects will go away as soon
> as draft support is replaced with actual 0x0304 support, but were 0-RTT
> sessions used in the recent TLS 1.3 middlebox resiliency experiments?  The
> scenario above shows that some middleboxes might (by luck?) not break full
> TLS 1.3 sessions, but those same middleboxes might fail with subsequent
> 0-RTT early data.

We haven't been testing that. I do expect to see some 0-RTT bustage, but
falling back to a full handshake at that point isn't a security issue, and
so can be handled in the conventional reconnect way. We (Firefox) also are
looking at testing for middlebox compat explicitly and turning off features
like 0-RTT and TFO (which we already see problems with) if needed.

2. Should middleboxes that understand the *supported_versions* extension
> get out of the loop immediately (as in ignore traffic after ClientHello)
> when it sees 0x7fNN, where NN is larger than the highest draft version
> supported by the middlebox?  How would that be different from other
> "grease" values?   I understand that this might just be a temporary measure
> until 0x7fXX goes away (hopefully soon!).

First, they shouldn't look at #s. Second, it depends what kind if middlebox
you are. If you're a protocol enforcing middlebox (ugh, these shouldn't
exist) you should get out of the way. If you're a MITM device you should
just negotiate a lower version.

> 3. Is there a plan for phasing out draft support once TLS 1.3 is finalized
> as RFC?  Servers can stop supporting 0x7fxx as soon as 0x0304 is ready, but
> what should a middlebox do if 0x7fxx is seen post RFC?

I would expect people to just signal the RFC version relatively shortly
after RFC. That's what we (Firefox) plans to do.


> --Roelof
> _______________________________________________
> TLS mailing list