Subject: Re: [saag] [kitten] AD sponsoring draft-hansen-scram-sha256

From: Simon Josefsson <[email-masked]>
Date: Sat, 23 May 2015 16:35:26 +0200

> I have a separate question: would there be value in defining a new
> session-level channel binding (updating rfc5929) based on
> tls-session-hash?

I offered
https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 as an
alternative to tls-unique back in the days.  The issue with using only
the client/server-random (a'la TLS Finished) was discussed back then
and for -01 in 2008 I fixed the construct to be more secure (credit to
Eric Rescorla and Sam Hartman who made me aware of the concern).

My draft derives the channel binding in a way similar to
tls-session-hash.  I would appreciate if you could take a look and tell
me if you believe that it would solve the triple-handshake concern.

/Simon

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 23 May 2015 08:07:17 +0200

>> We have a solution for that:
>> https://tools.ietf.org/html/draft-ietf-tls-session-hash

If a TLS connection uses the tls-session-hash, the tls-unique channel binding becomes
a good channel identifier for use in SCRAM (avoiding Triple Handshake-style attacks).
So either SCRAM could require tls-session-hash, or we could update RFC5929 to require it
(in the same way that it already requires RFC5746).

I have a separate question: would there be value in defining a new session-level channel binding (updating rfc5929)
based on tls-session-hash?

The advantage would be to obtain authenticated session resumption.
That is, once a client has used SCRAM to authenticate on one connection, it can reuse that credential
on all resumed connections, until a new full handshake is performed. I don’t know how commonly
we use session resumption in non-web scenarios, but the vast majority of connections initiated by
web browsers use abbreviated handshakes.

Best,
Karthik

> 
> Then SCRAM-SHA256 should normatively references that and require that
> it is implemented for secure use of SCRAM with channel bindings.  There
> are drawbacks with that approach: it is not widely implemented, not
> published as an RFC that updates earlier TLS versions, and difficult
> for SCRAM implementers to validate (usually the TLS stack is opaque to
> the SCRAM implementer).  I could live with that though, as a way of
> pushing the current security problem down from the IETF protocol layer
> into the implementation layer.
> 
> Alternatively, use a new channel binding type that use the extended
> master secret derivation as described by the document above.  I could
> update draft-josefsson-sasl-tls-cb to describe this approach.
> 
> /Simon
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten