[TLS] 0-RTT, server Application Data, and client Finished

David Benjamin <davidben@chromium.org> Wed, 27 January 2016 00:46 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 0ADAA1A1A92 for <tls@ietfa.amsl.com>; Tue, 26 Jan 2016 16:46:26 -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 8HFaNsSkgUSb for <tls@ietfa.amsl.com>; Tue, 26 Jan 2016 16:46:25 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 C7BFF1A1A90 for <tls@ietf.org>; Tue, 26 Jan 2016 16:46:24 -0800 (PST)
Received: by mail-ig0-x231.google.com with SMTP id t15so72505550igr.0 for <tls@ietf.org>; Tue, 26 Jan 2016 16:46:24 -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=9gUlr6CQ8814qqylfXj1XCBtCkth/cAeIw/SjBM7k6M=; b=hxOTzPNSXb3G4Fm1wkKUXH+BrFxV0eELJahPldewebcf7AmLsBpdeyqVX/bdVKqiNE 00aeww43nwlgITcTxivcDdGOx1ioNG6JGJwgMdA+64u71/FOjvDK5UOZZpUv/n/haPgt XVNEo+peV8HPmNv/tdrFa1vNxFfrFHHpFfpso=
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=9gUlr6CQ8814qqylfXj1XCBtCkth/cAeIw/SjBM7k6M=; b=gVPvc+P/XMonh0b6BTeUrmyfMCdmyRIbet3zjG8HnQXrBPksomL6BLJGMQVOsVttv+ REf57dCM3dkn/RmdLHhI+c6l6ucNB2KCHFdDN6GAVu1M04OBd1lZxXyQGqCIGVF6HdM2 j1enzQYBO5CRRqx/T7IZTbF+kPAq/5bYQnLhvg1Sz9818wq6eOK1KOoZnsSgKgNSa4CQ 2bWpUyfFh2ACQQRUKdqJCm5Mpk6pWs6/YbGPlaRLUStaFjHZyA2nuam6D6Dl3fcGHIBc J0+oAEjZ8jBq+iKRi2W4e/hEFdLn2IRuDFSF7GJtjfFr/6/z/P0ertxz8QJYkJ1j6BRo UrCw==
X-Gm-Message-State: AG10YORjcocqNK83PQO+g9gnG8zHkrhDoyKWfDavpvxI3Jv5ioiStJ783TwafPU+TfwqStrvpCC3ZYk7CPhSle/I
X-Received: by 10.50.8.106 with SMTP id q10mr24899485iga.67.1453855584072; Tue, 26 Jan 2016 16:46:24 -0800 (PST)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Wed, 27 Jan 2016 00:46:13 +0000
Message-ID: <CAF8qwaCty7qjJGobr+god_TDo+q82hZx2FpOitLQ0ANctWBZ0g@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e013c65dca50b01052a4621b1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qCzGsNB166sIbHra4ugajKleWxo>
Subject: [TLS] 0-RTT, server Application Data, and client Finished
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 00:46:26 -0000

It's possible I'm reading the draft wrong, so this thread may be a very
short one.

(t here is in units of RTT, so t=0 is when the client sends ClientHello and
t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is
when the client receives ServerHello, etc.)

Looking at the Zero-RTT exchange here:
https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2

Is the intention that the client, even in the successful 0-RTT case, send
two Finished messages (one at t=0 and one at t=1) and that the server not
send application data until receiving the second of these at t=1.5? If so,
does this not defeat the purpose of 0-RTT? Although the client now eagerly
sends at t=0, it will not see the response until t=2, which is no better
than the resumption case (in TLS 1.2 or 1.3) where the client doesn't send
until t=1.

David