Subject: [quicwg/base-drafts] Handshake protocol selection (#45)

From: MikeBishop <[email-masked]>
Date: Tue, 29 Nov 2016 13:28:12 -0800

It's currently unclear how two QUIC peers opening a connection know which handshake protocol to expect on Stream 1.

Since the client has to include the opening handshake in its first flight, it has to at least be able to guess *a* handshake protocol that's acceptable to the server and include enough information for the server to know which one it's attempting.  Currently all the mechanisms for telling the client to retry with different options are at the TLS layer, which is too late.

How is this negotiated?  Is it baked into the QUIC version?  Is it specified as part of the application mapping (e.g. the HTTP mapping currently requires the TLS 1.3 handshake to be used) and therefore either supplied as part of the Alt-Svc record or implied by the port?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/45

---

From: ianswett <[email-masked]>
Date: Tue, 29 Nov 2016 13:57:44 -0800

I would suggest it be baked into the QUIC version.

On Tue, Nov 29, 2016 at 4:28 PM, MikeBishop <[email-masked]>
wrote:

> It's currently unclear how two QUIC peers opening a connection know which
> handshake protocol to expect on Stream 1.
>
> Since the client has to include the opening handshake in its first flight,
> it has to at least be able to guess *a* handshake protocol that's
> acceptable to the server and include enough information for the server to
> know which one it's attempting. Currently all the mechanisms for telling
> the client to retry with different options are at the TLS layer, which is
> too late.
>
> How is this negotiated? Is it baked into the QUIC version? Is it specified
> as part of the application mapping (e.g. the HTTP mapping currently
> requires the TLS 1.3 handshake to be used) and therefore either supplied as
> part of the Alt-Svc record or implied by the port?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/45>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJcSL0szqoTqVb_RGb24h5GMpafwdyks5rDJjsgaJpZM4K_f8k>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/45#issuecomment-263712650

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Nov 2016 14:58:14 -0800

That's not unreasonable, though it feels odd to define in the core draft that a particular "version" means that its pluggable components have certain values.  So when we define a registry of "versions," it needs to specify both the base protocol release and the handshake protocol release that are implied by that version string.

Wading into unfamiliar transport territory -- does this need to include loss detection as well?  Do the two sides need to agree on the loss detection algorithm, or can that be unilateral?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/45#issuecomment-263727746

---

From: ianswett <[email-masked]>
Date: Tue, 29 Nov 2016 15:07:44 -0800

Crypto is special, because it indicates how to QUIC protocol handshake will
be transmitted, and QUIC can't do anything useful without crypto.

Loss detection can be unilateral.  And if something more framing oriented,
like an alternate ack format is desired, it could easily be negotiated in
the QUIC handshake, as long as it didn't need to be used before obtaining
the 1RTT keys.

On Tue, Nov 29, 2016 at 5:58 PM, Mike Bishop <[email-masked]>
wrote:

> That's not unreasonable, though it feels odd to define in the core draft
> that a particular "version" means that its pluggable components have
> certain values. So when we define a registry of "versions," it needs to
> specify both the base protocol release and the handshake protocol release
> that are implied by that version string.
>
> Wading into unfamiliar transport territory -- does this need to include
> loss detection as well? Do the two sides need to agree on the loss
> detection algorithm, or can that be unilateral?
>
> —
> You are receiving this because you commented.
> <https://github.com/quicwg/base-drafts/issues/45#issuecomment-263727746>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJccuWfwssCdXUoZICGJfUkpc5F-spks5rDK4GgaJpZM4K_f8k>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/45#issuecomment-263729778

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Nov 2016 16:25:10 -0800

Hmm, do I have to be the mailing-list police here?  I know that it's exciting and all, but we should either leave these design issues parked here, or take them to the list.  I suggest parking them because we can't have millions of design issues being discussed at the same time or they will all starve.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/45#issuecomment-263744669

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Nov 2016 16:31:24 -0800

Double-check the CONTRIBUTING file.

> Issues will be labeled by the Chairs as either `editorial` or `design`.
> 
> * `design` issues require discussion and consensus in the Working Group. This discussion can happen both **in the issue** and on the [Working Group mailing list](https://www.ietf.org/mailman/listinfo/quic), as outlined below.
> 
> * `editorial` issues can be closed by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.
> 
> Consensus for the resolution of a design issue can be established in a few different ways:
> 
> * Through discussion on the mailing list. Once a resolution is found, it will be recorded in the issue.
> 
> * **Through discussion on the issues list.** Once a resolution is found, it will be confirmed on the mailing list before consensus is declared.

Discussion on GitHub has been deemed appropriate -- it's only final decisions that have to go to the list.  If that's not the policy the chairs intended, they need to update their policy, because that's certainly how it reads.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/45#issuecomment-263745759