[TLS] Backwards-compatibility of 0-RTT data

David Benjamin <davidben@chromium.org> Wed, 27 January 2016 02:02 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84981B3365 for <tls@ietfa.amsl.com>; Tue, 26 Jan 2016 18:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 iIkx-EU5RUX7 for <tls@ietfa.amsl.com>; Tue, 26 Jan 2016 18:02:49 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 5D0E41B3351 for <tls@ietf.org>; Tue, 26 Jan 2016 18:02:49 -0800 (PST)
Received: by mail-ig0-x22d.google.com with SMTP id mw1so2680936igb.1 for <tls@ietf.org>; Tue, 26 Jan 2016 18:02:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=E6dYZvSgcpFb0Qf7zxd2skQo9DXcmSCknP1taE5AALg=; b=jBpugMvatd1cm1dMSK3xt0nV3yu5AMLilMwetHnjHuYXbDiTCbOuL9xUXT5cZJNrHW hcMauNIM0SoPtE+pSVyRoowZBTKvyH1BsAsI7rj8jZhSy2qmcncqP6z5JEedxSdcrHdG hhBQ6dgOfpsyF2vGwZLzdMZnB/YcEbdimgVhA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=E6dYZvSgcpFb0Qf7zxd2skQo9DXcmSCknP1taE5AALg=; b=MBFBGK/yqovzbo6uUv5+2eZ7TbWtS5vRjnTpIHukaPRE2VTYCj5+MkyVCgGUOPf9Iu 9OUAIyZXyCdvbnnZoIYC21lMbzj8ToSfUxNoaAB97LzL/Hrt3kVPyxcnJjspTI8xeV0g m72sa2DlF/4HJFob2y/0D5WE4p9OOn8cb1DUeG+2m6WcavkIV66YpUNHJ4JIKG0Jm5// 7N7HQyumqsCSws8z7BoPRz2eqxHeWmQTw7vW0WxSOectz6/K0K46Q7xoZEJZMLVbBJ5P PTHg2XuZOqV9SdPo01XfF58IzetNLec7KlHbW9CEvqrMB7WlOfcWNIQv1jfSH+5XQqh4 pLMg==
X-Gm-Message-State: AG10YORyYouCtREcYA5baqZQTZ2yWOSqeOWpECrQe43vqFfLMDes7+4JtI2p2ygcmsISDNAy2s3EqJSVfuDWJuh1
X-Received: by 10.50.171.200 with SMTP id aw8mr27929953igc.77.1453860168751; Tue, 26 Jan 2016 18:02:48 -0800 (PST)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Wed, 27 Jan 2016 02:02:39 +0000
Message-ID: <CAF8qwaDTU=f6UO=NY4SeKxR+yDrrOeuLCq2UKUoU_iFhFOzGVg@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e010d9562e9ae6e052a473234"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sou0Kz8WRG88YgyZnG7XRyindZw>
Subject: [TLS] Backwards-compatibility of 0-RTT data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 27 Jan 2016 02:02:51 -0000

Instead of putting 0-RTT data in a ClientHello extension, the current draft
has the client send extra records in the first flight, right? (I see an
early_data extension, but it seems only be an indicator. There's also
mention of requiring trial decryption which only makes sense if it were
appended.) Was there a reason not to put it into an extension? It's uglier,
but the current scheme has compatibility risks and may force clients into a
fallback dance.

Although a TLS 1.3 client won't make 0-RTT handshakes to a service until
it's managed to speak TLS 1.3 to it once, services aren't made of one
machine. Many services span multiple machines, changes are deployed
incrementally, etc. Even single-machine services may need to roll back a
change. This kind of statefulness means that one cannot enable 0-RTT on
*any* machine until *all* machines in the fleet have enabled TLS 1.3. And
TLS 1.3 may not be rolled back once 0-RTT is enabled (at least not until
all server configs have expired).

I would not expect all deployments to get this right. Large companies with
TLS experts might, but most people will idly take updates from their
operating system with (hopefully!) TLS 1.3 and 0-RTT enabled by default.
They won't realize fleets must "set" at TLS 1.3 without 0-RTT before
enabling TLS 1.3 with 0-RTT.

This is the same flavor of problems in session resumption that motivated
https://github.com/tlswg/tls13-spec/issues/136. That bug wasn't
hypothetical. At the time I filed that issue, https://www.debian.org was
two wildly different servers. One spoke up to TLS 1.0 and the other up to
TLS 1.2. OpenSSL on the client has some bugs around resumption which gives
similar version stickiness effects. Until I reworked the version
negotiation code, Chrome + BoringSSL would fail to connect sometimes.

Having the 0-RTT data delimited in the ClientHello should hopefully also
avoid the trial decryption step on 0-RTT miss which seems kind of silly.

David