Subject: Re: [TLS] '15 TLS Fall Interim Minutes

From: Sean Turner <[email-masked]>
Date: Tue, 6 Oct 2015 19:22:53 -0400

On Sep 22, 2015, at 19:27, Sean Turner <[email-masked]> wrote:

> I’ve gone ahead and posted the minutes/list of decisions to:
> 
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
> 
> spt

Revised minutes posted to the same link.

spt

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Oct 2015 11:29:53 +0200

The notes from the interim meeting mentions 'tls-unique' and points to
issue #228 on github.  I want to get your attention on the draft below.
Doesn't it do what you are looking for?  There is a little in the way of
a problem statement in the TLS interim meeting notes, so it is hard to
tell what the perceived problem with 'tls-unique' is in this context.
Does my draft need to be updated for TLS 1.3 in any way?  It might serve
as a starting point for future work.

https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Oct 2015 12:04:51 +0200

> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

Well, TLS 1.3 doesn't have a PRF, but instead explicitly uses HKDF.

With that said, I don't really understand the structure of your draft:
Instead of referencing the PRF and session_hash directly, why not instead
use RFC 5705 exporters and require the use of the session_hash extension?
Then TLS 1.3 can just define exporters for 1.3 and we'll be done.

-Ekr

> /Simon
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Oct 2015 12:16:23 +0200

> use RFC 5705 exporters and require the use of the session_hash

The introduction says:

   There exists a TLS extension [I-D.ietf-tls-session-hash] that modify
   TLS so that the definition of 'tls-unique' [RFC5929] has the intended
   properties.  If widely implemented and deployed, the channel binding
   type in this document would not offer any additional protection.  The
   purpose of this document is to provide an alternative channel binding
   that offers the intended properties without requiring TLS protocol
   changes.  However, keep in mind that TLS implementations needs to
   offer the appropriate APIs necessary to be able to implement the
   channel binding described in this document.

I agree that one alternative is to require session_hash for all
connections.  But then what is the problem with use of 'tls-unique'?
The github issue and the interim notes aren't clear on that.

> Then TLS 1.3 can just define exporters for 1.3 and we'll be done.

Right.  My draft intends to use TLS exporters but I see that it isn't
aligned with RFC 5705.

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Oct 2015 12:23:13 +0200

On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson <[email-masked]>
wrote:

> connections.

Given that you need to modify *some* software in any case, it seems
like one ought to adopt session-hash.

>   But then what is the problem with use of 'tls-unique'?
>

The general consensus is that 96 bits is too short.

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 8 Oct 2015 13:20:25 +0200

> > The introduction says:
> >
> >    There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > intended properties.  If widely implemented and deployed, the
> > channel binding type in this document would not offer any
> > additional protection.  The purpose of this document is to provide
> > an alternative channel binding that offers the intended properties
> > without requiring TLS protocol changes.  However, keep in mind that
> > TLS implementations needs to offer the appropriate APIs necessary
> > to be able to implement the channel binding described in this
> > document.
> >

The problem is if you want to resolve this at the application level and
don't have sufficient control over the TLS layer to influence it to
negotiate session-hash.  This is the situation for many SASL
applications.

If universal adoption of session-hash is a prio, then there is no
problem.  While RFC 7627 updates 5246 it does not talk a lot about what
it actually updates in 5246, or I missed it, and I haven't seen
session-hash functionality back-ported to deployed code.

My current approach works with or without session-hash negotiated, but
requires that you can get the session_hash value out of the TLS stack.

Another approach is to say that if session-hash is in use, it uses a
simple TLS exporter API call, and if it is not, it has to use TLS
exporter API on the session_hash value.  This would secure all cases.

> The general consensus is that 96 bits is too short.

I agree -- I used 256 bits.

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Oct 2015 13:55:53 +0200

> session-hash functionality back-ported to deployed code.

I'm not sure what you mean by "backported", but I believe that BoringSSL
presently has session-hash, SChannel has it soon or does already, and
the next version of NSS (3.21) will have it.

> requires that you can get the session_hash value out of the TLS stack.

I am not aware of a stack which has this function. Are you?

-Ekr

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 08 Oct 2015 14:36:42 +0200

> the next version of NSS (3.21) will have it.

If session-hash isn't backported to deployed code, like some other
security fixes has been backported (e.g., secure renegotiation), it will
take years until it is deployed.  Using only an TLS exporter interface
will therefor be insecure meanwhile, as far as I understand, since it
doesn't bind the entire handshake messages.

However, you could have a new TLS channel binding based on the TLS
exporter interface that demands use of session-hash, as you suggest.

> I am not aware of a stack which has this function. Are you?

No.  Either the application inspects the handshake or code has to be
added.

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 8 Oct 2015 16:05:17 +0300

> Then TLS 1.3 can just define exporters for 1.3 and we'll be done.

TLS 1.3 is different since TLS 1.3 always behaves like session_hash was
negotiated, whereas session_hash was a security fix for earlier versions.

One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with:

label: "TLS 1.3 tls-unqiue"
context: No context
Length: 256

And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some
better way at handling both context and no context cases? In original
RFC, those were different):

tmp = HKDF-Extract(label, exporter_secret)
output = HKDF-Expand(tmp, 0x01 | context, L)

or (no context case)

tmp = HKDF-Extract(label, exporter_secret)
output = HKDF-Expand(tmp, <blank>, L)

This is slightly different from other uses of HKDF. I don't mix in
session hash since exporter_secret is already Secret Nonce.

-Ilari