On Tue, 27 Sept 2022 at 11:51, Matthew Wild <[email protected]> wrote:
> On Tue, 27 Sept 2022 at 11:36, Dave Cridland <[email protected]> wrote: > > On Tue, 27 Sept 2022 at 09:59, Matthew Wild <[email protected]> wrote: > >> > >> On Tue, 27 Sep 2022, 09:46 Dave Cridland, <[email protected]> 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. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
