Subject: Hidden connection spawning

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 25 Jul 2018 23:31:58 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jul 2018 19:35:05 +1000

Sounds like work for an extension to me.
On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahnøe Jørgensen
<[email-masked]> 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.
>
> 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
> 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.

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 26 Jul 2018 11:53:38 -0500

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 <[email-masked]>:
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 26 Jul 2018 10:28:05 -0700

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 (
[email-masked]) 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)…?

Mirja

>> 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.
>> The third solution allows for an invisible connection spawn, but
requires addition handshake logic which is already complex as it is.
>>
>>
>> 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.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Jul 2018 14:41:39 -0700

On 7/25/2018 11:31 PM, Mikkel Fahnøe Jørgensen wrote:
> 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.
...
>
> 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.

I have a related scenario in mind, something like "server-assisted
peer-to-peer". Two peers first synchronize through a server -- each peer
has a QUIC connection with the server. They exchange some messages to
establish a peer-to-peer connection through the server, then use
connection migration to establish a direct peer-to-peer connection. I
think it will require the same type of extension frames that you are
considering, plus something like ICE.

-- Christian Huitema

---

From: Ted Hardie <[email-masked]>
Date: Thu, 26 Jul 2018 15:07:58 -0700

On Thu, Jul 26, 2018 at 2:41 PM, Christian Huitema <[email-masked]>
wrote:

> establish a peer-to-peer connection through the server, then use connection
> migration to establish a direct peer-to-peer connection. I think it will
> require the same type of extension frames that you are considering, plus
> something like ICE.
>

This seems like a generalization of the "QUIC as an RTCWEB datachannel"
use case.  In that, the web server providing the JavaScript is the initial
server, ICE messages provide rendezvous/consent, and you can have
peer-to-peer connections.

Other than the generalization from "web server" to "server" is there a
distinction here I'm missing?

Ted

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Jul 2018 15:40:28 -0700

On 7/26/2018 3:07 PM, Ted Hardie wrote:
> On Thu, Jul 26, 2018 at 2:41 PM, Christian Huitema
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     peer-to-peer". Two peers first synchronize through a server --
>     each peer has a QUIC connection with the server. They exchange
>     some messages to establish a peer-to-peer connection through the
>     server, then use connection migration to establish a direct
>     peer-to-peer connection. I think it will require the same type of
>     extension frames that you are considering, plus something like ICE.
>
>
> This seems like a generalization of the "QUIC as an RTCWEB
> datachannel"   use case.  In that, the web server providing the
> JavaScript is the initial server, ICE messages provide
> rendezvous/consent, and you can have peer-to-peer connections.  
>

It is definitely related. As it is related to SIP/RTP, and many other
apps. That's a very generic P2P pattern. I like the idea of pushing the
function down to a secure transport layer. It allows embedding this P2P
functionality in any application, independent of the browsers and web
servers. Think of "nodes and supernodes", as in the original versions of
Skype. Or Kazaa if you really want to go down memory lane.

-- Christian Huitema

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 27 Jul 2018 09:31:02 +0900

2018-07-26 15:31 GMT+09:00 Mikkel Fahnøe Jørgensen <[email-masked]>:
> The second solution can be used to get information about the connection, and
> for example block connections that appear to be doing that.

I prefer the second approach, since it allows spawning connections in
0-RTT across different transports.

For example, I think that it would be nice to have a way to spawn a
0-RTT HQ connection from a HTTP/2 connection (via alt-svc).

Note also that there is an individual draft submitted to TLSWG that
discusses of adding a way for a TLS server to issue session tickets
that could be context-specific: see
https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 27 Jul 2018 00:07:50 -0700

When you say you prefer option 2 (0-RTT), do you mean to not hide the
handshake, or do you mean the until now unlisted option 4:

4. carry out a full 0-RTT handshake over a separate secure channel (QUIC or
otherwise)

Option 4 may skip the QUIC encryption layer if the outer layer is equally
strong (this is a can of worms).

Correction: in my earlier mail I wrote “not complex” in relation to option
1, the “not” should not have been there.

On 27 July 2018 at 02.31.03, Kazuho Oku ([email-masked]) wrote:

> The second solution can be used to get information about the connection,
and

> I suggesting solution 3 as possible option, although I am not convinced
that
> this is worthwhile, at least in V1.
>
>
by

-- 
Kazuho Oku