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

From: Michael Tüxen <[email-masked]>
Date: Sun, 7 Mar 2010 11:11:36 +0100

On Feb 22, 2010, at 7:06 PM, <[email-masked]> <[email-masked]> wrote:

> 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.
Any decision on this?

Best regards
Michael
> 
> Best regards,
> Pasi
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> ext Eric Rescorla
>> Sent: 22 February, 2010 01:35
>> To: [email-masked]
>> Subject: [TLS] Entirely omitting context in draft-ietf-tls-extractor
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 08:10:13 +0100

> > objections before OK'ing this change with the RFC editor.

Nobody objected, so we'll go ahead with this change.

Eric: could you send the changes (and answers to the questions
the RFC editor had) as soon as possible? 

Best regards,
Pasi