lovetoxwhy does 0368 say we should treat xmpps and xmpp as the same record and mix it?
lovetoxthese connection methods have different security properties
lovetoxwhy is xmpps not prefered over xmpp
Zashiirc so that the admin can choose what to prefer. Weird and complicated tho and I don't think eg Conversations does that, it just does _xmpps first, then _xmpp
ZashI don't believe there's any differences in security properties tho, it's exactly equivalent to starttls. you do save a few roundtrips tho.
lovetoxZash no DIRECT TLS is not equivalent to START TLS
lovetoxwith the later, metadata are transfered unencrypted
lovetoxand yes we save roundtrips so another reason why to prefer xmpps
ZashBoth expose the name of the service and the fact that you're speaking XMPP
ZashBecasue SNI, ALPN and the service certificate are all sent unencrypted.
lovetoxbecause of unencrypted SNI
lovetoxstill, i dont see a reason why a server admin would tell a client what it should prefer
lovetoxif its the same connection method, like 2 ports for start tls i see why a client would not care, and an admin should decide
lovetoxbut not if one connection method has simply other properties, like fewer roundtrips
lovetoxof course a mobile client has to ignore the preference of the server admin here
lovetoxis it possible to setup multiple xmpps records?
lovetoxor can one only set one SRV record with the same name
jonas’the whole point of SRV is that you can setup multiple records with different weights and priorities.
lovetoxso then the admin should setup more than one xmpps record if he wants to load balance between hosts or ports
lovetoxand not prefer one over the other connection method
lovetoxi also tend to ignoring this specific rule of the XEP
jonas’you’re not the first
jonas’and nowadays I’m not sure why this rule was a good idea in the first place
lovetoxdirect tls is in every superior and i see no reason why i should not prefer it
jonas’I’m pretty sure I argued in favour of it in the past, but I can’t figure out why
jonas’well, it’s not superior if you cannot do ALPN but the service requires it
jonas’then weird things may happen
lovetoxyeah of course if i cant tecnically do it, then i should not do it
jonas’ALPN is not a MUST tho
jonas’lovetox, another reason may be that only some of the servers of the deployment support xmpps
ZashI'm still not entirely happy about what amounts to an optimization of a security thing.
jonas’ah, I recall
jonas’ah, I recall what the reason was
lovetoxwhy that, if it does not work without setting it if the server uses alpn
jonas’ah, I recall what the reason was, but I don’t think it really makes sense given true network behaviour
jonas’lovetox, because it depends on the deployment whether ALPN is required or not :)
lovetoxyeah but if the client cant figure that out ...
lovetoxok so this is just so a server can say i use 0368, but i dont use ALPN
lovetoxso i dont care if clients set it or not
lovetoxbut i still can say im 0368 compliant
lovetoxhm the should is on client side
lovetoxnot on server, so the client does not have to set it, but it fails then for some servers, and there is no way to discover if alpn is needed
Zash3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
lovetoxin a federated world for me this means, either as a client i set alpn the whole time or i dont use xmpps at all
lovetoxbecause weird stuff happens
jonas’lovetox, probably true
lovetoxthis not mixing xmpps and xmpp would make my impl a lot smaller
lovetoxso i can assume this is not mixing xmpps and xmpp is not a very bad thing for server owners, and i fuck up whatever they tried to do
lovetoxwhat would be reasons a server admin says i over direct tls but i want everyone to try lasz
lovetoxwhat would be reasons a server admin says i over direct tls but i want everyone to try last
lovetoxwhat would be reasons a server admin says i offer direct tls but i want everyone to try last
jonas’so, what I was thinking about earlier
jonas’if you have a multi-tiered HA deployment, where clients should not connect to the second tier if the first tier is online
jonas’but not all servers of the first tier support XMPPS
jonas’but only the second tier supports XMPPS
jonas’then the xmpp-server records would have a prio of 10 for the first tier and prio of 20 for the second tier
jonas’the xmpps-server records obviously only exist for prio 20
jonas’when mixing them, the correct thing would happen. when looking at them separately, the wrong thing happens.
jonas’the rationale for mixing is that the records (xmpps and xmpp) describe the same logical service but a different way to connect to it. SRV is there to describe where to find a service
jonas’so this is kind of an awkward thing to have in SRV in general
jonas’when not mixing, this setup would force the operator to only publish xmpp-client records (because they cannot rely on xmpps-client to behave correctly)
jonas’however, and this is what I meant earlier by "I don’t think it really makes sense given true network behaviour", an operator cannot rely on a client not connecting to prio 20 before prio 10, because local network problems may cause all connections to the prio 10 hosts to fail
jonas’so the HA cluster needs to be aware of this problem and handle it in some way, probably with a <redirect/>
ZashBut would a generic SRV resolver thing support this mixing thing?
lovetoxso as a xmpp client do i have to support START TLS?
jonas’Zash, probably not, which is what I meant by "so this is kind of an awkward thing to have in SRV in general"
lovetoxwhat if iam a client that only implements direct tls
jonas’lovetox, that’s not compliant.
ZashAltho, doesn't the email SRV RFC do this too?
Zash... but for imap, imaps, pop3 and pop3s
jonas’lovetox, STARTTLS is the default way if no SRV records are found at all, which is a valid XMPP deployment
jonas’Zash, nobody does email with SRV tho
jonas’lovetox, not to mention that direct TLS is still not possible for a virtualised (i.e. with multiple virtual hosts) prosody server
jonas’(due to lack of SNI)
jonas’also I don’t believe in direct TLS and won’t offer it due to the extra work this is ;)
moparisthebestlovetox: mixing was a must but is now a should
moparisthebestZash: conversations does mix, I wrote that patch before the xep even
moparisthebestThe argument for changing it was basically "maybe I just want to prefer direct TLS" which makes sense
moparisthebestAlso Zash the service certificate is encrypted with TLS 1.3 right?
moparisthebestAnd now with ESNI... :)
flowI think I potentially once thought that mixing would make sense, but I tend to not mix these days
moparisthebestI would agree with that flow
flowMostly because SRV RRs are meant to distribute load over cluster nodes (and backup closter nodes)
flowbut that would potentially mean that we do not need xmpps SRV RR at all, but just a flag that says "on every host that offers xmpp, there is also xmpps available on port X"
Zashmoparisthebest, false, SNI, ALPN and cert are still unencrypted in TLS 1.3
ZashHaven't seen ESNI anywhere yet
flowAnyway I think we need some more implementation and deployment experience. Waiting for other use cases that we do not know yet about. But right now I am probably going to not mix in my implementation
jonas’flow, you do realize that it’s both widely deployed and implemented?
jonas’Conversations does it, not sure about yaxim, servers don’t need to do a lot either way, the Conversations compliance checker does test for it, so a lot of deployments actually have those records set.
jonas’aioxmpp supports it, some other libraries do so, too
jonas’though not all support mixing and not-mixing
moparisthebestZash: cloudflare has fully deployed ESNI I think, also curl supports it
> Although TLS 1.3 [RFC8446] encrypts most of the handshake, including the server certificate,