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

Clear up confusion about label encoding #4201

Merged
merged 2 commits into from Oct 15, 2020
Merged
Changes from 1 commit
Commits
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
15 changes: 9 additions & 6 deletions draft-ietf-quic-tls.md
Expand Up @@ -924,8 +924,10 @@ based on the client's initial Destination Connection ID, as described in
The keys used for packet protection are computed from the TLS secrets using the
KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label function described in
Section 7.1 of {{!TLS13}} is used, using the hash function from the negotiated
cipher suite. Other versions of TLS MUST provide a similar function in order to
be used with QUIC.
cipher suite. Note that labels, which are described using strings, are encoded
as bytes using ASCII {{?ASCII=RFC0020}} without quotes or any trailing NUL
byte. Other versions of TLS MUST provide a similar function in order to be
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
byte. Other versions of TLS MUST provide a similar function in order to be
bytes. Other versions of TLS MUST provide a similar function in order to be

Copy link
Member Author

Choose a reason for hiding this comment

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

This is singular intentionally, to avoid problems like might arise from:

const char* label = "quic key";
hkdf_expand_label(...., label, strlen(label), ...);

used with QUIC.

The current encryption level secret and the label "quic key" are input to the
KDF to produce the AEAD key; the label "quic iv" is used to derive the
Expand All @@ -950,10 +952,11 @@ pseudorandom key (PRK) that is used to derive two separate secrets for sending
and receiving.

The secret used by clients to construct Initial packets uses the PRK and the
label "client in" as input to the HKDF-Expand-Label function to produce a 32
byte secret; packets constructed by the server use the same process with the
label "server in". The hash function for HKDF when deriving initial secrets
and keys is SHA-256 {{!SHA=DOI.10.6028/NIST.FIPS.180-4}}.
label "client in" as input to the HKDF-Expand-Label function from TLS
{{!TLS13}} to produce a 32 byte secret. Packets constructed by the server use
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
the same process with the label "server in". The hash function for HKDF when
deriving initial secrets and keys is SHA-256
{{!SHA=DOI.10.6028/NIST.FIPS.180-4}}.

This process in pseudocode is:

Expand Down