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.

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

Describe what happens if TLS breaks #3587

Merged
merged 3 commits into from
Apr 21, 2020
Merged
Changes from all commits
Commits
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
22 changes: 17 additions & 5 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -6170,10 +6170,22 @@ considered separately.
### Handshake {#handshake-properties}

The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
Copy link
Contributor

Choose a reason for hiding this comment

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

enjoys is an odd word to me, but I'm struggling to find a better one.

Copy link
Contributor

Choose a reason for hiding this comment

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

"benefits from" ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ahh @ekr will be sad
But yeah “benefits from” or “inherits” are all less tongue-in-cheek

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't really feel strongly about it. This is the text that 8446 uses (See S 8.1), so it's not tongue in cheek. I prefer "inherits" if that's accurate.

Copy link
Contributor

Choose a reason for hiding this comment

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

I also don't really care, we can keep it as is.

cryptographic properties described in Appendix E.1 of {{?TLS13=RFC8446}}.
cryptographic properties described in Appendix E.1 of {{?TLS13=RFC8446}}. Many
of the security properties of QUIC depend on the TLS handshake providing these
properties. Any attack on the TLS handshake could affect QUIC.

In addition to those properties, the handshake is intended to provide some
defense against DoS attacks on the handshake, as described below.
Any attack on the TLS handshake that compromises the secrecy or uniqueness
of session keys affects other security guarantees provided by QUIC that depends
on these keys. For instance, migration ({{migration}}) depends on the efficacy
of confidentiality protections, both for the negotiation of keys using the TLS
handshake and for QUIC packet protection, to avoid linkability across network
paths.

An attack on the integrity of the TLS handshake might allow an attacker to
affect the selection of application protocol or QUIC version.

In addition to the properties provided by TLS, the QUIC handshake provides some
defense against DoS attacks on the handshake.


#### Anti-Amplification
Expand Down Expand Up @@ -6220,9 +6232,9 @@ The entire handshake is cryptographically protected, with the Initial packets
being encrypted with per-version keys and the Handshake and later packets being
encrypted with keys derived from the TLS key exchange. Further, parameter
negotiation is folded into the TLS transcript and thus provides the same
security guarantees as ordinary TLS negotiation. Thus, an attacker can observe
integrity guarantees as ordinary TLS negotiation. An attacker can observe
the client's transport parameters (as long as it knows the version-specific
salt) but cannot observe the server's transport parameters and cannot influence
keys) but cannot observe the server's transport parameters and cannot influence
parameter negotiation.

Connection IDs are unencrypted but integrity protected in all packets.
Expand Down