[Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

Ruslan N. Marchenko me at ruff.mobi
Tue Jun 30 16:58:49 UTC 2020


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.

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.

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



More information about the Standards mailing list