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

On Feb 22, 2010, at 7:06 PM, <Pasi.Eronen@nokia.com> <Pasi.Eronen@nokia.com> 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: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
>> ext Eric Rescorla
>> Sent: 22 February, 2010 01:35
>> To: tls@ietf.org
>> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 