Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland: > 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. > In SASL (4422) no, in XMPP (6120 13.8.4 and the XEP in discussion) it does.
> 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. > 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. > 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, it cannot establish partially where one side trusts (authenticates) and other does not. 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. --rr
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
