Re: [TLS] TLS 1.3 draft 22 middlebox interaction

Eric Rescorla <ekr@rtfm.com> Fri, 01 December 2017 15: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 D583E1293F3 for <tls@ietfa.amsl.com>; Fri, 1 Dec 2017 07:18:51 -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 WcE6f12ARfw4 for <tls@ietfa.amsl.com>; Fri, 1 Dec 2017 07:18:44 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 C69B21293EE for <tls@ietf.org>; Fri, 1 Dec 2017 07:18:43 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id g191so4147378ywe.7 for <tls@ietf.org>; Fri, 01 Dec 2017 07:18:43 -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=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; d=1e100.net; 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 10.129.222.9 with SMTP id k9mr4212769ywj.47.1512141522932; Fri, 01 Dec 2017 07:18:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Fri, 1 Dec 2017 07:18:02 -0800 (PST)
In-Reply-To: <DB4A1029-DBE2-44D1-97F5-DFFF13BAB52A@nerd.ninja>
References: <DB4A1029-DBE2-44D1-97F5-DFFF13BAB52A@nerd.ninja>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 1 Dec 2017 07:18:02 -0800
Message-ID: <CABcZeBNw+X3YCru+BXyfr_J=_mwNcpp1r5E3-ZGiEUij8xJjTg@mail.gmail.com>
To: R du Toit <r@nerd.ninja>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403043d0488532b70055f48e221"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xCU3ukKfWsTMHOJq5-IbJhOBTA4>
Subject: Re: [TLS] TLS 1.3 draft 22 middlebox interaction
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: Fri, 01 Dec 2017 15:18:52 -0000

On Fri, Dec 1, 2017 at 6:47 AM, R du Toit <r@nerd.ninja> wrote:

> I want to provide some feedback that might be useful to the TLS WG:
> Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org
> 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.

-Ekr


>
>
>
> --Roelof
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>