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

Be clearer about protections #3900

Merged
merged 12 commits into from Aug 4, 2020
Merged

Be clearer about protections #3900

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
a38e49b
Be clearer about protections
martinthomson Jul 14, 2020
25264d0
First initial
martinthomson Jul 14, 2020
83e840e
first Initial
martinthomson Jul 14, 2020
5782bf9
Merge branch 'master' into less-protection
martinthomson Jul 16, 2020
c78921e
Use text from master for this paragraph
martinthomson Jul 16, 2020
1db24ca
Trailing whitespace, gah
martinthomson Jul 16, 2020
05cb8f2
Lots of review comments
martinthomson Jul 19, 2020
bca2743
wrap
martinthomson Jul 19, 2020
92d1701
Moor sugestions
martinthomson Jul 21, 2020
00d90fc
Some more rearrangement
martinthomson Jul 20, 2020
645d6f8
Cleaner
martinthomson Jul 20, 2020
7f190d7
Split sentence; reword
martinthomson Jul 21, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -913,9 +913,9 @@ QUIC packets have varying protections depending on their type:
and integrity, using keys and algorithms negotiated by TLS.

This section describes how packet protection is applied to Handshake packets,
0-RTT packets, and packets with short headers. The same packet protection
0-RTT packets, and 1-RTT packets. The same packet protection
process is applied to Initial packets. However, as it is trivial to determine
the keys, Initial packets are not considered to have confidentiality or
the keys used for Initial packets, these packets are not considered to have confidentiality or
integrity protection. Retry packets use a fixed key and so similarly lack
confidentiality and integrity protection.

Expand Down
14 changes: 7 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1177,8 +1177,8 @@ expected keys are available.

Invalid packets that lack strong integrity protection, such as Initial, Retry,
or Version Negotiation, MAY be discarded. An endpoint MUST generate a
connection error if processing of the contents of these packets prior to
discovering an error resulted in changes to the state of a connection that
connection error if processing the contents of these packets prior to
discovering an error resulted in changes to connection state that
cannot be reverted.


Expand Down Expand Up @@ -3165,10 +3165,10 @@ section includes an overview of the protections that are provided.
Version Negotiation packets have no cryptographic protection; see
{{QUIC-INVARIANTS}}.

Retry packets use an authenticated encryption with associated data (AEAD;
{{?AEAD=RFC5116}}) function to protect against accidental modification.
Retry packets use an authenticated encryption with associated data function
(AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification.

Initial packets use an AEAD with keys that are statically derived. This does
Initial packets use an AEAD with keys that are derived using a value that is visible on the wire, and therefore does
not provide effective confidentiality protection. Initial protection exists to
ensure that the sender of the packet is on the network path. Any entity that
receives the Initial packet from a client can recover the keys that will allow
Expand All @@ -3182,8 +3182,8 @@ protected with 0-RTT and 1-RTT keys are expected to have strong confidentiality
and integrity protection; the cryptographic handshake ensures that only the
Copy link
Member

Choose a reason for hiding this comment

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

Maybe "authentication, confidentiality, and integrity protection"? I think that would be more consistent with the use of terms thatwe see in RFC 8446 section 1.

Copy link
Member Author

Choose a reason for hiding this comment

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

Those are inclusive of other properties provided by TLS, so the packet protection doesn't strictly provide authentication in the same way.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not against viewing that way, though then I think it might be better to talk about 0-RTT, Handshake and 1-RTT packets, rather than just 0-RTT and 1-RTT packets.

It might be a good idea to change the first sentence of the paragraph to the following and remove the last sentence: All other packets are expected to provide strong confidentiality and integrity protection using the keys derived from the cryptograph handshake; the handshake ensures that only the communicating endpoints receive the corresponding keys.

communicating endpoints receive the corresponding keys.

The Packet Number field that appears in some packet types contains a packet
number, which has additional confidentiality protection that is applied as part
The Packet Number field that appears in some packet types
has additional confidentiality protection that is applied as part
of header protection; see Section 5.4 of {{QUIC-TLS}} for details. The
underlying packet number increases with each packet sent in a given packet
number space; see {{packet-numbers}} for details.
Expand Down