[Standards] Advance XEP-0368 to Proposed

Dave Cridland dave at cridland.net
Tue Jan 24 14:01:12 UTC 2017


On 24 January 2017 at 13:38, Travis Burtrum <travis at burtrum.org> wrote:
> On 01/24/2017 08:08 AM, Kim Alvefur wrote:
>> On Thu, Jan 19, 2017 at 03:19:12PM -0500, Travis Burtrum wrote:
>>> I am proposing advancing XEP-0368 from Experimental to Proposed, and the
>>> XSF MUC said to do this by sending an email to the standards list.
>>>
>>> https://xmpp.org/extensions/xep-0368.html
>>> Any thoughts?
>>
>>
>>> TLS provides more security than STARTTLS if RFC 7590 [4] is not
>>> followed, as it isn't subject to STARTTLS stripping.
>>
>> I strongly object to this. "Direct" TLS and STARTTLS is exactly
>> equivalent security-wise. In the absence of DNSSEC, you can just as well
>> strip the SRV records that point to the "direct" TLS port, and you can
>> attempt STARTTLS even if the advertising is stripped, or give up and
>> throw a security exception.
>>
>> I assert that this is only an optimization that lets you skip a few
>> round trips.
>
> Both are equally susceptible to DNS attacks in the absence of DNSSEC.
>

(And this is by far the simpler attack).

> But you basically said it yourself, "Direct" TLS and STARTTLS are
> equivalent security-wise ONLY IF you attempt STARTTLS regardless of
> offer and give up with a security exception otherwise.  That behavior is
> enforced with direct TLS, therefore they are not equivalent.
>

This is true, however while the integrity of unencrypted TCP can be
compromised by spoofing and similar, it's mostly likely to be
compromised by an MITM attack, at which point the "send anyway" school
of thought doesn't gain you much. This is because the DNS spoofing
attack required to MITM is vastly simpler than mounting the TCP level
attack.

Moreover, since '368 mandates that records are treated equally, the
attacker can - in the absence of DNSSEC - spoof the records for an
MITM in exactly the same way regardless of whether 368 is supported
and/or deployed by either party.

> We could say something like that in there, but I'm not sure how to word it.

"One vastly more complex attack can't be mounted anymore, but the
really simple attacks still can?"

I agree with Kim: absent DNSSEC, a downgrade attack is no harder with
'368 supported than without.

With DNSSEC, a downgrade attack - which should only yield a denial of
service - based around TCP spoofing is removed.

> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________


More information about the Standards mailing list