moparisthebestdwd, so are you saying we should drop ALPN from the spec or just change it into a MAY ?
moparisthebestbecause I'm opposed to the first and fine with the second :)
dwdWhat does ALPN provide that is required for interop?
moparisthebestwhen you want to easily multiplex a port
moparisthebesta big corporation has IPs to spare, maybe, and doesn't need it, for personal servers you do
dwdYes, sure. ALPN is useful for multiplexing ports. Why is it required for interop with direct TLS?
dwdOr to put it another way, why is it specifically useful for direct TLS?
moparisthebestif you remove it from the spec then as a server operator I cannot multiplex easily
dwdWhat does multiplexing have to do with direct TLS?
moparisthebestbecause alpn is built into direct TLS and specifically for multiplexing?
dwdWell, put it this way - right now, nobody much seems to be implementing it, and yet it works fine.
dwdLots of TLS options and extensions might be useful in XMPP. But we don't specify many of them - so what makes ALPN something we want to call people out for non-conformance on?
ZashWhat is the purpose of direct tls?
moparisthebestconversations implements it which is why it works so well
ZashIs it to get through your company firewall?
moparisthebestI don't think you call them non-conformant, but as a server operator I need to be able to run nginx and prosody on the same port, so I need alpn
dwdZash, That's an interesting question, yes.
moparisthebestthe odd client that doesn't send alpn is ok because of SRV records they just fall back
ZashTo me it looks way too much like a premature squeezing of all services into port 443 because ... reasons.
moparisthebesteveryone else is doing it :)
moparisthebestI agree it's crappy we have to run everything over TLS on 443 to connect
moparisthebestbut also not supporting that won't change anything, people just won't use XMPP
dwdI really doubt that. But even if not, it's not clear that ALPN belngs in *this* spec.
petershakes his fist at the evil NATs along with all the other Internet purity people and then returns back to reality
ZashNice things be unattainable.
peterThese days if you want just about anything to work, you have to (sometimes) run it on 443. Same for TURN servers etc.
ZashSo therefore we must embrace it and put everything on 443.
moparisthebestdwd, at least for me the spec is 100% useless without alpn
danielI'm very much for keeping alpn as may
moparisthebestI have to multiplex on 443, and so do lots of other servers
danielOtherwise you can only differentiate on domain basis
Zashmoparisthebest: which leads back to the question of its purpose
danielAnd that's not good enough in some scenarios
moparisthebestit has multiple purposes, my personal purpose is to evade shitty firewalls I encounter
moparisthebestnow someone else might only want it for 0-RTT or something, in which case maybe alpn isn't needed
ZashWhat is the problem statement? Does this require ALPN to solve?
moparisthebestbut, if they need multiplexing, it still is
dwddaniel, There's literally no difference between MAY and removing it entirely.
dwddaniel, I mean, there's absolutely nothing in XMPP which rules ou using any TLS extension at all.
ZashIf you do direct TLS you need SNI, since you can't use the initial stream 'to' attr anymore to select certificates
danieldwd, ok optional then
ZashAssuming name based certificate selection is a thing you do
SamWhitedThe current wording (SHOULD) seems perfectly reasonable to me. If the client sets it and it's not used by the server, no big deal. If the client doesn't set it and the server needs it though, that ends poorly. Just tell clients to set it and be done with it.
dwddaniel, Right, "OPTIONAL" and "MAY" are equivalent terms.
dwdSamWhited, If ALPN's a "SHOULD", I don't think we're in a position to advance it. That's fine if that's what we want.
danielmay would have the benefit that if servers and client end up implementing it the at least use the same value. which would allow us to raise it to a should again if we see that people are using it
moparisthebestI tend to prefer SHOULD, a server operator can feel more comfortable requiring it then
danielMAY over not specifing it at all i mean
ZashMAY is the default? or like, inherited from all the TLS RFCs?
moparisthebestdaniel, I haven't checked but it's faster to just ask, does conversations.im require ALPN ?
SamWhiteddwd: That seems fine to me. Is it just that we need another open source implementation? I think I have one I just never published that should be "production ready", I can probably push it this weekend if that's all that's needed.
jonaswSamWhited, I think server-side support is also lacking
SamWhitedServer side support doesn't really matter, does it? I mean, this is just saying "clients SHOULD set it because it doesn't hurt them at all and then it provides information that servers can use if they want to"
moparisthebesthow do you define 'implementation' ? this spec has quite a few parts to implement
danieli think one of my customers requires it. because we are running an http server on the same ip with the same host name
danielbut conversations.im has the http server on a different ip
moparisthebestyou've got client support, then server c2s support, then server s2s as client and server s2s as server support
danielbut that's not an option everywhere. ipv4 is getting rare
moparisthebestso I count 4, "parts"
moparisthebestwith alpn, I can host an xmpp server with full c2s and s2s support and http or whatever on a single port, with ipv4 getting harder to find that seems useful
danielI don't see the point of hosting s2s on the same port. but c2s + http is a valid argument
moparisthebestso I could see a future host that sells you a dedicated server, but a shared IP and shared port 443, and you get to add your own alpn/sni rules for it
moparisthebestsounds awful but without ipv6 also seems inevitable
jonaswI see a future where we get IPv6
jonaswrocks forward and backward in a corner
Zashs/ipv6/ip/; s/ipv4/legacy ip/
jonaswZash, thank you
dwdSamWhited, Right now it's saying all implementations, so clients, servers, C2S and S2S.
moparisthebestjonasw, I *hope* for that future but, well, I also hope for a future where everything doesn't need shoved through TLS on 443
moparisthebestI'm in the continue to hope, but also do what you can now camp :)
moparisthebestdwd, I don't see a reason to have different rules for s2s and c2s, just overcomplicates things
moparisthebestright now you can send it or not, I say leave it that way
Zashmoparisthebest: I'm not sure that writing a spec for shoving everything on 443 is the best way to make that come true
danielyou don't need to handle alpn on an *incoming* s2s or c2s connection. but that's obvious I guess
jonaswdaniel, don’t you? what if s2s and c2s live on the same port?
moparisthebestagain Zash you really are much more of an optimist than me if you think not supporting that will push people to open other ports rather than to abandon xmpp :)
danieljonasw, fair enough
jonaswmoparisthebest, I don’t think that IPv4 depletion is an argument here
Zashmoparisthebest: optimist? "being draged kicking and screaming into a future I don't want" is what I was going for
jonaswsome corporate firewalls may very well be
jonaswbut I’m not confident that ALPN will help there in the long run
moparisthebestuser of public wifi in coffee shop: "hi owner-of-coffee-shop, my xmpp client can't connect from here, can you unblock port 5222?" owner of coffee shop: "what's xmpp and what's a port?"
jonaswZash, you just put how I feel in words better than I could have done it :-)
Ge0rGmoparisthebest: owner of coffee shop: "stop that dirty talk! I call the police"
danielmoparisthebest, and that assumes the owner is even around…
jonaswmoparisthebest, as I said, c2s makes sense, s2s doesn’t too much
jonaswand this doesn’t have anything to do with IPv4 depletion.
moparisthebestright, more likely you are talking to the 16 year old behind the counter who's never met the owner
moparisthebestjonasw, it's the same code and everything though, it seems more complicated to only support it for c2s and not s2s meh
moparisthebestwhat if you are running your xmpp server on your laptop from a coffee shop???? >:)
jonaswmoparisthebest, the difference is that you don’t need to require support for ALPN from servers in that case. Since they will only ever be listening on a single port which would be a candidate for ALPN (the c2s-port), they don’t need to distinguish protocols.
moparisthebestmaybe your server doesn't, but maybe someone else's server does, what's the argument against it other than "I don't think it needs it" ?
jonaswmoparisthebest, is there an S2S-ALPN-capable XMPP server implementation?
moparisthebestwhich of the 3 server side parts? haha
moparisthebestsslh covers 2 of 3 parts
moparisthebestdwd's metre could have alpn added rather easily I think
jonaswmoparisthebest, sslh isn’t an XMPP server, right?
moparisthebestmetre isn't either I guess
Zashssl/ssh multiplexer thingymajibber
moparisthebestthe combination implements it though, I don't see a difference really
SamWhiteddwd: that still seems perfectly fine to me. I don't see a problem with just setting it even if it's not used, and if there really is a serious problem (option to try and avoid firewalls that inspect that field or something) then that's why it's a SHOULD, they can ignore it if they *really* need too.
moparisthebestthat's basically it, it's super handy to have unless you are trying to evade firewalls, and then you can just not send it, and still be compliant with spec
moparisthebestevade packet inspecting firewalls that don't seem to exactly exist yet, but no doubt will