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 about that.
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). —Sam -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
