Subject: [Unbearable] Exporter label for token bindnig?

From: Bill Cox <[email-masked]>
Date: Mon, 14 Mar 2016 16:55:25 -0700

I see it is EXPORTER-Token-Binding.  Did we register that like we are
supposed to?  All I know is that I didn't :p

A colleague would like to use the same label, since the result is a
TLS-unique value, which has various applications.  Did we register the
label?  Currently, it is EXPORTER-Token-Binding.  If that's a done-deal,
I'll just ask him to use it.

Thanks,
Bill

---

From: =JeffH <[email-masked]>
Date: Mon, 14 Mar 2016 18:27:55 -0700

> supposed to?  All I know is that I didn't :p

I noticed a registration hadn't yet been included in -tokbind-protocol aka 
TBPROTO and so it's in this PR..

https://github.com/TokenBinding/Internet-Drafts/pull/18

 > I'll just ask him to use it.

shouldn't an exporter label be used only for the purpose it's allocated for?

is that not the admonition in the 2nd para of rfc5705 sec cons (below)?

or if it is a tokenbinding rfelated usage, perhaps using the label but being 
sure to supply a context value (TBPROTO uses a null context value) would be ok?

=JefffH

https://tools.ietf.org/html/rfc5705#section-5

5. Security Considerations

The prime security requirement for exporter outputs is that they be
independent. More formally, after a particular TLS session, if an
adversary is allowed to choose multiple (label, context value) pairs
and is given the output of the PRF for those values, the attacker is
still unable to distinguish between the output of the PRF for a
(label, context value) pair (different from the ones that it
submitted) and a random value of the same length. In particular,
there may be settings, such as the one described in Section 4, where
the attacker can control the context value; such an attacker MUST NOT
be able to predict the output of the exporter. Similarly, an
attacker who does not know the master secret should not be able to
distinguish valid exporter outputs from random values. The current
set of TLS PRFs is believed to meet this objective, provided the
master secret is randomly generated.

Because an exporter produces the same value if applied twice with the
same label to the same master_secret, it is critical that two EKM
values generated with the same label not be used for two different
purposes -- hence, the requirement for IANA registration. However,
because exporters depend on the TLS PRF, it is not a threat to the
use of an EKM value generated from one label to reveal an EKM value
generated from another label.

With certain TLS cipher suites, the TLS master secret is not
necessarily unique to a single TLS session. In particular, with RSA
key exchange, a malicious party acting as TLS server in one session
and as TLS client in another session can cause those two sessions to
have the same TLS master secret (though the sessions must be
established simultaneously to get adequate control of the Random
values). Applications using the EKM need to consider this in how
they use the EKM; in some cases, requiring the use of other cipher
suites (such as those using a Diffie-Hellman key exchange) may be
advisable.

Designing a secure mechanism that uses exporters is not necessarily
straightforward. This document only provides the exporter mechanism,
but the problem of agreeing on the surrounding context and the
meaning of the information passed to and from the exporter remains.
Any new uses of the exporter mechanism should be subject to careful
review.