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
___