[Standards] Fwd: [Uta] STARTTLS vulnerabilities

Peter Saint-Andre stpeter at mozilla.com
Fri Aug 13 15:21:58 UTC 2021


On 8/13/21 7:47 AM, Dave Cridland wrote:
> 
> 
> On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre <stpeter at mozilla.com
> <mailto: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".

Hey Dave, thanks for the history lesson. :-) It's easy to forget that
the technical landscape was quite different in 1999. Indeed, XML was the
new hotness back then!

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

Agreed.

Peter



More information about the Standards mailing list