Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland: > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko <[email protected]> > wrote: > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland: > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko <[email protected]> > > > wrote: > > > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland: > > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko < > > > > > [email protected]> wrote: > > > > > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave > > > > > > Cridland: > > > > > > > > it cannot establish partially where one side trusts > > > > > > > > (authenticates) and other does not. > > > > > > > > > > > > > > You can very much establish a TLS session where one side > > > > > > > authenticates by the certificate presented but the other > > > > > > > side does not. > > > > > > Not if you mandate mutual TLS auth (request cert) > > > > > > > > > > "Mutual authentication" means both sides authenticating the > > > > > other in the same action. Here, both sides can authenticate > > > > > the other, but need not. Either side is entirely free to > > > > > ignore the certificate for any number of reasons. (The > > > > > confusion arises because all SASL mechanisms that support > > > > > server authentication are by definition mutual > > > > > authentication). > > > > Yes, this is exactly the point. But not only that, by mandating > > > > SASL external over TLS you also mandate TLS mutual > > > > authentication (which happens within the same protected > > > > channel). > > > > > > > > > > > > > > Ah, no. Because SASL EXTERNAL isn't an authentication at all, > > > there's no implication of mutual authentication (and often isn't > > > any bidirectional either). > > Maybe I'm not aware of other uses of EXTERNAL auth but when I > > wanted to implement EXTERNAL support in XMPP to advertise it in > > mechanisms and expect interoperability with other client/servers I > > need to request client certificate (set_verify_mode VERIFY_PEER) > > and then validate received certificate. If that is not mutual TLS > > auth then I'm not sure what that is. > > It's client authentication. > > You can do this whether you have a certificate or not yourself - > though it's fair to say if you don't have a certificate, then very > few clients or initiating servers will talk to you at all. > > But you absolutely can do this with a self-signed certificate. > Whether anyone connects to you at *that* point is a matter of their > policy, not yours. > Sorry I don't follow you here. _How_ you trust the certificate is your *policy* . The fact that a party *must* have a certificated trusted by your policy is authentication. If I am Bob and I trust Alice's certificate, but Alice doesn't trust mine - could be a policy thing of course. Because Alice may only accepted certificates issued by hereself or signed by her boyfriend. It's her decision. But it's a closed system. In open system TLS validation [policy] is pretty much written down and fixed in 13.7.2 (eg 13.7.2.2.1) and if I follow this *policy* while connecting to open system and that opens system doesn't trust myself I have two conclusions - either it is misconfigured or it doesn't actually see *my* certificate but rather someone else's. Especially this is valid if we are part of closed system and my certificate was signed by Alice's boyfriend. > > > > > > > Nevertheless I just realized the whole mechanism proposal part > > > > is not protected by the SASL so any ill-minded adversary can > > > > easily suppress EXTERNAL and enjoy dialback-only. So based on > > > > that I recall my downgrade statement - the attack vector > > > > requires level of exposure (TLS airgap with trusted > > > > certificate) which invalidates the whole mechanism and thus any > > > > imposed by it identity/confedentiality protection. > > > > > > So you now think that SASL EXTERNAL as a whole is subject to some > > > kind of downgrade attack? > > > > > > Could you please explain this, because it sounds entirely wrong > > > to me. > > > > > No, external is not a downgrade. Just to make (ab)use of external > > dowgraded to dialback you need level of interception which makes > > dowgrade by the PR in scope redundant as you can achieve the same > > outcome (dialback) regardless of whether the external behaves as in > > current XEP0178 edition or as in proposed modified one. > > Ah, OK. Still not a downgrade, as Alice can still authenticate Bob in > exactly the same way, and to suppress EXTERNAL you'd need an > integrity attack against the session, which'd currently be heavily > mitigated by Alice having authenticated Bob's certificate. >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
