[Standards] Fwd: [Uta] STARTTLS vulnerabilities

Dave Cridland dave at cridland.net
Fri Aug 13 13:47:57 UTC 2021


On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre <stpeter at mozilla.com> wrote:

> On 8/11/21 3:35 PM, Kim Alvefur wrote:
> > On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote:
> >> Too bad we didn't stick to our guns in 2003 and insist on two ports
> >> instead of one, but STARTTLS was the recommended approach back then...
> >
> > We were always at war with STARTTLS?
>
> We would have preferred to keep using port 5223 for TLS-only, but at
> that time (2003/2004) IETF/IESG policy was "don't use so many ports,
> STARTTLS makes it so that you only need one".


That's not the only argument, and was always the least interesting.

See: rfc2595 (ietf.org)
<https://datatracker.ietf.org/doc/html/rfc2595#section-7>

The single biggest change since then (where "then" is 1999) is that all the
other channel encryption technologies have vanished - nobody uses anything
but TLS, whereas back then, TLS was but one encryption possibility, and
Kerberos, for example, was often a better choice. TLS certificates were
annoyingly expensive, most people used self-signed or nothing at all, and
many of us believed Kerberos and similar, lacking the CAs, would take over.
Even the ports argument was slightly more relevant since the significance
of ports below 1024 was still considered important. In the intervening
years, CAs have become cheaper, and indeed free. TLS implementations have
become ubiquitous. Export laws have relaxed. A lot of us hoped for these
events but had no idea of a timeframe.

The change to universally use TLS as the channel encryption means that of
the four points in the RFC, two of them no longer apply, and the first
never applied to XMPP in the first place. XEP-0368 solves the remaining
quibbles over the remaining points, leaving the "twice as many ports" the
remaining argument - which was always weak on a SRV-based protocol anyway.

Hindsight, and existing arguments at the time, make it look in retrospect
like StartTLS was always a poor choice, but nearly 20 years ago the rough
consensus was indeed opposed. Back then I would have comfortably argued for
StartTLS - these days, I'd be arguing the other way. Times change, and we
adapt. Last time I chatted with Chris Newman, who wrote RFC 2595, he said
it was a bad mistake - but I disagree, it was the correct choice for the
time and circumstances. It isn't any longer, and we can, should, and do
encourage "Direct TLS".

We should be pushing XEP-0368 to Final and move it to Core in compliance.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20210813/cb4ad8bc/attachment.html>


More information about the Standards mailing list