Subject: [http-auth] [Mutual] answers for FAQs (2) Methods for TLS channel bindings

From: Yutaka OIWA <[email-masked]>
Date: Fri, 4 Oct 2013 08:54:42 +0900

Deal all,

second commonly-asked questions to answer is about how the protocol
bind itself with the underlying connection channels.
Currently, a TLS channel binding mechanism has an RFC standard,
and our scheme defined a separate mechanism in Section 7.
We've listed this as an item for possible future consideration in
Appendix A.  I'll answer "why" doing so, and "what" I think we should do.

* Why

As the time of writing the first revision of our proposal, there was simply
no such scheme defined as the standard.  It was not a re-invented wheel,
but acutually parallel-developed wheels.

Of course, at that time there was no implementation support for the
current standard,
and things defined in the current standard (issued as an I-D which we noticed
shortly after our design) really requires additional implementation
code inside TLS libraries.
We had no ways to implement that at that time.
Our alternative design, on the contrary, was *able to be* implemented with
existing TLS libraries at that time without modification.

* What we should do

I currently do not have enough information about the implementation status of
the current standard mechanism.  If you have any summary of that, I
really appreciate it.
That is the only reason that we're suspending technology migration.
If we have enough support for that mechanism, I'm  simply happy to migrate for
the newer standard mechanism.

* Why again (appendix: possible reasons for the design difference)

Generally speaking, using a raw key as a binding material is often risky against
information leakage.  As a general vehicle for unrestricted applications,
it seems infeasible to use it.  I guess that is the reason why the
current standard
uses a TLS Finished message instead.  However, if the implementation
do not support the standard explicitly, the Finished message is a
volatile thing which is generated on-demand during negotiation and then
discarded (as it is not required anymore after that).  After finished
negotiation,
we have absolutely no way for regenerating the Finished message for
channel binding.  That's why the current standard required explicit
implementation support.

On the contrary, the raw key is rather a permanent thing which is often
kept until the TLS protocol really terminates.  It was, and it is,
available from the internal structure of many TLS libraries, or in some cases,
even through debugging facilities implemented in the libraries.
In our use cases, that raw key is always mixed and hashed with
random numbers with larger entropy, so there is no direct risk for
retrieving/guessing the raw key from eavesdropped traffics.
That's why we chose this design in the past.

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 8 Oct 2013 23:57:36 +0900

An additional note to the my previous answer:

(1)
main discussion around here seems to be something
around our tls-key and RFC-5929 "tls-unique" binding.
However, currently I also consider dropping tls-key binding
completely.
(It's only significant for use with anonymous D-H exchanges.)

Alternatively, I expect we mainly use tls-cert verification.
It uses a server certificate as a binding key,
This correspond to RFC-5929 "tls-server-end-point" binding.
The difference between these two are quite minor.

Regarding running code, both can be implemented at this moment.
Without library support, our one is easier to implement.
With explicit library support, RFC 5929 is easier.

We have a small interest to discuss the "correct" design
on the cryptographic context,
but, in short, after having a talk to clarify security strength differences
and having a consensus on having such changes (possibly weaking
security in some cases),
adopting tls-server-end-point is quite acceptable for us.

(Only "weaking" difference is that RFC-5929 will use SHA-256 instead of SHA-512
when certificates are signed with MD5, SHA-1 and SHA-256, and
our Mutual key exchange will go on with stronger SHA-512 hash.
On the contrary, if Mutual key exchange uses SHA-256 and certificate
has SHA-512 signature, RFC-5929 will use stronger SHA-512 while ours
use SHA-256.)

(2)
Assuming that we go to implement tls-key regardless of above (1) discussion,
Quickly searching around Internet and looking for changelogs,
we currently see only several proposed patches for tls-unique binding.
We're really appreciating information about already-adopted implementation
of RFC 5929 (especially for "tls-unique").
We really need either implemented or implementable algorithms,
but, as repeating my previous words, once it's widely implemented
we're happy to use it.
Or, do we have strong motivation and power to promote its implementations?