Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland: > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko <m...@ruff.mobi> > wrote: > > Because Alice's authentication fails on this particualr conneciton? > > So it may be not Alice after all speaking, despite what 'from' > > tells (or does not). From Bob's perspective someone tries to spoof > > Alice's server over this connection. > > The question isn't whether it's a bad decision by Bob or not, but > whether it's an active downgrade. Metre, FWIW, ditches you if you try > to provide an authzid that differs from the stream "from", but it > will, I think, allow you to continue if you provide no stream "from" > and are using, for example, a wildcard cert, so there is no implicit > authzid available to it. > > > Alice, on the other hand, has already either decided to trust > > > Bob's certificate or not. Nothing Bob does at this point affects > > > that decision in the slightest, nor alters the security outcome > > > of the decision already made. So there is no downgrade attack on > > > Alice here. > > > > The EXTERNAL TLS is mutual authentication, > > EXTERNAL, with or without TLS, is absolutely not in any way mutual > authentication. EXTERNAL isn't authentication at all, actually.
Now this is nit picking. STARTTLS is not a TLS but is a way to secure connection with TLS encryption, EXTERNAL is not an authentication but is a way to execute mutual TLS x509 authentication. > > > 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) > > > By disrupting the authentication in whatever way (just to make it > > fail - eg strip from field) you will then expect the peers will > > follow new (amended) standard and retry dialback. The fact that > > other side doesn't trust our certificate (when we know it is ok) > > may mean there's broken integrity on this connection so we should > > also assume the worst and drop the connection. > > What? Why? If Alice finds Bob doesn't trust their certificate, but > Alice does trust Bob's, why would Alice worry? Because under normal circumstances the certificate is trusted hence expectation is it will be accepted. Same as if you know your credentials are valid but server does not accept it. It means something worng with the server or it is wrong server. Let's put couple examples here - we have exchanged certificate fingerprints with Alice - we both _must_ trust each other certificates. If we don't there are two possibilities - misconfiguration and mitm.- we both obtained certificates from trusted authority and expect we both trust each other. If we don't either there's misconfiguration on our side, on other side (CA might have revoked the cert) or the dark side (mitm). In other words - If Bob cares about secure communication with Alice he cares whether she trusts his certificate or not.What is suggested though is - let's ignore this and do our best to reach Availability, sacrificing Integrity and Confidentiality. > Alice's trust requirements are still met either way, and Alice can > prove there is no MITM attack on the session to Bob. > > Indeed, Alice cannot tell if Bob blindly trusts anything at all and > always offers, and accepts, EXTERNAL. Why only be concerned about > some kinds of misconfiguration? >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
