-
lovetox
why does 0368 say we should treat xmpps and xmpp as the same record and mix it?
-
lovetox
these connection methods have different security properties
-
lovetox
why is xmpps not prefered over xmpp
-
Zash
iirc 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
-
Zash
I don't believe there's any differences in security properties tho, it's exactly equivalent to starttls. you do save a few roundtrips tho.
-
lovetox
Zash no DIRECT TLS is not equivalent to START TLS
-
lovetox
with the later, metadata are transfered unencrypted
-
lovetox
and yes we save roundtrips so another reason why to prefer xmpps
-
Zash
Both expose the name of the service and the fact that you're speaking XMPP
-
Zash
Becasue SNI, ALPN and the service certificate are all sent unencrypted.
-
lovetox
because of unencrypted SNI
-
lovetox
or what
-
lovetox
still, i dont see a reason why a server admin would tell a client what it should prefer
-
lovetox
if its the same connection method, like 2 ports for start tls i see why a client would not care, and an admin should decide
-
lovetox
but not if one connection method has simply other properties, like fewer roundtrips
-
lovetox
of course a mobile client has to ignore the preference of the server admin here
-
lovetox
is it possible to setup multiple xmpps records?
-
lovetox
or 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.
-
lovetox
so then the admin should setup more than one xmpps record if he wants to load balance between hosts or ports
-
lovetox
and not prefer one over the other connection method
-
lovetox
i 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
-
lovetox
direct 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
-
lovetox
yeah 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
-
Zash
I'm still not entirely happy about what amounts to an optimization of a security thing.
-
jonas’
ah, I recall✎ - jonas’
-
lovetox
why 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 :)
-
lovetox
yeah but if the client cant figure that out ...
-
lovetox
ok so this is just so a server can say i use 0368, but i dont use ALPN
-
lovetox
so i dont care if clients set it or not
-
lovetox
but i still can say im 0368 compliant
-
lovetox
hm the should is on client side
-
lovetox
not 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
-
Zash
3. 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.
-
lovetox
in a federated world for me this means, either as a client i set alpn the whole time or i dont use xmpps at all
-
lovetox
because weird stuff happens
-
jonas’
lovetox, probably true
-
lovetox
this not mixing xmpps and xmpp would make my impl a lot smaller
-
lovetox
so 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
-
lovetox
what would be reasons a server admin says i over direct tls but i want everyone to try lasz✎ -
lovetox
what would be reasons a server admin says i over direct tls but i want everyone to try last✎ ✏ -
lovetox
what 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/>
-
Zash
But would a generic SRV resolver thing support this mixing thing?
-
lovetox
so 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"
-
jonas’
lovetox, yes.
-
lovetox
what if iam a client that only implements direct tls
-
lovetox
..
-
jonas’
lovetox, that’s not compliant.
-
Zash
Altho, 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)
-
Zash
(0.12 tho)
-
jonas’
also I don’t believe in direct TLS and won’t offer it due to the extra work this is ;)
-
moparisthebest
lovetox: mixing was a must but is now a should
-
moparisthebest
Zash: conversations does mix, I wrote that patch before the xep even
-
moparisthebest
The argument for changing it was basically "maybe I just want to prefer direct TLS" which makes sense
-
moparisthebest
Also Zash the service certificate is encrypted with TLS 1.3 right?
-
moparisthebest
And now with ESNI... :)
-
flow
I think I potentially once thought that mixing would make sense, but I tend to not mix these days
-
moparisthebest
I would agree with that flow
-
flow
Mostly because SRV RRs are meant to distribute load over cluster nodes (and backup closter nodes)
-
flow
but 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"
-
Zash
moparisthebest, false, SNI, ALPN and cert are still unencrypted in TLS 1.3
-
Zash
Haven't seen ESNI anywhere yet
-
flow
Anyway 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
-
moparisthebest
Zash: cloudflare has fully deployed ESNI I think, also curl supports it
-
moparisthebest
Zash: > Although TLS 1.3 [RFC8446] encrypts most of the handshake, including the server certificate,
-
moparisthebest
I knew I had read that somewhere
-
moparisthebest
From https://tools.ietf.org/html/draft-ietf-tls-esni-05
-
moparisthebest
So with ESNI and TLS 1.3, alpn is the only thing still plaintext
-
Zash
Interesting, seems they do encrypt before sending the cert. OpenSSL of course doesn't.
-
jonas’
isn’t ESNI that thing which isn’t going to work with XMPP?
-
jonas’
something about how the DNS records assume that the world is HTTP
-
Zash
DNS records?
-
jonas’
ah, another/earlier draft had the public keys for the ESNI encryption in DNS
-
moparisthebest
I think it will, just requires DNS records with a key to encrypt the SNI
-
jonas’
moparisthebest, last time I checked, those records would not allow to publish different ESNI keys for different services on the same domain
-
jonas’
which is a no-go if your XMPP service and HTTP service are in separate trust domains
-
jonas’
the document has become more convoluted since, the details appearing to be in https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 which is too dense for me right now
-
moparisthebest
Yea I haven't been following closely either
-
moparisthebest
Also I use the same certificate for my xmpp and https server meh
-
Zash
jonas’, fun thing with openssl, you can't have different certs based on ALPN afaik, only based on SNI.
-
Zash
I don't. Don't even have them on the same server.
-
moparisthebest
Well wait still one esni key would be fine
-
moparisthebest
You wouldn't need to use the same cert on multiple servers, just the same esni key
-
moparisthebest
So in worst case compromise, an attacker could decrypt the esni only of your other servers?
-
jonas’
moparisthebest, that still requires to keep them in sync on different things, possibly restarting services etc. whenever you roll the key over
-
jonas’
that’s awful
-
jonas’
and there’s no good reason for this requirement except ignorance for non-HTTP things
-
jonas’
(if it is still true, that is)
-
moparisthebest
Well it is simpler from an implementation point of view
-
moparisthebest
I understand your point though
-
Zash
DANE allows putting the full public key in DNS. Why not do that and start with a key agreement?
-
Zash
Don't even need a certificate, https://tools.ietf.org/html/rfc7250
-
jonas’
Zash, interesting
-
moparisthebest
Oh yes I love DANE and have had it set up for years
-
moparisthebest
Shame only postfix seems to support it :'(
-
moparisthebest
Used to be a Firefox plugin that did but it broke
-
moparisthebest
Oh no I just read that esni RFC and it depends on "srv2"
-
moparisthebest
Which means it'll require whole new mechanism instead of xep368 :'(
-
moparisthebest
Good news is it's an esni key per domain/port combo though Zash / jonas’
-
moparisthebest
Srv2: https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
-
Zash
Ugh
-
moparisthebest
They called it httpsvc lol
-
Zash
Hrrrrr