Re: Hidden connection spawning

Mirja Kühlewind <> Thu, 26 July 2018 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 930BC130E0E for <>; Thu, 26 Jul 2018 09:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EaXu7Uan0Y2d for <>; Thu, 26 Jul 2018 09:53:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2196E12F1AC for <>; Thu, 26 Jul 2018 09:53:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41bypt4wj6zMl1H; Thu, 26 Jul 2018 18:53:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sowSyRgakwnj; Thu, 26 Jul 2018 18:53:41 +0200 (CEST)
X-MtScore: NO score=0
Received: from [] ( []) by (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 <>
In-Reply-To: <>
Date: Thu, 26 Jul 2018 11:53:38 -0500
Cc: QUIC WG <>, Martin Thomson <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mikkel Fahnøe Jørgensen <>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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…


> Am 26.07.2018 um 04:35 schrieb Martin Thomson <>:
> Sounds like work for an extension to me.
> On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahnøe Jørgensen
> <> 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.
>> Mikkel