[quicwg/base-drafts] Resume HTTP/2 TLS from QUIC ? (#941)

krasic <notifications@github.com> Fri, 17 November 2017 00:43 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0398127011 for <quic-issues@ietfa.amsl.com>; Thu, 16 Nov 2017 16:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.615
X-Spam-Level:
X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 deLxqUHKpHrn for <quic-issues@ietfa.amsl.com>; Thu, 16 Nov 2017 16:43:34 -0800 (PST)
Received: from o8.sgmail.github.com (o8.sgmail.github.com [167.89.101.199]) (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 74087126CD8 for <quic-issues@ietf.org>; Thu, 16 Nov 2017 16:43:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=mALTi5nHRM3yKtEid9Ux5uMK2cE=; b=Nrk9PWPhP1E8fMnD 8/Ono2xAbjWFBZ4JoltYuPhef48ncaGp37MgQAPGUtQ85c/cstq3oUAAYuN6q0Th BvsVIXaCIqT0Vu8+vxDMu0wXcUwF7GqIGSsMpo8CftN/XpFYVGp65xyh5b9SNvgZ tQTrdDFSSmAmFYTEXLjsYTVGvSw=
Received: by filter0451p1iad2.sendgrid.net with SMTP id filter0451p1iad2-10984-5A0E30B5-27 2017-11-17 00:43:33.729402601 +0000 UTC
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id GheKH1IsTlyYxa1YplVNwA for <quic-issues@ietf.org>; Fri, 17 Nov 2017 00:43:33.532 +0000 (UTC)
Date: Fri, 17 Nov 2017 00:43:33 +0000
From: krasic <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6923405f0656b34f405cb8551e9f2ae2da939dc792cf000000011625f2b592a169ce105fcf55@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/941@github.com>
Subject: [quicwg/base-drafts] Resume HTTP/2 TLS from QUIC ? (#941)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a0e30b56a4b3_743c3f937ed78f3812148f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: krasic
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
tracking:
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3/f0RJTO/1COIVeibXGdleeR88tbM344W+6c 3nU8/9k5Oo6r+UGrWlmojAYwefvwWVomK7JbJLh+nSBHFzTVeEfxgwpUm1Q+vh1AqAPUTKmEmK8hXa y/8wlxS/Cl4BSOUCTu7yL1zJ1iNm0PF5vxc+qphB3coNOfW4P4e0MVHznAPpDBAoz/Ov2rK7hJ4KJ2 c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/cTk-lckSUN5jC72VU6ET9Zc5Sjg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2017 00:43:36 -0000

Section 2 and 3 of the HTTP mapping describe the progression from HTTP QUIC advertisement to QUIC connection establishment.

For the very first time accessing an HTTP origin, typical progression is:
   o make initial request via HTTP/2
       - this involves TLS 1.3 handshake
       - client see response contains QUIC advertisement
   o subsequent request to same origin 
        - client tries QUIC, does QUIC TLS 1.3 handshake
        - so two RTTs before first QUIC request goes out.

Would it be possible for QUIC to instead of treating it as an initial TLS 1.3 handshake, but rather  treating the first QUIC request as TLS zero RTT, based on resuming the HTTP/2 TLS session (over QUIC)?   Saving 1 RTT for that case?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/941