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

martinduke <notifications@github.com> Mon, 15 October 2018 16:30 UTC

Return-Path: <noreply@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 9B4A1130EBC for <quic-issues@ietfa.amsl.com>; Mon, 15 Oct 2018 09:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.351
X-Spam-Level:
X-Spam-Status: No, score=-8.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.351, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 SNwNUWMvJR86 for <quic-issues@ietfa.amsl.com>; Mon, 15 Oct 2018 09:30:45 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E24130DC4 for <quic-issues@ietf.org>; Mon, 15 Oct 2018 09:30:45 -0700 (PDT)
Date: Mon, 15 Oct 2018 09:30:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1539621043; bh=3r148xQ5fmj3piKXdkq3zrgfOSNOYXn44jjDCYgvhic=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JB7WTG5P8z78fXPxBrvc9csR1geG2a6wBy1Reo+FD3uTSb+sbOzO4LLe815ZGqTW0 1UAY1MgYAXVWoQF22VzEUvREs1Bj8cFtk7ALX4BnW67g/vbgzCJdi3I73McZ7ApJfT dfWWx1htRnz9pmBFE23lMuPtV9EpF1jAsrcpru1U=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab0ee4034596db02e0b1c1ea8d317806ed5b34970092cf0000000117dc82b392a169ce105fcf55@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/429923070@github.com>
In-Reply-To: <quicwg/base-drafts/issues/941@github.com>
References: <quicwg/base-drafts/issues/941@github.com>
Subject: Re: [quicwg/base-drafts] Resume HTTP/2 TLS from QUIC ? (#941)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bc4c0b3550c6_5fb53ff0356d45c44342bf"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Igzonp5CdiCzl6pX9LVeEBHRNs8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 15 Oct 2018 16:30:48 -0000

> Right now, QUIC operates over UDP but I'd like to think we build HTTP over QUIC implementations that are functional without any knowledge of the protocol under QUIC (e.g. QUIC over CAN bus).

As defined in the spec, QUIC operates over UDP. The question, as I see it, is if servers are able to demultiplex an incoming connection to the correct TLS and application. It's evident to me that we can demultiplex on the protocol number (or, the protocol of the listening socket, if we don't have access to IP header contents).

This helps solve an immediate problem with adoption. I'm not sure that QUIC-over-something-weird is in the same class. If this is the only issue, we can always switch the ALPN code in v2 to support more complicated use cases, once browsers are routinely trying QUIC when they connect.

-- 
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#issuecomment-429923070