Re: [Standards] Deprecating Dialback

[Sam Whited]

On Fri, Dec 4, 2020, at 20:10, Philipp Hancke wrote:
> That has less features than 220, in particular you can't add new
> domains on *either* side, no? (ofc stream headers suck a bit for this)

Yes, it will definitely need more work. This seems like a useful
requirement to add if it gets accepted. I also had some ideas for how we
could do auth without having to dial another connection at all that
might be worth exploring.

> In general I see little value in reinventing the syntax -- it would
> take another decade or so to get adoption.

I'm not against reusing the old syntax, but since this doesn't actually
require dialback anymore I thought that would just lead to confusion.

> And please, do NOT BRING BACK the wrong notion of subdomain from RFC
> 3920. Discovery is a problem for multiplexing but one has to use DNS,
> not make wrong assumptions about it :-)

I'm not sure what this means, are you worried about using the term
subdomain in the examples? What is the specific confusion this would
cause? I think we always use DNS and don't rely on splitting domains or
anything improper, so slightly imprecise language that's in common use
seems fine to me but I'll try and clean it up a bit.

—Sam

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

Re: [Standards] Deprecating Dialback

[Philipp Hancke]

Am 03.12.20 um 15:13 schrieb Sam Whited:

I lied, I got interested and got started on it last night after work /
this morning.

https://github.com/xsf/xeps/pull/1017


That has less features than 220, in particular you can't add new domains 
on *either* side, no? (ofc stream headers suck a bit for this)
In general I see little value in reinventing the syntax -- it would take 
another decade or so to get adoption.


And please, do NOT BRING BACK the wrong notion of subdomain from RFC 
3920. Discovery is a problem for multiplexing but one has to use DNS, 
not make wrong assumptions about it :-)



—Sam

On Wed, Dec 2, 2020, at 16:20, Sam Whited wrote:

Either way I can start writing the new multiplexing proposal this
weekend unless someone else who actually has experience with this sort
of thing wants to do it.

___
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] Deprecating Dialback

[Sam Whited]

I lied, I got interested and got started on it last night after work /
this morning.

https://github.com/xsf/xeps/pull/1017

—Sam

On Wed, Dec 2, 2020, at 16:20, Sam Whited wrote:
> Either way I can start writing the new multiplexing proposal this
> weekend unless someone else who actually has experience with this sort
> of thing wants to do it.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Deprecating Dialback

[Peter Saint-Andre]

On 12/2/20 8:36 AM, Dave Cridland wrote:
> 
> 
> On Wed, 2 Dec 2020 at 14:09, Sam Whited  > wrote:
> 
> I've been having a think about dialback recently and came to the
> conclusion that it would be nice to begin discouraging its use on the
> public network. This would raise the overall quality of authentication
> on the network by beginning to phase out insecure DNS-based
> authentication as well as simplify the implementation of certificate
> based auth by allowing us to only rely on SASL EXTERNAL without having
> to also implement "dialback without dialing back". Towards that end, I
> would like to propose deprecating XEP-0220 and XEP-0185.
> 
> 
> There are two things here:
> 
> a) Phasing out DNS-based authentication - ie, db:verify.
> 
> b) Phasing out the use of the db:result syntax.
> 
> The DNS side, (a), is easy to suggest deprecation. It's fundamentally
> weak, and it really only served a useful purpose before Let's Encrypt
> came along. 

Well, in 1999/2000 it was hard (for some definition) to get certs at
all. Dialback was a bootstrapping mechanism for server deployment (along
the lines of IBR for c2s) and I agree deserves to be deprecated now.

> But we don't have a solution without  for "piggybacking", as
> described in
> XEP-0220: https://xmpp.org/extensions/xep-0220.html#multiplex
> 
> 
> I think multiplexing has value in a number of cases, particularly where
> S2S bandwidth and/or latency is poor.
> 
> Proposal:
> 
> 1) Pull multiplexing out into its own XEP.
> 
> 2) Give it a new syntax (and a stream feature) that doesn't imply
> XEP-0220 anymore. Reference the old syntax as a historical case.

Will that actually speed things up? Multiplexing would be a new protocol
for server developers to implement and for server operators to deploy.

Just wondering. :-)

Peter

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

Re: [Standards] Deprecating Dialback

[Sam Whited]

This sounds reasonable to me. I wonder if we can go ahead and begin the
deprecation process though so we don't have to wait for the new
multiplexing proposal to go all the way through the process?

Either way I can start writing the new multiplexing proposal this
weekend unless someone else who actually has experience with this sort
of thing wants to do it.

—Sam

On Wed, Dec 2, 2020, at 15:36, Dave Cridland wrote:
> Proposal:
>
> 1) Pull multiplexing out into its own XEP.
>
> 2) Give it a new syntax (and a stream feature) that doesn't imply XEP-
>0220 anymore. Reference the old syntax as a historical case.
>
> With that in place, I think we can deprecate XEP-0220
>
> Note that I'm not suggesting we immediately rip the support out of
> every codebase, just that we're suggesting it's no longer desirable or
> necessary for servers to implement.
>
> How does that sound?

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

Re: [Standards] Deprecating Dialback

[Dave Cridland]

On Wed, 2 Dec 2020 at 14:09, Sam Whited  wrote:

> I've been having a think about dialback recently and came to the
> conclusion that it would be nice to begin discouraging its use on the
> public network. This would raise the overall quality of authentication
> on the network by beginning to phase out insecure DNS-based
> authentication as well as simplify the implementation of certificate
> based auth by allowing us to only rely on SASL EXTERNAL without having
> to also implement "dialback without dialing back". Towards that end, I
> would like to propose deprecating XEP-0220 and XEP-0185.


There are two things here:

a) Phasing out DNS-based authentication - ie, db:verify.

b) Phasing out the use of the db:result syntax.

The DNS side, (a), is easy to suggest deprecation. It's fundamentally weak,
and it really only served a useful purpose before Let's Encrypt came along.
So I'm perfectly happy to see this deprecated - even though XEP-0344
suggests that DNSSEC and TLS provide pretty broad security even in this
case.

XEP-0288 refers to dialback, but broadly is unaffected by deprecation of
(a) and (b).

But we don't have a solution without  for "piggybacking", as
described in XEP-0220: https://xmpp.org/extensions/xep-0220.html#multiplex

I think multiplexing has value in a number of cases, particularly where S2S
bandwidth and/or latency is poor.

Proposal:

1) Pull multiplexing out into its own XEP.

2) Give it a new syntax (and a stream feature) that doesn't imply XEP-0220
anymore. Reference the old syntax as a historical case.

With that in place, I think we can deprecate XEP-0220

Note that I'm not suggesting we immediately rip the support out of every
codebase, just that we're suggesting it's no longer desirable or necessary
for servers to implement.

How does that sound?

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

[Standards] Deprecating Dialback

[Sam Whited]

Hi all,

I've been having a think about dialback recently and came to the
conclusion that it would be nice to begin discouraging its use on the
public network. This would raise the overall quality of authentication
on the network by beginning to phase out insecure DNS-based
authentication as well as simplify the implementation of certificate
based auth by allowing us to only rely on SASL EXTERNAL without having
to also implement "dialback without dialing back". Towards that end, I
would like to propose deprecating XEP-0220 and XEP-0185.

To decide whether this was a good idea or not, I tried to answer the
following questions (this was actually to decide if I wanted to
implement it or not, but I think they apply here too):

- How widespread is dialback use on the public Jabber network today?

- Are there any services that are considered "important" that only
  support dialback (and what do we mean by "important")?

To answer the first I asked in the chat for stats from large public
servers. The only respondent was Jabber.FR (thanks Link Mauve) where
only 4% of 2034 connections were using dialback. I would be curious if
this is representative of the broader network if any other medium-to-
large servers want to chime in.

For the second I did not end up coming up with a definition of
"important", but someone suggested that jabber.org might be considered
important and that they thought it had trouble with SASL EXTERNAL. I did
not verify this since I don't have a domain setup to do s2s properly
right now. If anyone can verify this (and if it's true can verify
whether it can be upgraded to support SASL EXTERNAL) please chime in.

Thanks for reading,
Sam

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