RFC Errata
Found 1 record.
Status: Reported (1)
RFC 5705, "Keying Material Exporters for Transport Layer Security (TLS)", March 2010
Note: This RFC has been updated by RFC 8446, RFC 8447
Source of RFC: tls (sec)
Errata ID: 4395
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rick van Rein
Date Reported: 2015-06-16
Section 4 says:
If no context is provided, it then computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random )[length] If context is provided, it computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length]
It should say:
If no context is provided, it then computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random )[0..length-1] If context is provided, it computes: PRF(SecurityParameters.master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[0..length-1]
Notes:
The current notation is not in line with that of RFC 5246, where the [0..N-1] notation is used on a PRF outcome in Sections 7.4.9 and 8.1 and similar [A..B] notation is also used elsewhere. This makes me believe that the current text is technically wrong, and not in line with the intentions stated informally below it,
The output is a pseudorandom bit string of length bytes generated
from the master_secret.