On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko <m...@ruff.mobi> wrote:
> 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. > > The former would be nitpicking; the latter is not. In S2S, there are two independent authentications going on, and by the time the initiator (Alice) issues EXTERNAL, it should have already completed its authentication of Bob (and Bob should have at least decided to trust the certificate before offering EXTERNAL, with just name matching to go). If Bob rejects EXTERNAL but continues, Alice still knows Bob is the correct server. Just that Bob hasn't accepted the certificate. The only reason for Bob to then close the session is if Bob *only* accepts TLS authentication, and moreover cannot handle XEP-0344§2.4. The former is perfectly acceptable, of course, and might even be desirable - but it's not something I feel needs mandating by inference here. > > > 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). > > > 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. > > Alice knows whether or not it's the right server based on Bob's presented certificate. If Bob then turns out to not trust Alice's certificate, this doesn't affect whether or not Alice has trusted Bob's, and Bob is still proven to be the right server. If this were not the case, then there would be an attack whereby Bob *pretends* to trust Alice's credentials. > 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. > That's a fallacy - the trust relationship is, for want of a better phrase, half-duplex - Alice's trust of Bob doesn't tell you anything about Bob's trust of Alice and vice-versa. > - 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). > > Again, no - if Alice sees a valid certificate for Bob, then Alice can know there is no MITM between them. If Bob doesn't see a valid certificate from Alice then Bob cannot know that, but that affects Bob's knowledge, and not Alice's. Moreover, there is no absolute definition of a trusted authority. Perhaps Bob's admin isn't satisfied with the security offered by a CA based in some country with a worrying habit of government control. Perhaps Bob's admin isn't convinced by any certificate that doesn't use Extended Validation. Maybe Bob's server software can't handle sRVName subject alternative names (or maybe it's configured to ignore CommonName RDN matching in the subject). Maybe it pins certificates or CAs for a given domain and requires operator action if this changes. It's then up to Bob's admin, not Alice's, whether to continue the connection. Perhaps Bob does trust the certificate after all, will use the domain names given by the dialback process to complete the name-matching as per XEP-344§2.4, or maybe Bob wants to do the dialback as further verification in case of a compromised CA. All of this is up to Bob, and does not impact Alice's authentication of Bob. > 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. > > I think you may be confusing Alice and Bob here, but anyway. There is absolutely no way for either to know if the other is validating the certificate properly or not. > 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 > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
