[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms
sam at samwhited.com
Wed May 6 16:44:48 UTC 2020
It sounds like I should have added a design considerations section to
the ProtoXEP, I knew that having non-registered mechanisms would be
controversial so I should have known to go ahead and do this. Sorry
On Wed, May 6, 2020, at 11:37, Daniel Gultsch wrote:
> However I don’t like the syntax at all and would like us to either
> find a different syntax
What is it that you don't like about the syntax specifically? For my
part, I implemented this and it only took a couple of minutes to update
my existing SCRAM implementation and worked exactly as expected.
Also, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are already effectively doing
this, the "-PLUS" suffix has to be parsed off to see if you want to add
the channel binding information, so adding another suffix to tell you
exactly what that information should be seemed like the logical next
step to me.
> Doing SCRAM-*-PLUS only for TLS1.3+ feels like an OK compromise to me.
I would be okay with that too for that matter, but it's not clear to me
where we would make that recommendation. The SCRAM RFC says that tls-
unique is the default, but it's not defined for TLS 1.3. I suppose we
could try to convince KITTEN to update the document for TLS 1.3, but
that seems like a lot of work and time and doesn't help us if we end up
finding problems or needing other mechanisms later (for example, right
now my new channel binding type only defines a version that uses the
exporter on the master secret, but you can also create exporters with
the early master secret in 0RTT mode; if a separate mechanism were to be
created for that case later, we might want to also support it and we'd
be right back here).
More information about the Standards