Re: [kitten] Request for review of a SASL mechanism using the OPAQUE aPAKE

[Florian Schmaus <[e-mail]>]

On 10/10/2022 09.15, Simon Josefsson wrote:
> - Require TLS channel bindings.  I don't think there is sufficient
>    use-cases ofr non-TLS settings for IETF application protocols any more
>    (and those that may exist aren't likely to be using state-of-the-art
>    authentication protocols -- and can always profile a mechanism if
>    necessary).  The recent RFC9622 tls-exporter has sufficient properties
>    to always be included in authentication.  Having an optional TLS
>    channel binding also leads to sub-negotiation between PLUS and
>    non-PLUS variants.

Dave already wrote that requiring channel binding is problematic.

I have been recently asked to introduce a non-channel-binding variant in 
draft-schmaus-kitten-sasl-ht [1], as this gets implemented in part of an 
effort to create an XMPP mechanism for instant / fast reconnects. It 
appears that XMPP *web* clients are unable to retrieve the channel 
binding data from browser APIs, and hence need a fast reconnect method 
that does not require channel binding.

So while there is a good reason to encourage channel binding, especially 
with tls-exporter now being available, we should not require it.

- Flow

1: https://datatracker.ietf.org/doc/draft-schmaus-kitten-sasl-ht/