Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt

From: Mohamad Badra <[email-masked]>
Date: Mon, 02 Mar 2009 11:40:16 +0100

Hi Eric,

Section 4, version 03 said that the context length may be Zero (This text has been removed in Version 04).

In case the context is Zero length, does this length is omitted from the PRF input? or is it concatenated to the SecurityParameters.client_random + SecurityParameters.server_random?

Best regards,

Badra

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Layer Security Working Group of the IETF.
>
>
> 	Title           : Keying Material Exporters for Transport Layer Security (TLS)
> 	Author(s)       : E. Rescorla
> 	Filename        : draft-ietf-tls-extractor-04.txt
> 	Pages           : 6
> 	Date            : 2009-02-28
>
> A number of protocols wish to leverage Transport Layer Security (TLS)
> to perform key establishment but then use some of the keying material
> for their own purposes.  This document describes a general mechanism
> for allowing that.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Mar 2009 06:47:25 -0800

At Mon, 02 Mar 2009 11:40:16 +0100,
> Section 4, version 03 said that the context length may be Zero (This text has been removed in Version 04).

Editor error.

> In case the context is Zero length, does this length is omitted from the PRF input? or is it concatenated to the SecurityParameters.client_random + SecurityParameters.server_random?
The length bytes are zero. The context isn't there.

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Mar 2009 15:57:47 +0100

Hi Eric, WG,

I'm preparing a document that uses the tls-extractor document to
strengthen Kerberos V5 encryption keys using keys derived from TLS, see:

http://www.ietf.org/internet-drafts/draft-josefsson-krb5starttls-bootstrap-00.txt

I would appreciate general review of how that document uses the
tls-extractor construct, but I also have a specific question:

The tls-extractor document reads:

          PRF(master_secret, label,
              SecurityParameters.client_random +
              SecurityParameters.server_random +
              context_value_length + context_value
              )[length]
...
   The context value allows the application using the exporter to mix
   its own data with the TLS PRF for the exporter output.  The context
   value length is encoded as an unsigned 16-bit quantity (uint16)
   representing the length of the context value.

Is it fine if "context_value" contains material intended to be
confidential, e.g., encryption keys?

I suspect it may be a common use-case to "strengthen" keys derived via
other protocols by using tls-extractor, by placing encryption keys or
other sensitive information in the context_value field, so it would be
helpful to understand whether this is a good idea or whether it is
something that falls outside of the intended use of tls-extractor.

In particular, I'm thinking about how the data is fed to the hash
functions, and whether any length extension attacks or other problems
applies.

Thanks,
/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 05 Mar 2009 08:01:52 -0800

At Mon, 02 Mar 2009 06:47:25 -0800,
> The length bytes are zero. The context isn't there.

It should be clear at this point that I totally screwed up
and based my -04 revision off the -02 .xml, thus reverting
a lot of changes. I'll be preparing another revision
shortly that merges the 02-03 changes and will ask Joe to
start a new last call at that time.

Best,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 07 Mar 2009 14:59:33 -0800

At Thu, 05 Mar 2009 08:01:52 -0800,
> start a new last call at that time.

OK, I believe I've unscrewed this and submitted -05. Please
let me know if people think this is still hosed.

-Ekr

---

From: Badra <[email-masked]>
Date: Sun, 8 Mar 2009 00:20:46 +0100

Hi Eric,

Version 05 is fine for me. But some nits are reported but can be addressed
in a future revision (see
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-tls-extractor-05.txt
)

  ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216)

  ** Downref: Normative reference to an Informational RFC: RFC 5281
Beest regards,
Badra

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Mar 2009 12:35:59 +0100 (MET)

I'm wondering whether tls-extractors should use a TLS hello extension to
"negotiate" whether the TLS implementations at both ends actually
implement tls-extractors, and whether its the same version of
the spec.

There is this statement in "1. Introduction":

   o  Both client and server need to be able to export the same EKM
      value.

But I don't currently see a means how both peers are able to determine that
this is the case _without_ using a TLS hello extension to determine
they both, in fact, offer the necessary APIs to their callers and
implement the same version of the tls-extractors (TLS Exporters) spec.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Mar 2009 12:57:50 +0100

>    o  Both client and server need to be able to export the same EKM

I believe that is an implementation requirement.

> implement the same version of the tls-extractors (TLS Exporters) spec.

Doesn't this negotiation belong better in protocols that make use of
tls-extractor instead?  Compare one usage of tls-extractor:

http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02

If the other peer does not support tls extractor, the protocol that uses
tls-extractor could handle that gracefully.  The tls-extractor protocol
does not need to describe this negotiation.

In other words, I don't see what _advantage_ you get from knowing that
both peers support tls-extractor.  Support for it does not mean that
_use_ of the tls-extractor will do anything useful, since that will be
determined by some other protocol that makes use of tls-extractor.

Just some thoughts.

/Simon

---

From: Badra <[email-masked]>
Date: Mon, 9 Mar 2009 13:04:28 +0100

I think it is up to the application/spec/protocol that relies on TLS for
security services, e.g. EAP-TLS specifies how to extract the keys from
master_secret by both the client and the server and to verifies that both of
them have extracted the same key.

Best regards
Badra

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 09 Mar 2009 08:08:51 -0700

At Mon, 9 Mar 2009 12:35:59 +0100 (MET),
> implement tls-extractors, and whether its the same version of

That's one possibility. In fact, it's how DTLS-SRTP works. we just
didn't want to preclude otehr options.

>    o  Both client and server need to be able to export the same EKM

This is a requirement on the system as a whole.

> implement the same version of the tls-extractors (TLS Exporters) spec.

Say, for the sake of argument, that we were implementing a new
protocol Foo over TLS. Foo is defined to use an extractor as a key
generation mechanism and whenever Foo over TLS is used, the
extractor is also used. Thus, there is no need to negotiate it.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Mar 2009 16:48:05 +0100 (MET)

> extractor is also used. Thus, there is no need to negotiate it.

And if they were implementing a new revision of an existing protocol Bar
over TLS, which has the option of making use of TLS extractor, then
the Bar application protocol will have to use an application-level
negotiation (one round-trip) und the regular TLS protection in order
to determine whether the new Bar option to use TLS extractors is
available on both sides before it can switch to using it.

I don't see a need to make TLS extractors available to one side if 
the other side doesn't implmement it (doesn't offer it to the
application caller).  Whether and when the application makes use
of it is a different matter.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 09 Mar 2009 09:13:28 -0700

At Mon, 9 Mar 2009 16:48:05 +0100 (MET),
> available on both sides before it can switch to using it.

Yes. I don't see a problem with that. As I said, there are several
options.

> of it is a different matter.

I agree with that, but I'm not sure what your point is.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 Mar 2009 17:00:12 +0100 (MET)

> I agree with that, but I'm not sure what your point is.

If the availability of TLS-extractors was negotiated between both
communication peers through a TLS Hello extension, then the decision
at the application level of Bar whether to use a feature based
on TLS extractors or to use fallback instead can be entirely
based on the return value of the respective TLS-extractors API call,
no negotiation at the application level necessary.

The local API would then be able to produce the following
error messages:

     - TLS-extractor not implemented
     - TLS-peer did not confirm TLS-extractor availability for session
     - OK
     - misc errors (out-of-memory, ...)

And if TLS-wg would want to create a different variant of TLS-Extractors
in the future, one would not have to change the application negotiation
to also negotiate the variants of TLS-Extractors, that would be
entirely addressed by the negotiation in the TLS Hello extension.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 09 Mar 2009 09:28:26 -0700

At Mon, 9 Mar 2009 17:00:12 +0100 (MET),
> entirely addressed by the negotiation in the TLS Hello extension.

Yes, I see your point, but the extractors are suitable generally for
only a specific purpose (E.g., DTLS-SRTP) and the negotiation includes
the parameters for that purpose. So, I don't think a generic technique
is appropriate here.

-Ekr

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 09 Mar 2009 17:37:37 +0100

> the parameters for that purpose. So, I don't think a generic technique

I think the document should state that TLS is not concerned at all in 
case applications export keys from the master_secret; it describes a 
procedure that should be followed by IANA and authors of future 
Applications over TLS that need to assign new labels.

At the end, the document is developed to avoid exporting keys in 
insecure way, isn't? IMO, the time a different variant is need means 
that the TLS-PRF is not more secure. And in this case, we know how to 
resolve this problem without changing those applications' behavior (cf. 
cipher suites).

Best regards,
Badra

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 9 Mar 2009 17:55:16 +0100

> the parameters for that purpose. So, I don't think a generic technique
Another usage is DTLS/SCTP and it is a requirement to use it. So there
is no negotiation necessary. If an implementation does not provide
the extractor functionality, you can not use DTLS/SCTP.