QUIC-TLS Extension and version negotiation

[MikeBishop]

Proposal on how to define the TLS extension for QUIC, and thereby fix up some of the version negotiation issues (#89, #97).

Key changes:

• TLS doc does define the QUIC extension, but it simply contains an opaque blob transported for whichever QUIC version is being used.
• Parameters encoding is specified, and is more "TLS-y" than the current protocol -- an enum of possible parameters, carried as numbers rather than strings where appropriate, etc. Plenty of room to add additional parameters, but unrecognized parameters here will be fatal unless we add an explicit length.
• Server's version list is always required in TLS extension, even if no Version Negotiation packet was sent. Client MAY open a new connection immediately if it discovers the server would have supported a newer version, and SHOULD use the newer version next time.
• Server SHOULD pick an application protocol supported by the client's proposed version; Version Negotiation only if no overlap on the current version.

[martinthomson]

I think that this is better off moved to the -transport document. If it's OK with you, I plan to move your text there. I think that keeps the separation of concerns cleaner.

[MikeBishop]

I kind of disagree -- I was trying to keep anything TLS-specfic out of the Transport doc. Remember that QUIC doesn't know that the crypto protocol is necessarily TLS. Defining that any handshake MUST be able to transport a blob and then defining how TLS will transport the opaque data keeps the components separate.

[martinthomson]

Actually, I made that comment without really reading what you had done. I prefer this structure. I've built on and fleshed it out more in #122.

[ghedo]

Should this specify which error to use?

[martinthomson]

Yes, generally we need to identify error codes. But until we have #37 fixed, I think that we can afford to be a little bit lenient on PRs that describe error conditions.

[martinthomson]

Since we have #122 and this is bitrotten, closing this.