-
Notifications
You must be signed in to change notification settings - Fork 87
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.
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
Supporting QUIC #392
Comments
From a look at draft-ietf-quic-tls-23 it seems this is all about using a different record layer. I'm wondering if it is possible to push more into infrastructure code instead of duplicating handshake code. Especially:
Having a more general API is desirable because it could be used or tested independently of QUIC. We need to be able to maintain and refactor for TLS without impacting QUIC. I'm also wondering what is the story for HelloRetryRequest. |
Yes. Historically speaking, old drafts designed to use backend with the TLS record layer. Since it is inefficient, the current design was taken.
Did you suggest the following?
Good point. Since |
If a QUIC client calls
Is this what you want? |
I cited Backend as example of pluggable module API we already have. If interface between QUIC and TLS needs to exchange packet plaintext, it should not be backendSend/backendRecv but a higher-level API dealing with something like I don't know which side is supposed to take care of packet fragmentation. What I don't understand too is the call model that is actually required. Does QUIC need to pull a Client Hello out of TLS in its calling thread, or is it possible to push the Client Hello to QUIC from an external thread executing |
I'm now exploring your idea: https://github.com/kazu-yamamoto/hs-tls/tree/record-layer I will bring my experience here soon. |
It is a job of QUIC CRYPTO frame which provides the offset field. |
Good news: the new approach works elegantly.
I think the approach 3) is promising. In this sample code, a client and a server negotiates with HRR and NST. I also confirmed that this APIs works well for my QUIC client.
data RecordLayer = RecordLayer {
-- Sending.hs and Sending13.hs
encodeRecord :: Record Plaintext -> IO (Either TLSError ByteString)
-- IO.hs
, sendBytes :: ByteString -> IO ()
-- IO.hs
, recvRecord :: IO (Either TLSError (Record Plaintext))
}
I don't have to hurry for merging since these branches are not drastic changes. But I would like to merge Any comments? |
|
How much of an issue is this in practice? With some effort, I think the encoding I gave in #380 could be extended and then provide |
I'm not sure. Probably, its cost is cheap.
I don't understand this idea completely. Anyway, I'm satisfied with the current implementation: https://github.com/kazu-yamamoto/hs-tls/tree/handshake-controller This code was tested with other QUIC implementations. I have spent much time to implement this and would like to spend time to explore other stuffs of QUIC than the handshake. Would you compare my implementation and your idea by yourself, if necessary? |
Todo items identified after reviewing #419, will work on this over time:
|
QUIC requires TLS 1.3 without the transport feature.
To support QUIC, a lot of refactorings and new APIs are necessary.
I'm thinking 4 steps to merge my QUIC implemenatation:
Edited: the approach was changed. The new approach is found in #419.
The text was updated successfully, but these errors were encountered: