On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko <m...@ruff.mobi> wrote:
> Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer: > > Hi list, > > > > (Editor hat on) > > > > On behalf of the Council, I’d like to bring this pull request to the > > attention > > of the community: > > > > https://github.com/xsf/xeps/pull/963 > > > > Input from server operators specifically would be welcomed to see if > > this > > change is in fact desirable or if you can see any issues with that. > > At least > > one member of the community has already expressed [1] that they think > > this may > > lead to downgrade attacks. > > > Let me rephrase/expand a bit my statement. > > The SASL EXTERNAL mandates use of TLS and certificate validation (XEP- > 0220 does not). In theory you can achieve exactly the same level of > security with Dialback as with EXTERNAL - eg. both sides still auth > each others' certificates during dialback, and similarly one can put > additional measures such as DANE + DNSEC. > > See also XEP-0344. Note that SASL EXTERNAL absolutely does *not* mandate the use of either TLS or X.509 authentication - that is simply (by far) the most common use. There are two parties involved, and while EXTERNAL is nearly exclusively offered by the Responder when TLS is in use *and* it has validated the certificates of the Initiator *and* the supplied or inferred authorization identifier matches, it says absolutely nothing about the Initiator's use of TLS, X.509, etc - whether or not the Initiator decides to use the mechanism offered. > Now if EXTERNAL fails - that means there's something wrong with the > certificates. And proposal to fail back to dialback means we want to > tolerate certificate validation errors. Which is a downgrade. > > Suggesting there is a downgrade attack here raises two important questions: By whom? Upon whom? Let's assume that Alice.example is connecting to Bob.example. Alice may, or may not, have decided to trust Bob's certificate. Bob might have decided to trust Alice's, or might not. These are completely independent choices on the part of the servers. In this scenario Bob offers EXTERNAL but then, when that is taken by Alice, it fails. There are few cases where this is sensible - one is where Alice does not provide a "from" on the stream (technically a violation) and the authorization identifier in EXTERNAL is either not present or doesn't match, one is where Alice provides a "from", but then uses a different authorization identifier in EXTERNAL (or at least one that doesn't match the certificate). Neither strike me as good behaviour by Alice, but still. At this point, if Bob is willing to let Alice use Dialback (either pure XEP-0220, or some form of XEP-0344), why shouldn't it leave the session going and allow it? In other words, the downgrade "attack" is by Bob, on Bob. 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. > Now, if we want to loosen the failure scenario, we need to explicitly > call out that this is only acceptable without loss of security controls > (validation) - eg just a misconfiguration. > > Now again EXTERNAL misconfiguration is kind of obvious - connection is > lost if integrity/confidentiality is not achievable. Dialback does not > put anything like that in place to ensure that. > > Regards, > Ruslan > > _______________________________________________ > 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 _______________________________________________
