Subject: [http-auth] [Asking for technical suggestions] re: changing TLS channel binding mechanisms

From: Yutaka OIWA <[email-masked]>
Date: Wed, 9 Oct 2013 03:25:20 +0900

Dear all,

thank you for good suggestions and discussions on the interim meeting.
After having the discussion, my minds are going to make changes
regarding TLS channel binding mechanisms.  Two topics exist:

(1) Regarding tls-key mechanism, I'm going to replace it with RFC 5929
"tls-unique" mechanism.
This mechanism is rather "experimental" (even within experimental I-D)
in real use cases, so I'm convinced that it's a good thing to go forward
with promoting new channel-binding standard, encouraging changes to underlying
TLS implementations, even if current implementations do not support it.

I do not see any security issue about this change.
If you have any comment about security implication of this change
on the bad side, please let me know.

(2) Regarding tls-cert mechanism, I also consider replacing it with
RFC 5929 "tls-server-end-point" mechanism.
It's a little bit more difficult to implement RFC way than our way without
library support, but it's still implementable, so I'm OK regarding
implementation issue.

I'm basically happy with using standard mechanism as far as it is OK.
However, I want to confirm whether it is OK or not, regarding security.
I have one thing which I'm not completely certain with, so I am asking
for a clue.

<long, strongly technical description follows>

These two constructions are quite similar, both using hash of the body of
the server certificate as a binding key, but choices of hash functions
differs as following:

  * My tls-cert proposal uses hash function which is used within
    PAKE key exchanges within Mutual HTTP authentication.
    As its strength is the same as the security strength
    which Mutual itself assures, the construction is straightforward.
    And that's why we constructed in this way, before having RFC 5929
as a standard.

  * The tls-server-end-point standard uses the hash function which is
    used by the CA to sign the certificate.  However, if it were MD5 or SHA-1,
    SHA-256 is used instead.

Under this setting,
if people uses stronger 4096-bit Mutual authentication with SHA-512,
and underlying TLS uses a certificate still signed with 256-bit hash functions,
the RFC standard will generate a 256-bit binding key, weaker than my
current proposal.
This is the difference I am not completely sure it's OK.

My question is, in short, is it acceptable to use 256-bit binding key
in this case?
More precisely, if the certificate's signature is only 256 bit,
can we say that we only have 256-bit-hash-equivalent security anyway in TLS,
and it is not very worthful to generate 512 bit binding keys?
(This logic may lead to a contradiction, however, because it implies that
 having a 256-bit binding key is worthless when cert is signed with 128-bit MD5,
 meaning RFC 5929 construction being odd.)

Answers may be:
 (a) It's OK, no security issue here. a 512-bit binding key is
worthless with this case.
 (b) Strictly speaking a 512-bit key is preferable, but a 256-bit key
is mostly OK in this case.
 (c) A 512-bit key is preferable, a 256-bit key is certainly weaker,
but the difference is
      not "significant" to make a deviation from current standards.
 (d) A 256-bit key is no-go in this case.  We should not use the standard.
 (e) other than any of above.

</technical description>

I will personally explain the situation face-to-face in Vancouver if
you are kindly
going to make a suggestion but the above description is not enough for
decisions.
I will also invetigate this issue further by myself, and post again to
this ML if I found more.

If you have a clear intuition on answer (a) or (b), please let me know.
Again, I'm happier on answers (a)-(b) than having answer (d).
(C) is mostly unhappy, as we need to make a security decision in WG.
But my current guess is something around case (c).

Especially in case (c), I want to have a strong WG consensus before
making this change,
not only from my personal intention to do so.

# P.S. Regarding that RFC 5929 hardcoded the 256-bit security strength
of hashes,
# I guess why they did, I guess I'm understanding that they needed to do so,
# but I am still seeing it as technically "odd".

Thanks,

-- 
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]