Subject: [TLS] Entirely omitting context in draft-ietf-tls-extractor

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Feb 2010 15:35:03 -0800

During LC, we received a comment from Jouni Malinen that unconditionally
including the context in the PRF created an unnecesssary incompatibility
with exporter-type mechanisms in EAP-TLS and EAP-TTLS which could otherwise
be retconned into being extractor usages. In order to address this, I
propose changing the text to read:

  If no context is provided, it then computes:

         PRF(SecurityParameters.master_secret, label,
             SecurityParameters.client_random +
             SecurityParameters.server_random
             )[length]

  If the context is provided, it computes::

         PRF(SecurityParameters.master_secret, label,
             SecurityParameters.client_random +
             SecurityParameters.server_random +
             context_value_length + context_value
             )[length]

  Where PRF is the TLS PRF in use for the session.  The output is a
  pseudorandom bit string of length bytes generated from the
  master_secret. (This construction allows for interoperability
  with older exporter-type constructions which do not
  use context values, e.g., [RFC5281]).

Any objections?

-Ekr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 21 Feb 2010 21:07:43 -0800

Looks good. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric
> Rescorla
> Sent: Sunday, February 21, 2010 3:35 PM
> To: [email-masked]
> Subject: [TLS] Entirely omitting context in draft-ietf-tls-extractor
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Mon, 22 Feb 2010 19:06:19 +0100

Not wearing any hats: This could potentially simplify TLS library 
APIs a bit (no need to provide special cases for EAP-TLS/EAP-TTLS).  
And since we require that one label can't be a prefix of any other 
label, this seems safe, too. So no objections from me as individual.

Wearing AD hat: I'll wait for a week or so to see if there are
objections before OK'ing this change with the RFC editor.

Best regards,
Pasi

> ext Eric Rescorla
> Sent: 22 February, 2010 01:35
> To: [email-masked]