Re: Hidden connection spawning
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 26 July 2018 17:28 UTC
Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F3130E53 for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 10:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.003
X-Spam-Level: ***
X-Spam-Status: No, score=3.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f3rrKF5vkWm4 for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 AD049130E0C for <quic@ietf.org>; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id w16-v6so3873076ita.0 for <quic@ietf.org>; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yeW8NMB1mSf9bis/1cohTYduuvzZdK/VwQ8/GOSnd6w=; b=Z73Tns15DKsgkbbLbR1IwE97Ddjtqb37fTmEiiE8zVt9Bp92dRgXcAiKsSTFei/5vB NWUD1LEvMOqcpOjqviCnUgvDRvn9cDuVgaJJnuOKnP/QbVLsFjAIEm8L/sXmT2QP6W0i my1M7xEZGYsqqb9/jgDclakA0tsTsa0AilBU2lC2FeoEwQi+nF+K+BA30hDaulW36QUv HStJpG5q86uClKyCBfLU9G4pmiR7/+uT9eXFSHGHUocX/RoB67oLmcB1iSmhl+mk/x+M f7EeWbH3kOc+FAEv4mO5hWQDg4pjkGXlfENBz1Qo1C1/nsjUcpdvzkMTr7f2l/CRhM0D zvIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yeW8NMB1mSf9bis/1cohTYduuvzZdK/VwQ8/GOSnd6w=; b=LXiTwIdnGcTA6fuqON4PvC+nCE5gL7zpbJcwaE06WeXp/ow8gcU9vr8YtA1wsNkujR uZBDsCHXfj2Yv3N4Qbwj7DlJXvYjptA1pnyjz4x54ATq97ZuafY0leho3YN8dLmJD33Q dppn2S0JR1bGNBuFUOUQoPao9OKGUq5zfD/pFOUp05GZgkzuFIr3/7AsyO53441PW0DL PyTaoBRF1ZLINTO0nBeory31RcKH8wOO5UWDxNxpUq2FdPvCURmqV2CGrXOzqY2Waz/4 TGSimsMStc9vFFmQsW5cHzG3FBwGcFLlzhM7GLR/rNH4QDltW+iE6OuYQXXxBbOMsQoa VrNg==
X-Gm-Message-State: AOUpUlEuyITgE8tj2cAEyMkoHtBjOgDEtEQoRdcL1Nc7ZXgQ1I9RTEAt kViiawDIjFFRXGfO/jR3ivBpJbBj9ZmTMvyrN5E=
X-Google-Smtp-Source: AAOMgpeem2VQN/VXeYgp1G1+yVcC1dJ1yM9zEhaAxQvjVEop3HF57sIz+N9xhQfb1/S4uHL7AXKTIOV7nwZ0uf6qLPc=
X-Received: by 2002:a02:8c75:: with SMTP id j50-v6mr2871917jal.76.1532626086055; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 26 Jul 2018 10:28:05 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <3F11F9C1-FD7D-48D6-9D59-838852DD58B8@tik.ee.ethz.ch>
References: <CAN1APdfRmLp9R8+3e+kfHusSppnrtyHNFC1mNt9Vt+5kiDf9rw@mail.gmail.com> <CABkgnnXxYnXyVa78w4rXG4sSG=ss5Y4bMCCfkUANC_o9tqQQEQ@mail.gmail.com> <3F11F9C1-FD7D-48D6-9D59-838852DD58B8@tik.ee.ethz.ch>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 26 Jul 2018 10:28:05 -0700
Message-ID: <CAN1APdcvDTYh4ZV-wZ6acLWO_TkuqFGjR1pjT9=WW_kCsbFJUw@mail.gmail.com>
Subject: Re: Hidden connection spawning
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Cc: Martin Thomson <martin.thomson@gmail.com>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006ed3e40571ea519c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g7_ep_vK6qRnIEVI1qy_EIz9AJ8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2018 17:28:09 -0000
Hi Mirja, I believe at least the following issues must be addressed in a handshake: - traffic keys - PMTU - TP (transport params, incl. reset token etc.) - CID - TLS CERT auth (some clients are authenticated this way too) - QUIC version Traffic keys are easy. PMTU could be inherited and later retested if needed. Transport params probably cannot be inherited trivially, especially not if there is some sort of negotiation happening, but I don’t there is anything beyond "this is what I have - deal with it". CID would require some thought because it needs to be different and possible route to same or different location. TLS Certs could be implied valid via handover. For things like traffic keys, it would be trivial to provide these via any secure out-of-band channel. But the sum of concerns probably would make it fragile to attempt to use a non-QUIC protocol to negotiate a QUIC handshake, except for the special case where everything other than traffic keys and CID can be statically configured. Of course you can be have special QUIC protocols that can have handshake negotiated via either QUIC or WebRTC etc, but in the general case I think it needs to be via QUIC and likely even the same QUIC version. The above can be side-stepped by actually carrying a full QUIC handshake over another secure channel, but that could lead to more roundtrips and overhead than ideal. 0-RTC might not work here because keys might not be present. Various rejections might happen like retry or vneg. On 26 July 2018 at 18.53.43, Mirja Kühlewind ( mirja.kuehlewind@tik.ee.ethz.ch) wrote: Hi Mikkel, a little amount of discussion on this also happened in taps. At least I have a draft on separating the handshake from the actual data encryption (draft-kuehlewind-taps-crypto-sep) which was not yet largely discussed but probably will come up again. In case of quic I'm mainly wondering how hard it would be to resume a TLS1.3 session with keys that have been negotiated with a different underlying transport protocol (use 0-RTT quic based on keys from a TCP/TLS1.3 connection or the other way around)…? But maybe the taps list is a better place to have this discussion… Mirja > Am 26.07.2018 um 04:35 schrieb Martin Thomson <martin.thomson@gmail.com>: > > Sounds like work for an extension to me. > On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahnøe Jørgensen > <mikkelfj@gmail.com> wrote: >> >> I came to think about a use case where you want to spawn a new connection from an existing connection because the new connection runs a different protocol. For example a http connection where you want to run a separate live conference call, or to control tunnels from http control connection. >> >> You have roughly three options: >> >> 1. extend the current protocol with the new feature set in extension frames or similar >> 2. develop or use a purposes specific QUIC protol using 0-RTT for spawning the connection >> 3. negotiate the new connection handshake within the current handshake. >> >> The first solution is not complex, limited, and not modular. >> The second solution can be used to get information about the connection, and for example block connections that appear to be doing that. >> The third solution allows for an invisible connection spawn, but requires addition handshake logic which is already complex as it is. >> >> I suggesting solution 3 as possible option, although I am not convinced that this is worthwhile, at least in V1. >> >> >> This was in part inspired by recent discussion on tunneling, and in part by the following issue where partial reliability is being discussed and possibly shoe-horned into an extension. I am not following that issue closely though - it is just an example. >> https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495 >> >> >> Mikkel >
- Hidden connection spawning Mikkel Fahnøe Jørgensen
- Re: Hidden connection spawning Martin Thomson
- Re: Hidden connection spawning Mirja Kühlewind
- Re: Hidden connection spawning Mikkel Fahnøe Jørgensen
- Re: Hidden connection spawning Christian Huitema
- Re: Hidden connection spawning Ted Hardie
- Re: Hidden connection spawning Christian Huitema
- Re: Hidden connection spawning Kazuho Oku
- Re: Hidden connection spawning Mikkel Fahnøe Jørgensen