Re: Hidden connection spawning

Mikkel Fahnøe Jørgensen <> Thu, 26 July 2018 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF7F3130E53 for <>; Thu, 26 Jul 2018 10:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f3rrKF5vkWm4 for <>; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD049130E0C for <>; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: by with SMTP id w16-v6so3873076ita.0 for <>; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with HTTPREST; Thu, 26 Jul 2018 10:28:05 -0700
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 26 Jul 2018 10:28:05 -0700
Message-ID: <>
Subject: Re: Hidden connection spawning
To: Mirja Kühlewind <>
Cc: Martin Thomson <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000006ed3e40571ea519c"
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 17:28:09 -0000

Hi Mirja,

I believe at least the following issues must be addressed in a handshake:

- traffic keys
- TP (transport params, incl. reset token etc.)
- 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 ( 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…


> 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
>> 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