[Standards] Channel binding and token authentication

Dave Cridland dave at cridland.net
Tue Sep 27 11:30:04 UTC 2022

On Tue, 27 Sept 2022 at 11:51, Matthew Wild <mwild1 at gmail.com> wrote:

> 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).
Indeed... Never occurred to me there wouldn't be, especially these days
with Crypto.subtle and things.

> > - 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
> externally.
> > - 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?
Any case where an attacker obtains the SASL exchange itself, or can replay
it by some other means (I think TLS Early Data has some weaknesses here).
I'm not convinced this is very exploitable in any useful way, but I think
it might be enough to do something in some cases.

I'm not sure that tls-server-end-point doesn't have the same weaknesses
with HT-*, mind. (IoW, I think it might have the same problems as no
channel binding at all, because it's a fixed string).

> >> 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.

But note that there's at least three different problems here:

- Do we need to specify an HT-*-NONE (or at least, something similar)? The
answer to this is "probably, yes".
- Can we minimize the need to use this, and encourage developers down a
better path? I think we're in agreement that there's some good advice we
can usefully give in some cases, but sadly not all.
- Does a simplistic HT-*-NONE have some issues we'll want to address
carefully - possibly to the point that we actually need something different
in this case? Again, "probably, yes".

It might be that HT-* in general has much higher security than HT-*-NONE,
and it might be that we just have to live with that.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220927/1272659a/attachment.html>

More information about the Standards mailing list