IETF Logo Mail Archive

Re: Hidden connection spawning

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Thu, 26 July 2018 16:53 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 930BC130E0E for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 09:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EaXu7Uan0Y2d for <quic@ietfa.amsl.com>; Thu, 26 Jul 2018 09:53:44 -0700 (PDT)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2196E12F1AC for <quic@ietf.org>; Thu, 26 Jul 2018 09:53:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41bypt4wj6zMl1H; Thu, 26 Jul 2018 18:53:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sowSyRgakwnj; Thu, 26 Jul 2018 18:53:41 +0200 (CEST)
X-MtScore: NO score=0
Received: from [10.0.100.91] (50-204-41-11-static.hfc.comcastbusiness.net [50.204.41.11]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 26 Jul 2018 18:53:40 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Subject: Re: Hidden connection spawning
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CABkgnnXxYnXyVa78w4rXG4sSG=ss5Y4bMCCfkUANC_o9tqQQEQ@mail.gmail.com>
Date: Thu, 26 Jul 2018 11:53:38 -0500
Cc: QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F11F9C1-FD7D-48D6-9D59-838852DD58B8@tik.ee.ethz.ch>
References: <CAN1APdfRmLp9R8+3e+kfHusSppnrtyHNFC1mNt9Vt+5kiDf9rw@mail.gmail.com> <CABkgnnXxYnXyVa78w4rXG4sSG=ss5Y4bMCCfkUANC_o9tqQQEQ@mail.gmail.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/6qYm1hY9MS3kuRp9Q48-lyfwJV0>
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 16:53:47 -0000

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
>

v2.23.0 | Report a Bug | By Email