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
___

[Standards] XEP-0372 references pointing to different elements in same stanza

[JC Brand]

Hi everyone

In XEP-0372, when references are used for "mentions", there is an 
implicit assumption that the referenced text is in the  tag.


There are however other elements where mentions could also occur, such 
as ,  and , and some stanzas could have multiple 
possible elements whose text might be referenced.


XEP-0372 provides an "anchor" attribute for the  tag, which 
can be used to refer to other addressable entities, to handle the case 
where the reference points to something in another stanza.


I think this "anchor" attribute can also be used to disambiguate the 
references in a stanza that has multiple text-containing elements. In 
this case, instead of letting the anchor point to an XMPP URI, it would 
only point to a fragment, meaning that the fragment is inside the same 
stanza.


In HTML the fragment of a URI points to an element with the same id 
attribute value as the fragment itself, but apparently this isn't a 
general requirement for URIs. In this case, for simplicity, I would 
however stick to that convention.


So, if you have a stanza with for example, both "subject" and "body" 
tags, we can have references for both, and use the "anchor" attribute as 
follows (I hope this comes out formatted properly once sent):



    Attention Bart Simpson
    Please hand in your homework before the end of the 
day

    


I think this is an elegant solution that uses the existing mechanics, 
and the only further requirement would be to clarify in the XEP that the 
anchor attribute can be used in this way.


I'd be happy to hear your thoughts and feedback.

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