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

Text on session resumption #3566

Merged
merged 5 commits into from
Apr 21, 2020
Merged

Text on session resumption #3566

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1f12b18
Text on session resumption
martinthomson Apr 8, 2020
b51c504
Add a note to security considerations
martinthomson Apr 8, 2020
46ee3b6
Tweak intro to security considerations
martinthomson Apr 8, 2020
4c97d95
speling
martinthomson Apr 9, 2020
c0ad8f5
plural
martinthomson Apr 14, 2020
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
41 changes: 37 additions & 4 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -648,6 +648,31 @@ messages and clients MUST treat receipt of such messages as a connection error
of type PROTOCOL_VIOLATION.


## Session Resumption {#resumption}

QUIC can use the session resumption feature of TLS 1.3. It does this by
carrying NewSessionTicket messages in CRYPTO frames after the handshake is
complete. Session resumption is the basis of 0-RTT, but can be used without
also enabling 0-RTT.

Endpoints that use session resumption might need to remember some information
about the current connection when creating a resumed connection. TLS requires
that some information be retained; see Section 4.6.1 of {{!TLS13}}. QUIC itself
does not depend on any state being retained when resuming a connection, unless
0-RTT is also used; see {{enable-0rtt}} and Section 7.3.1 of
{{QUIC-TRANSPORT}}. Application protocols could depend on state that is
retained between resumed connections.

Clients can store any state required for resumption along with the session
ticket. Servers can use the session ticket to help carry state.

Session resumption allows servers to link activity on the original connection
with the resumed connection, which might be a privacy issue for clients.
Clients can choose not to enable resumption to avoid creating this correlation.
Client SHOULD NOT reuse tickets as that allows entities other than the server
ianswett marked this conversation as resolved.
Show resolved Hide resolved
to correlate connections; see Section C.4 of {{!TLS13}}.


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Simple and to the point. My only reservation is about the security section. Session resumption allows tracking by the server, and this is arguably a security issue. The text here properly describes the concern and the remediation, but I wonder whether should there be a mention of these potential privacy issues in the security section.

## Enabling 0-RTT {#enable-0rtt}

To communicate their willingness to process 0-RTT data, servers send a
Expand Down Expand Up @@ -1609,11 +1634,19 @@ As a result, EndOfEarlyData does not appear in the TLS handshake transcript.

# Security Considerations

There are likely to be some real clangers here eventually, but the current set
of issues is well captured in the relevant sections of the main text.
All of the security considerations that apply to TLS also apply to the use of
TLS in QUIC. Reading all of {{!TLS13}} and its appendices is the best way to
gain an understanding of the security properties of QUIC.

This section summarizes some of the more important security aspects specific to
the TLS integration, though there are many security-relevant details in the
remainder of the document.


## Session Linkability

Never assume that because it isn't in the security considerations section it
doesn't affect security. Most of this document does.
Use of TLS session tickets allows servers and possibly other entities to
correlate connections made by the same client; see {{resumption}} for details.


## Replay Attacks with 0-RTT
Expand Down