RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search