Move SETTINGS into TLS Handshake

[ekr]

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/want 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).

[martinthomson]

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

[hardie]

On Mon, Apr 17, 2017 at 10:21 PM, Martin Thomson ***@***.***> wrote: 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).

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

[MikeBishop]

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. Or allocate a QUIC setting ID per protocol.

[martinthomson]

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.

[martinthomson]

Discussed in Prague: conclusion was to leave things as they are.