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

Allow for other inputs than packets #3873

Closed
martinthomson opened this issue Jul 8, 2020 · 5 comments · Fixed by #4011
Closed

Allow for other inputs than packets #3873

martinthomson opened this issue Jul 8, 2020 · 5 comments · Fixed by #4011
Labels
-tls editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing

Comments

@martinthomson
Copy link
Member

The process for interacting with TLS does not acknowledge the possibility that progress in the handshake might depend on inputs other than CRYPTO frames. In particular, endpoints might need to perform additional checking to decide that the TLS handshake is complete. The most important example being the processing that occurs for certificate validation. This is often an asynchronous process, with OCSP and other muck, so recognizing that explicitly in the draft is worthwhile.

This might help tease out one of the causes of the problem discussed in #3821, but it doesn't lead to a solution.
@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -tls labels Jul 8, 2020
@ianswett
Copy link
Contributor

ianswett commented Aug 2, 2020

Q: Does this indicate that the TLS changes involved in #3821 may be editorial? I'd like to focus on the transport and recovery changes to deal with the issue, and it'd be nice if the tls changes were separate from my perspective.

@janaiyengar
Copy link
Contributor

Why isn't #3874 adequate for this? Specifically, isn't it enough to change the stance from synchronous to asynchronous?

@larseggert larseggert added this to Triage in Late Stage Processing via automation Aug 3, 2020
@martinthomson
Copy link
Member Author

I would prefer to explain how certificate validation can take time and block availability of keys.

@LPardue LPardue moved this from Triage to Editorial Issues in Late Stage Processing Aug 4, 2020
martinthomson added a commit that referenced this issue Aug 18, 2020
@martinthomson
Describe inputs to TLS more clearly
98905a1 
This clarifies the TLS interface by explaining that TLS only generates
outputs (handshake bytes or keying material) in response to inputs.
Previously, the only inputs we acknowledged were the handshake bytes,
but this recognizes two more: the signal from the client to start
handshaking, and - for async validation - a signal that a certificate is
OK or not.

Closes #3873.
@martinthomson martinthomson mentioned this issue Aug 18, 2020
Merged
@larseggert
Copy link
Member

Should this become proposal-ready?

@janaiyengar
Copy link
Contributor

@larseggert : This is an editorial issue, so no.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Sep 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-tls editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Describe inputs to TLS more clearly quicwg/base-drafts
4 participants
@martinthomson @larseggert @janaiyengar @ianswett