Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Version Negotiation + TLS #97

Closed
MikeBishop opened this issue Dec 23, 2016 · 3 comments
Closed

Version Negotiation + TLS #97

MikeBishop opened this issue Dec 23, 2016 · 3 comments
Labels
-tls design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@MikeBishop
Copy link
Contributor

The QUIC-TLS spec currently says that the server should select a protocol without regard to the current QUIC version, and MAY (not MUST?) do Version Negotiation if the selected protocol can't be carried by the current QUIC version. However, if the server does Version Negotiation, the client's ClientHello gets thrown away, and the client has to resend the ClientHello anyway.

I'd be more inclined to say that servers select application protocols compatible with the current version if it can. There are then two possibilities:

  • Client learns that server supports a newer version in the response. Then the client can try again (in parallel or in the future) over the newer version. Same RTTs to reach the new version/protocol, but able to exchange some data on the initial connection 1 RTT sooner.
  • Server supports no protocol compatible with the client's supported version, and triggers Version Negotiation anyway. Same RTTs to reach the new version/protocol.
@MikeBishop MikeBishop added design An issue that affects the design of the protocol; resolution requires consensus. -tls labels Dec 23, 2016
MikeBishop added a commit that referenced this issue Dec 23, 2016
@MikeBishop
Changes to ALPN and version negotiation for #97
9b99196
@MikeBishop MikeBishop mentioned this issue Dec 23, 2016
Closed
@MikeBishop
Copy link
Contributor Author

#99 & #122 address this in the same way -- app protocols MAY restrict which version are acceptable, but tokens aren't version-specific.

@MikeBishop MikeBishop added the proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. label Jan 14, 2017
@vasilvv vasilvv mentioned this issue Jan 23, 2017
Closed
@mnot
Copy link
Member

mnot commented Jan 25, 2017

Discussed in Tokyo; seems reasonable.

@mnot mnot added editor-ready and removed proposal-ready An issue which has a proposal that is believed to be ready for a consensus call. labels Jan 25, 2017
@mnot mnot mentioned this issue Jan 25, 2017
Closed
@martinthomson
Copy link
Member

Closed as part of #122.

@mnot mnot removed the editor-ready label Mar 7, 2017
@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Apr 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-tls design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@martinthomson @mnot @MikeBishop