Subject: [http-auth] (mutual:P9) Re: possible discussions / call for opinions

From: Yutaka OIWA <[email-masked]>
Date: Wed, 18 Mar 2015 10:10:45 +0900

Dear Ilari,

2015-03-16 23:09 GMT+09:00 Ilari Liusvaara <[email-masked]>:

>> [P9] Do we really need tls-unique for general HTTP?
>>      (It is too complex for actual implementation,
>>       because authentication life-duration spans
>>       over multiple HTTP requests and
>>       multiple TLS connections.)
>
> Yes, but one HTTP request can't span multiple TLS connections,
> which makes this thing actually feasible to implement.

Key point is that whether we need to verify the consistency of
the binding among multiple requests, especially for POST/PUT request.
For the certificate-based host authentications, the answer is no:
the verified certificate is enough, but tls-server-endpoint works in this case.

> However, there is a relevant security bug in the TLS protocol itself:
>
> Specifically, if one: Establishes the session without certain (not yet
> standardized) extension [extended_master_secret, which is built-in in
> TLS 1.3 draft], does not check keys (those are often impossible to
> check) and then resumes the session, the attacker can break
> tls-unique channel binding.

Thank you very much for the clear description of
the situation.  I've once seen some note about
vulnerability, possibly in TLS ML, but
did not competely understand the details.

So, do you know how people can fix it for the future?
Is problem going to be fixed in TLS 1.3, or
a new, fixed binding will be required?
Or, not yet decided, simply?

-- 
Yutaka OIWA, Ph.D.
           Senior Researcher, 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: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Mar 2015 09:21:17 +0200

> Or, not yet decided, simply?

As I noted above, there are two fixes:
- TLS 1.3 (fixed in -03, latest is -05).
- extended_master_secret extension (a.k.a. session-hash)

Both are drafts (the latter is holding incorporating WGLC feedback,
but still has preallocated extension codepoint).

-Ilari

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 25 Mar 2015 03:56:47 +0900

Dear Ilari,

On 2015/03/18 16:21, Ilari Liusvaara wrote:
>...

Thank you very much.  Could I ask one more help on it?

How do you think whether I should write something into my current draft,
something like "Use either TLS-1.3 or extended_master_secret when you use
tls-unique"?  Or, the fixes will be "automatic" in the IETF standards?

-- 
Yutaka OIWA, Ph.D.
          Planning Officer, Research Planning office for IT and Electronics
    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: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Mar 2015 21:48:32 +0200

> tls-unique"?  Or, the fixes will be "automatic" in the IETF standards?

Well, draft-balfanz-https-token-binding-00 section 4.3 contains some text.

This does not take resumption into account. The reason might be that
HTTP authentication layer might not know if resumption has taken place
or not.

-Ilari