Skip to content

Commit

Permalink
https://www.rfc-editor.org/errata/eid5128
Browse files Browse the repository at this point in the history 
This seems to be a typo.
  • Loading branch information
@alandekok
alandekok committed Dec 28, 2022
1 parent d9c72b9 commit fd8a7e8
Showing 1 changed file with 3 additions and 2 deletions.
5 changes: 3 additions & 2 deletions draft-ietf-emu-rfc7170bis.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2793,13 +2793,14 @@ of S-IMCK is as follows:
~~~~
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMCK[j] = TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys" \|\|
IMSK[j], 60)

This comment has been minimized.

Sign in to view

Copy link
@jimdigriz

jimdigriz Jan 4, 2023

Contributor

The 60 is necessary and correct as it describes the length to pull from the TLS-PRF function; especially important for TLSv1.3 as every byte changes as the length requested changes.

Not helping has been the other typos around the use of the TLS-PRF function may lead the reader to believe it may be an octet to concatenate instead.

The definition is TLS-PRF(<key>, <seed> + <label>) we can elude that length becomes the final argument.

So what we want is as shown above:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" || IMSK[j], 60)

This comment has been minimized.

Sign in to view

Copy link
@jsalowey

jsalowey Jan 9, 2023

Contributor

RFC 5246 defines:

PRF(secret, label, seed) = P_(secret, label | seed) so it is a bit ambiguous as to what the 3rd argument means (could be seed or length), we ought to be explicit because I don't think implementations are including the length in the derivation.

IMCK[j] = the first 60 bytes of TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])

Earlier in the section I think we should define TLS-PRF as:

 where "|" denotes concatenation and the TLS-PRF is defined in
 [RFC5246] as 

 PRF(secret, label, seed) = P_<hash>(secret, label | seed).

 the secret is the S-IMCK[j-1] from the inner method, the label is 
 "Inner Methods Compound Keys" consisting of the ASCII value for the
 label "Inner Methods Compound Keys" (without quotes), and  the seed 
 consists of IMSK[j].
 
 IMCK[j] = First 60 bytes of P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" || IMSK[j])

Does this match you expectation?

This comment has been minimized.

Sign in to view

Copy link
@jimdigriz

jimdigriz Jan 9, 2023

Contributor

Does this match you(r) expectation?

Full version at https://mailarchive.ietf.org/arch/msg/emu/bBB8xRq6z2KSTHl-X0dPriopJTU/ but the tl;dr version is:

I do prefer this language ("First N bytes ...") but I am biased more towards "how this gets implemented" in practice. Coded up PRF functions take a length argument so to know how much stuff to generate so I think there is value adding 'length' to PRF/P_<hash>.

Alternatively if we want to go with the language, I think add something to highlight that PRF is a (stable) stream output function so people know how to treat it.

My quest here is there is so much in this (and other) RFCs that expect the reader to know inside out TLS (and PKCS) RFCs that it makes it extremely difficult to write an implementation if you are new to all this and there is no guide rail.

This comment has been minimized.

Sign in to view

Copy link
@jimdigriz

jimdigriz Jan 9, 2023 •
edited

Contributor

As a follow up, Heikki Vatiainen showed me the wrongs of my ways, so your language is better and we should remove all references to the 'length' argument.

Would be nice to include, for idiots like me, that if I would be so polite to look at RFC5246, to nosey at section 3.1 which is relevant.
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
~~~~

where TLS-PRF is the PRF negotiated as part of TLS handshake
where "\||" denotes concatenation, and TLS-PRF is the PRF negotiated as part of TLS handshake
{{RFC5246}}.

## Computing the Compound MAC {#computing-compound-mac}
Expand Down

0 comments on commit fd8a7e8

Please sign in to comment.