On Mon, 9 Jan 2023 at 10:57, Alexander Clouter <[email protected]> wrote:
Problem is this section has the instruction "generate 64 bytes, use the > first 32..." and after personally getting tripped up[1] on the different > though used with TLS-Exporter which for TLSv1.3 now generates wildly > different outputs depending on the length you request. > > So do we think implementers treat the PRF function as a '(stable) stream > output function' or a 'hashing function'? It works as the former but when > you use it it feels like the latter. > My suggestion: see how the PRF is defined and use it accordingly. For example, with TLSv1.2 default PRF one needs to call P_hash as many times as needed to get at least the number of octets that are required before truncation. Then truncate if needed. As seen below (IMSK definition for TEAP), the length of defined output affects P_hash output therefore it's important to know how much output is needed and what the possible truncation is. Truncation must define clearly what is removed and what is left. For example 'First 32 octets' tells what is used after truncation. I think the TLSv1.2 PRF definition provides the definition and example that is clear enough: https://www.rfc-editor.org/rfc/rfc5246#section-5 > So two options: > > 1. I do like the amendment to use the language "First N octets of > TLS-PRF(..." but it would be helpful to include with it a statement along > the lines that PRF/P_<hash> outputs a stable infinite *stream* of > pseudorandom wonder. > > 2. We update the PRF/P_<hash> function definition updated to include > 'length' (as actual implementations *do* take in a length to know how much > stuff to generate) just so we push it under the noses of implementers and > ready them for the excitement and pitfalls of TLSv1.3. > I'd say it would be enough to tell that successful using PRF requires taking a look at the definition. Such as Section 5 in the TLSv1.2 RFC. With TLS exporter things are easier because length is one of the inputs. > So whilst I prefer the amendment language, I think for communication and > clarity reasons adding 'length' to the PRF/P_<hash> is the better options > as it makes it literally closer to how those functions are in practice > implemented and called; plus TLS-Exporter is now sensitive to length to we > gain some kind of symmetry there too. > > On a related note, whilst we are here, it does raise the question on how > we got: > > "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)" > > The '0x00 || 0x40' (64 network order 16bit length concatenation) looks > superfluous and I cannot see what they add here (as the label is not > recycled elsewhere) and makes me wonder if it was unintended? > See https://www.rfc-editor.org/rfc/rfc5295#section-3.1 Because IMSK is derived from EMSK I think it has to be defined as currently shown in draft 7170bis-02. One of RFC 5295 requirements is that the derived key, in this case IMSK, has to be at least 64 octets. Maybe this clarifies section 5.2 in the draft (be specific that 64 octets are needed by using [0..63] notation): IMSK = First 32 octets of TLS-PRF(EMSK, "[email protected]", 0x00 || 0x00 || 0x40) [0..63] This means that two iterations of TLSv1.2 P_hash(secret, seed) are needed with. o secret=EMSK; and o seed = "[email protected]", 0x00 || 0x00 || 0x40 One iteration would give enough data, but RFC 5295 requires to pull 64 octets. I haven't implemented TEAP yet, but the above is how I'd do to get IMSK. Part of my reasoning is later in the same section we see TLS-PRF(...) with > what is obviously a length field: > > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" || IMSK[j], > 60) > S-IMCK[j] = first 40 octets of IMCK[j] > CMK[j] = last 20 octets of IMCK[j] > > This makes me believe that originally we were meant to see: > > IMSK = First 32 octets of TLS-PRF(EMSK, "[email protected]" || 0x00, > 64) > > This aligns nicely with the 'label | seed' definition seen earlier for > PRF/P_<hash> too. > Not to sure why the '0x00' is still needed, but maybe it was to stop > people messing up the seed with a NULL/empty value rather than a single NUL > byte or vice versa; this way it is explicitly described/read-as "seed is > 0x00" and clear to the implementer. > > Anyway, pondering on history here is mostly irrelevant as Windows, Cisco > ISE, hostapd and now FreeRADIUS all have implemented '... || 0x00 || 0x00 > || 0x40'. > As mentioned above, I think this comes from RFC 5295. -- Heikki Vatiainen [email protected]
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
