Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding

[Nico Williams <[e-mail]>]

On Sat, May 23, 2015 at 11:57:07PM +0100, Stephen Farrell wrote:
> On 23/05/15 23:44, Simon Josefsson wrote:
> > Perhaps this is a question for the TLS WG -- whether they intend
> > tls-session-hash to apply as a mandatory fix to all TLS versions or
> > not.  The document does not say anything about updates now, which means
> > "TLS needs fixing" won't necessarily happen.
> 
> So this may be helpful or not depending on how much one
> considers IETF minutae important...

We've discussed this in the TLS WG.  There was no consensus call as
such, so... I don't know what the status is.

Regardless, it's not really appropriate for a SASL/GSS mechanism to
introduce a new TLS channel binding.  Nor is it necessary assuming that
TLS is fixed to use the session hash.

It would be appropriate to:

a) add security considerations text about the dangers of using
   tls-unique with an unpatched TLS implementation with resumed
   sessions;

b) separately pursue a new TLS channel binding, though perhaps having
   an informative references from any new SASL/GSS mech(s) on the new
   TLS channel binding.

   Normative references would belong in the _application_ protocols, not
   the SASL/GSS mechanism.

There isn't consensus for (b) yet.  I'm not against it, but I note that
it shouldn't be necessary.  The TLS session hash fix has to get
deployed, full stop.

> During IESG evaluation we agreed to have the session hash
> document be an update of 5246. The start of that thread is

It should probably also update RFC5929.  I made a comment as to that on
the DISCUSS.  There was no further discussion.

> at [1] and the resolution is downthread or maybe in some
> other thread but was on the TLS list. The update to the
> draft hasn't yet happened but will shortly.
> 
> The impact is that our formalities then expect any new TLS
> code to include session hash. But that of course does not
> affect already deployed code so make of that what you will.

The same is true for adding new TLS channel bindings, and adding
security considerations text to new SASL/GSS mechanisms about that:
existing TLS stacks and applications won't be using the new TLS CB.

But fixing TLS stacks to use the session hash can be done in a
backwards-compatible way at the API level, and so fixing TLS *is* the
right thing to do, and the only thing that will fix existing apps
without having to change them.

That's why I much prefer focusing on getting the TLS session hash
deployed.

> Cheers,
> S.
> 
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg16231.html

My reply is at

https://www.ietf.org/mail-archive/web/tls/current/msg16335.html

Nico
--