Subject: [quicwg/base-drafts] Move SETTINGS into TLS Handshake (#436)

From: ekr <[email-masked]>
Date: Thu, 13 Apr 2017 11:05:39 -0700

Reviewing Issue #181 and PR #236, it seems like having the SETTINGS
frame on Stream #3 creates a bunch of odd race conditions, because
you need to send data (both in 0-RTT and 1-RTT) before you might
get the SETTINGS frame.

It occurs to me that we might easily be able to remove this by
moving the SETTINGS frame into the handshake. Specifically the
ClientHello and the EncryptedExtensions.

If we did this, there would be no need for defaults, because:

- In 1-RTT, you would be guaranteed of getting it before you
  could write
- It would not be possible to have a 0-RTT context without
  SETTINGS.

Moreover, the server's 1-RTT settings frames would clearly
apply to the 1-RTT data, but not the 0-RTT data.

It seems like the major downsides of this are:

- Layer violation
- You don't get confidentiality for the client's settings
  (but you do gain a full RTT).

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Apr 2017 22:21:34 -0700

You need a design here that handles multiple higher-layer protocols, e.g.:

1. Every protocol that uses QUIC (and needs this pattern) defines a TLS extension for itself.  HTTP would define a new TLS extension.
2. Application protocols can define QUIC transport parameters.  HTTP would define a small number of QUIC transport parameters.

This isn't intractable, it's just that it's a result of designing a generic protocol (QUIC) with only one real user (HTTP).  Good to see some work on DNS here, which wouldn't need this functionality (I think).

-- 
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/436#issuecomment-294684829

---

From: hardie <[email-masked]>
Date: Tue, 18 Apr 2017 10:42:46 -0700

On Mon, Apr 17, 2017 at 10:21 PM, Martin Thomson <[email-masked]>
wrote:

>    1. Every protocol that uses QUIC (and needs this pattern) defines a
>    TLS extension for itself. HTTP would define a new TLS extension.
>    2. Application protocols can define QUIC transport parameters. HTTP
>    would define a small number of QUIC transport parameters.
>
> This isn't intractable, it's just that it's a result of designing a
> generic protocol (QUIC) with only one real user (HTTP). Good to see some
> work on DNS here, which wouldn't need this functionality (I think).
>
> Actually, I think a QUIC over DNS might benefit from the use of a settings
frame like construction, e.g. for  EDNS0 options.

I'm a little worried about design 1, as I suspect the use of common TLS
libraries might encourage people to re-use existing TLS extensions and
re-interpret their meanings in new protocol contexts.  (That likely would
not be a problem for standards track protocols, but might be for those
experimenting with layering Example Protocol over QUIC).  If we can clearly
associate transport parameters with specific application protocols, that
seems safer, especially if we allow for fairly open use of experimental
code points.

Just my two cents,

Ted

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/436#issuecomment-294684829>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5Ku2Mrdj3Eyu54xjLXYsXCeOYtppks5rxEhegaJpZM4M9BXs>
> .
>

-- 
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/436#issuecomment-294924006

---

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Apr 2017 10:50:33 -0700

I'd prefer reusing the model we're using for the TLS transport of QUIC parameters -- TLS provides blob transport, and QUIC defines the content and structure within the blob interpreted only at the QUIC layer.

If QUIC, in turn, stuffed an application-provided blob in its parameters whose structure was defined and parsed only by the application layer, I think we're done.  For HTTP, this will be the content of what was a SETTINGS frame.  For DNS, this might be a sequence of EDNS0 options.  For an application that elects not to use it, it will either not be present or be zero-length.

There is also a hiccup here that it presumes the selection of a particular app protocol to include this in your QUIC settings.  While you probably know whether you expect hq versus dq, you might not know whether you expect e.g. imap versus jmap.  We might need to support sending a map of ALPN token to blob, if we go this route.

-- 
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/436#issuecomment-294926744

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Apr 2017 16:49:55 -0700

Yeah, I think that logically the blob within blob within blob design is fine.  The only issue that I have with that is that we now have more places where extensibility is critical.  If we can collapse at least some of those then that reduces the likelihood that the ones we do have will atrophy.

-- 
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/436#issuecomment-295018410

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Apr 2017 19:31:50 -0700

-- 
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/436#issuecomment-297594438