[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
- [TLS] Backwards-compatibility of 0-RTT data David Benjamin
- Re: [TLS] Backwards-compatibility of 0-RTT data Eric Rescorla
- Re: [TLS] Backwards-compatibility of 0-RTT data Martin Thomson
- Re: [TLS] Backwards-compatibility of 0-RTT data David Benjamin