XSF Discussion - 2021-09-01

emus, I can add it to the agenda. What we need is someone to volunteer to be the organization admin (and someone else as a fallback). They will need to submit the application and manage everything if we get accepted. Perhaps you could write to members@ seeking volunteers?

How can I withdraw the message?

huge, https://xmpp.org/extensions/xep-0424.html

thank you, MattJ

MattJ: That is good. If someone offers to support with advises who already did it im happy to volunteer

moparisthebest, How do you feel about asking the Editor to issue a Call For Experience on XEP-0368 and get it to Final?

I did that before and there were comments I said I'd address, I remember that much and then promptly forgetting to do it... ✏

indeed, we did have a CFE on 2020-02-11

the document hasn't been updated since 2019, sooo....

see? my memory is only half bad :P

Yes, mixing definition was the only thing. But equally, ejabberd does XEP-0368 as well as Openfire, so we've the server-side fully covered.

I can give you some text, on list (or in a PR), which i think covers the mixing question if you like.

was that the only update? sure I'm fine with either of those

Specifically, I'm thinking "MAY treat them equally (ie, mix), but MAY prefer direct TLS". I don't want to suggest that people should prefer StartTLS, I don't think that's sane.

it does already have "However, clients MAY choose to prefer one type of connection over the other." but yea it probably makes sense to tweak that as you said

Conversations and xmpp-proxy implements mixing, unsure what other implementations do if any

Metre mixe{s|d}, as does Openfire I think. Not sure what ejabberd does, but Holger knows all.

ejabberd mixes.

Someone (Sam?) was ranting against that behavior the other day, because "why not just always prefer direct TLS".

But I know that there's plenty of clients out there that hit all the _xmpps-client records to exhaustion before touching _xmpp-client, and that seems OK. The reverse seems... odd. I'd rather be in a position in five years to deprecate StartTLS.

fwiw future not-yet-written thing using SRV2 will deprecate XEP-0368, XEP-0156, and how the RFC uses SRV

I guess the question is whether there might be any interop implication with one or the other behavior.

though obviously none will go away... forever?

moparisthebest, are you saying it needs an RFC?

probably

The 6120 successor should just hard-code direct TLS on port 443, end of story :-)

server can't count on mixing or not regardless, because from it's POV it can't tell if a client doesn't implement mixing or is on a network with blocked connectivity

Right.

Holger, or Quic on UDP port 443 yea :)

Indeed, I'm just old-school.

personally I'd like to have XEP-0368 fallback to hard-coded 443 if no records are returned, but I assume that'd be so controversial I didn't want to bring it up

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah

if you don't like this don't look at what xmpp-proxy does ;)

The ALPN stuff is just a bit too new fangled for me.

I'd like to see a hard-coded fallback to xmpp.$domain:443 to cope with the case where SRV lookups fail 😂

one other text I'd like to change/clarify before final is: > If the _xmpps-client (or _xmpps-server) target is set to . (dot), this indicates as per RFC 2782 [3] that the service is not provided for the given domain. In this context, this means that Direct TLS is not supported. In this case, the initiating party SHOULD look up _xmpp-client (or _xmpp-server) records. The initiating party MUST NOT perform A/AAAA fallback as per RFC 6120 [1] (since the service provider has already indicated that the SRV protocol is supported).

this isn't clear that a response like this should be utterly ignored if not signed with DNSSEC (so 99% of the time in practice)

Right now, $domain:5222 needs to be accessible to cope with those.

moparisthebest, I'd note that in Security Considerations, alongside that any records may be spoofed without DNSSEC.

or just take it out entirely since there is no fallback in 368 at all either

They were unless you need them.

*tor users yell "but we still don't have a sane way to look up srv records"*

What's the motivation of the 'MUST NOT perform A' part?

Just to avoid an unnecessary lookup?

dwd, security considerations do note that all DNS responses are subject to modification/spoofing in abscense of DNSSEC, but it's not quite explicit enough for me

Holger, that's just from the SRV spec, to let an admin signal the service isn't supported and you shouldn't even try

but again, should be ignored almost all the time :/

moparisthebest, Yeah, I'd note that '.' is particularly vulnerable and leave it at thta.

I see no interop problem with trying.

So personally I'd omit that.

The SRV spec is wrong :-)

I think it's fine in a world where DNS is trustworthy, unfortunately...

In my book, MUST clauses exist to avoid interop problems.

Therefore, a clause that says 'MUST avoid $x' just because $x seems unnecessary to the spec author confuses me while reading a spec.

But whatever.

You are right imho

I look at this from the perspective of the user, they want to connect, that means you should do everything possible to connect, that means all the methods, all the fallbacks etc etc

oh, and now I remember another change, though thinking on it maybe it'd be more appropriate in another "best practices" type xep

but roughly, when to abort connecting vs when to move to next srv record / connection method (tl;dr almost never abort connecting)