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

TLS interface overview #30

Merged
merged 11 commits into from
Dec 9, 2016
Merged

TLS interface overview #30

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
eafea73
Work in progress: Improving the quality of the TLS overview
martinthomson Nov 25, 2016
ab76aee
Adding details of the interaction between QUIC and TLS
martinthomson Nov 28, 2016
9155bd9
Refinement of delivery requirements
martinthomson Nov 28, 2016
17ab6f8
Fix ignore
martinthomson Nov 28, 2016
474b579
Fix client's second phase
martinthomson Nov 28, 2016
577d8df
Expand on retransmission of handshake messages
martinthomson Nov 28, 2016
31eaab6
Make it clearer what keys are used for which in packet protection
martinthomson Nov 28, 2016
ef666a9
Pre-handshake clarifications
martinthomson Nov 28, 2016
035b6b5
Contributing editorial fixes
MikeBishop Dec 8, 2016
d2956b8
QUIC delivers data to TLS
martinthomson Dec 9, 2016
4188b83
More precise talk about TLS data exchange
martinthomson Dec 9, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 6 additions & 9 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -373,20 +373,17 @@ A QUIC server starts the process by providing TLS with any stream 1 octets that
might have arrived. Only in-sequence frame data is delivered; data that arrives
out of order are buffered by QUIC until all preceding data is available.

Each time that an endpoint receives data on stream 1, it determines if it can
deliver the data to TLS. Any octets that are contiguous with the last data
provided to TLS can be delivered. When any octets of TLS data can be delivered,
TLS is provided with the data. New handshake octets are then requested from TLS.

After providing TLS with data, new handshake octets are then requested from TLS.
TLS might not provide any octets if the handshake messages it has received are
incomplete.

Once the TLS handshake is complete, this is indicated to QUIC along with any
final handshake octets that TLS needs to send. Once the handshake is complete,
TLS becomes passive. TLS might still receive data from its peer and respond to
that data, but it will not need to send more data unless it is explicitly
requested. One reason to send data is that the server might wish to provide
additional or updated session tickets to a client.
TLS becomes passive. TLS can still receive data from its peer and respond in
kind that data, but it will not need to send more data unless specifically
requested - either by an application or QUIC. One reason to send data is that
the server might wish to provide additional or updated session tickets to a
client.

Important:

Expand Down