[Standards] Channel binding and token authentication

Matthew Wild mwild1 at gmail.com
Tue Sep 27 10:50:46 UTC 2022

On Tue, 27 Sept 2022 at 11:36, Dave Cridland <dave at cridland.net> wrote:
> On Tue, 27 Sept 2022 at 09:59, Matthew Wild <mwild1 at gmail.com> wrote:
>> On Tue, 27 Sep 2022, 09:46 Dave Cridland, <dave at cridland.net> wrote:
> I'd not considered web clients - can they not obtain the server certificate at all, even these days?

I'm not aware of any method to do so (which is certainly a shame).

> - I'd assumed that all clients could use tls-server-end-point fairly easily. If that's not the case for web clients, that's clearly a problem.
> - As a client, it's impossible to tell whether a server is validating the channel binding data or simply blindly accepting it anyway.
> - Ideally, even with TLS termination before the XMPP server, the XMPP server can discover or be configured with its TLS certificate so it can verify that.

Sure, in Prosody we default to the configured certificate but allow
manually providing a hash to allow for setups where TLS is handled

> - I seem to remember that HT-* derives a lot of its replay protection from the channel binding, so we may want to have *something* there.

What is the attack scenario here? Someone compromised TLS?

>> Unless I'm misunderstanding your proposal.
> Well, my proposal is to think about it a bit before we commit, so maybe you're unwittingly accepting it anyway?

I propose to consider that you might be right.


More information about the Standards mailing list