Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Peter Saint-Andre]

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

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Dave Cridland]

On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre  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)


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.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Ruslan N. Marchenko]

Am Mittwoch, dem 11.08.2021 um 14:25 -0600 schrieb Peter Saint-Andre:
> 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...
> 
I am still not convinced the STARTTLS is ultimate evil. SMTP had way
too many bugs in its implementation over its history, still no one
considers it evil. And that's just yet another of those bugs. And
considering network transparency becomes bigger rarity nowadays - port
multiplication is a must. And we are yet to see how many of similar
bugs will be in alpn/sni implementations.

--rr

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Sam Whited]

We've had this discussion before but for context in this thread: I
ignore that as it doesn't make any sense (and follow the second thing
and just decide myself how I want to connect). I know at least one or
two others do to, but I don't know which strategy is more wide spread.

—Sam

On Thu, Aug 12, 2021, at 09:16, Holger Weiß wrote:
> | Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same
> | record with regard to connection order as specified by RFC 2782 [3],
> | in that all priorities and weights are mixed. This enables the
> | server operator to decide if they would rather clients connect with
> | STARTTLS or direct TLS. However, clients MAY choose to prefer one
> | type of connection over the other.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Holger Weiß]

* Sam Whited  [2021-08-11 17:21]:
> In my experience it's widely supported these days.

At least for c2s, yes.

> I also don't know if clients prioritize these records over starttls.

XEP-0368 says:

| Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record
| with regard to connection order as specified by RFC 2782 [3], in that
| all priorities and weights are mixed. This enables the server operator
| to decide if they would rather clients connect with STARTTLS or direct
| TLS. However, clients MAY choose to prefer one type of connection over
| the other.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Martin]

Quoting Kim Alvefur :

We were always at war with STARTTLS?


The world is at war with both ports < 443 and ports > 443.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Philipp Hancke]

Am 11.08.21 um 23:49 schrieb Peter Saint-Andre:

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".


ah, one port is enough. But I do wonder if the old technique from 
https://github.com/mawis/jabberd/blob/8c99ba9d56574044770c7513acd11c9072488203/jadc2s/clients.cc#L1289-L1301

(18 years...) is documented in some IETF document.
There is
  https://datatracker.ietf.org/doc/html/rfc5764#section-5.1.2
but it only applies to DTLS.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Peter Saint-Andre]

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".

Peter
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Kim Alvefur]

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?

--
Zash


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Sam Whited]

In my experience it's widely supported these days.

Out of the 119 providers on the jabber.at server list 74 of them (62%)
have xmpps records (though I did not test whether these resulted in a
successful connection with a reasonable TLS configuration). I also don't
know if clients prioritize these records over starttls.

—Sam

On Wed, Aug 11, 2021, at 16:13, Philipp Hancke wrote:
> tl;dr: its a mess. What is the deployment state of xep-0368?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Peter Saint-Andre]

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...

On 8/11/21 2:13 PM, Philipp Hancke wrote:
> tl;dr: its a mess. What is the deployment state of xep-0368?
> 
> Am 11.08.21 um 19:08 schrieb Peter Saint-Andre:
>> Perhaps of interest here...
>>
>>
>>  Forwarded Message 
>> Subject: [Uta] STARTTLS vulnerabilities
>> Date: Wed, 11 Aug 2021 17:42:40 +0200
>> From: Hanno Böck 
>> To: u...@ietf.org
>>
>> Hi,
>>
>> I wanted to share some research we have done on vulnerabilities in
>> STARTTLS implementations:
>> https://nostarttls.secvuln.info/
>>
>> We started analyzing STARTTLS implementations in E-Mail servers and
>> clients based on the 2011 command injection discovered in Postfix. We
>> learned that this vulnerability is still very prevalent in current
>> servers and that clients suffer from simliar vulnerabilities. We also
>> found some IMAP specific vulnerabilities.
>>
>> Focussing on client-to-server communication our recommendations are
>> mostly in line with what this working group has already concluded in
>> RFC 8314, which is that implicit TLS on its own port should be
>> preferred over STARTTLS.
>>
>>
>> Our research has not focussed on the server-to-server part. Still I
>> think particularly the buffering / injection vulnerabilities are
>> a concern if one wants to secure s2s communication with mechanisms like
>> MTA-STS. I strongly recommend that users of MTA-STS audit their
>> STARTTLS implementations for buffering bugs.
>> (We found a buffering bug in Yahoo's MX servers, and Yahoo is one of
>> the companies driving MTA-STS. I was unable to report this properly to
>> Yahoo, I reported it through their Hackerone bugbounty program, but the
>> bug triagers were unwilling to try to understand the issue and didn't
>> forward it to Yahoo.)
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Philipp Hancke]

tl;dr: its a mess. What is the deployment state of xep-0368?

Am 11.08.21 um 19:08 schrieb Peter Saint-Andre:

Perhaps of interest here...


 Forwarded Message 
Subject: [Uta] STARTTLS vulnerabilities
Date: Wed, 11 Aug 2021 17:42:40 +0200
From: Hanno Böck 
To: u...@ietf.org

Hi,

I wanted to share some research we have done on vulnerabilities in
STARTTLS implementations:
https://nostarttls.secvuln.info/

We started analyzing STARTTLS implementations in E-Mail servers and
clients based on the 2011 command injection discovered in Postfix. We
learned that this vulnerability is still very prevalent in current
servers and that clients suffer from simliar vulnerabilities. We also
found some IMAP specific vulnerabilities.

Focussing on client-to-server communication our recommendations are
mostly in line with what this working group has already concluded in
RFC 8314, which is that implicit TLS on its own port should be
preferred over STARTTLS.


Our research has not focussed on the server-to-server part. Still I
think particularly the buffering / injection vulnerabilities are
a concern if one wants to secure s2s communication with mechanisms like
MTA-STS. I strongly recommend that users of MTA-STS audit their
STARTTLS implementations for buffering bugs.
(We found a buffering bug in Yahoo's MX servers, and Yahoo is one of
the companies driving MTA-STS. I was unable to report this properly to
Yahoo, I reported it through their Hackerone bugbounty program, but the
bug triagers were unwilling to try to understand the issue and didn't
forward it to Yahoo.)


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___