XMPP Council - 2017-09-28

  1. ralphm has left
  2. jonasw has left
  3. jonasw has joined
  4. Zash has left
  5. Tobias has joined
  6. Zash has joined
  7. Zash has left
  8. Zash has joined
  9. jere has left
  10. ralphm has left
  11. SamWhited has left
  12. jonasw has joined
  13. jonasw has joined
  14. daniel has left
  15. daniel has joined
  16. daniel has left
  17. daniel has joined
  18. daniel has left
  19. daniel has joined
  20. ralphm has left
  21. daniel has left
  22. daniel has left
  23. Kev has left
  24. daniel has left
  25. ralphm has left
  26. daniel has left
  27. daniel has left
  28. dwd has joined
  29. daniel has left
  30. ralphm has left
  31. daniel has left
  32. daniel has left
  33. daniel has left
  34. daniel has left
  35. daniel has left
  36. daniel has left
  37. ralphm has left
  38. ralphm has left
  39. vanitasvitae has left
  40. vanitasvitae has joined
  41. daniel has left
  42. daniel has joined
  43. ralphm has left
  44. ralphm has left
  45. jayaura has joined
  46. jayaura has left
  47. daniel has left
  48. daniel has joined
  49. vanitasvitae has left
  50. vanitasvitae has joined
  51. jere has joined
  52. Tobias has left
  53. ralphm has joined
  54. daniel has left
  55. daniel has joined
  56. daniel has left
  57. daniel has joined
  58. vanitasvitae has left
  59. vanitasvitae has left
  60. jere has left
  61. jere has joined
  62. vanitasvitae has left
  63. vanitasvitae has left
  64. vanitasvitae has joined
  65. ralphm has left
  66. daniel has left
  67. ralphm has left
  68. daniel has left
  69. daniel has left
  70. daniel has left
  71. daniel has left
  72. ralphm has left
  73. jere has joined
  74. jere has joined
  75. jcbrand has joined
  76. jcbrand has left
  77. ralphm has left
  78. peter has joined
  79. ralphm has left
  80. ralphm has left
  81. moparisthebest has joined
  82. moparisthebest dwd, so are you saying we should drop ALPN from the spec or just change it into a MAY ?
  83. moparisthebest because I'm opposed to the first and fine with the second :)
  84. dwd What does ALPN provide that is required for interop?
  85. moparisthebest when you want to easily multiplex a port
  86. moparisthebest a big corporation has IPs to spare, maybe, and doesn't need it, for personal servers you do
  87. dwd Yes, sure. ALPN is useful for multiplexing ports. Why is it required for interop with direct TLS?
  88. dwd Or to put it another way, why is it specifically useful for direct TLS?
  89. moparisthebest if you remove it from the spec then as a server operator I cannot multiplex easily
  90. dwd What does multiplexing have to do with direct TLS?
  91. moparisthebest because alpn is built into direct TLS and specifically for multiplexing?
  92. dwd Well, put it this way - right now, nobody much seems to be implementing it, and yet it works fine.
  93. dwd Lots 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?
  94. Zash What is the purpose of direct tls?
  95. moparisthebest conversations implements it which is why it works so well
  96. Zash Is it to get through your company firewall?
  97. moparisthebest I 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
  98. dwd Zash, That's an interesting question, yes.
  99. moparisthebest the odd client that doesn't send alpn is ok because of SRV records they just fall back
  100. Zash To me it looks way too much like a premature squeezing of all services into port 443 because ... reasons.
  101. moparisthebest everyone else is doing it :)
  102. moparisthebest I agree it's crappy we have to run everything over TLS on 443 to connect
  103. moparisthebest but also not supporting that won't change anything, people just won't use XMPP
  104. dwd I really doubt that. But even if not, it's not clear that ALPN belngs in *this* spec.
  105. peter shakes his fist at the evil NATs along with all the other Internet purity people and then returns back to reality
  106. Zash Nice things be unattainable.
  107. peter These days if you want just about anything to work, you have to (sometimes) run it on 443. Same for TURN servers etc.
  108. Zash So therefore we must embrace it and put everything on 443.
  109. moparisthebest dwd, at least for me the spec is 100% useless without alpn
  110. daniel I'm very much for keeping alpn as may
  111. moparisthebest I have to multiplex on 443, and so do lots of other servers
  112. daniel Otherwise you can only differentiate on domain basis
  113. Zash moparisthebest: which leads back to the question of its purpose
  114. daniel And that's not good enough in some scenarios
  115. moparisthebest it has multiple purposes, my personal purpose is to evade shitty firewalls I encounter
  116. moparisthebest now someone else might only want it for 0-RTT or something, in which case maybe alpn isn't needed
  117. Zash What is the problem statement? Does this require ALPN to solve?
  118. moparisthebest but, if they need multiplexing, it still is
  119. dwd daniel, There's literally no difference between MAY and removing it entirely.
  120. dwd daniel, I mean, there's absolutely nothing in XMPP which rules ou using any TLS extension at all.
  121. Zash If you do direct TLS you need SNI, since you can't use the initial stream 'to' attr anymore to select certificates
  122. daniel dwd, ok optional then
  123. Zash Assuming name based certificate selection is a thing you do
  124. daniel should
  125. SamWhited The 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.
  126. dwd daniel, Right, "OPTIONAL" and "MAY" are equivalent terms.
  127. dwd SamWhited, 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.
  128. daniel may 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
  129. moparisthebest I tend to prefer SHOULD, a server operator can feel more comfortable requiring it then
  130. daniel MAY over not specifing it at all i mean
  131. Zash MAY is the default? or like, inherited from all the TLS RFCs?
  132. moparisthebest daniel, I haven't checked but it's faster to just ask, does conversations.im require ALPN ?
  133. daniel moparisthebest, no
  134. SamWhited dwd: 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.
  135. jonasw SamWhited, I think server-side support is also lacking
  136. peter has left
  137. SamWhited Server 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"
  138. moparisthebest how do you define 'implementation' ? this spec has quite a few parts to implement
  139. daniel i think one of my customers requires it. because we are running an http server on the same ip with the same host name
  140. daniel but conversations.im has the http server on a different ip
  141. moparisthebest you've got client support, then server c2s support, then server s2s as client and server s2s as server support
  142. daniel but that's not an option everywhere. ipv4 is getting rare
  143. moparisthebest so I count 4, "parts"
  144. moparisthebest with 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
  145. daniel I don't see the point of hosting s2s on the same port. but c2s + http is a valid argument
  146. moparisthebest so 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
  147. moparisthebest sounds awful but without ipv6 also seems inevitable
  148. jonasw I see a future where we get IPv6
  149. jonasw rocks forward and backward in a corner
  150. Zash s/ipv6/ip/; s/ipv4/legacy ip/
  151. peter has joined
  152. jonasw Zash, thank you
  153. dwd SamWhited, Right now it's saying all implementations, so clients, servers, C2S and S2S.
  154. moparisthebest jonasw, I *hope* for that future but, well, I also hope for a future where everything doesn't need shoved through TLS on 443
  155. moparisthebest I'm in the continue to hope, but also do what you can now camp :)
  156. moparisthebest dwd, I don't see a reason to have different rules for s2s and c2s, just overcomplicates things
  157. moparisthebest right now you can send it or not, I say leave it that way
  158. Zash moparisthebest: I'm not sure that writing a spec for shoving everything on 443 is the best way to make that come true
  159. daniel you don't need to handle alpn on an *incoming* s2s or c2s connection. but that's obvious I guess
  160. jonasw daniel, don’t you? what if s2s and c2s live on the same port?
  161. moparisthebest again 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 :)
  162. daniel jonasw, fair enough
  163. jonasw moparisthebest, I don’t think that IPv4 depletion is an argument here
  164. Zash moparisthebest: optimist? "being draged kicking and screaming into a future I don't want" is what I was going for
  165. jonasw some corporate firewalls may very well be
  166. jonasw but I’m not confident that ALPN will help there in the long run
  167. moparisthebest user 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?"
  168. jonasw Zash, you just put how I feel in words better than I could have done it :-)
  169. Ge0rG moparisthebest: owner of coffee shop: "stop that dirty talk! I call the police"
  170. daniel moparisthebest, and that assumes the owner is even around…
  171. jonasw moparisthebest, as I said, c2s makes sense, s2s doesn’t too much
  172. jonasw and this doesn’t have anything to do with IPv4 depletion.
  173. moparisthebest right, more likely you are talking to the 16 year old behind the counter who's never met the owner
  174. daniel has left
  175. moparisthebest jonasw, it's the same code and everything though, it seems more complicated to only support it for c2s and not s2s meh
  176. moparisthebest what if you are running your xmpp server on your laptop from a coffee shop???? >:)
  177. peter has left
  178. jonasw moparisthebest, 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.
  179. moparisthebest maybe 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" ?
  180. jonasw moparisthebest, is there an S2S-ALPN-capable XMPP server implementation?
  181. moparisthebest which of the 3 server side parts? haha
  182. moparisthebest sslh covers 2 of 3 parts
  183. moparisthebest dwd's metre could have alpn added rather easily I think
  184. jonasw moparisthebest, sslh isn’t an XMPP server, right?
  185. moparisthebest metre isn't either I guess
  186. Zash ssl/ssh multiplexer thingymajibber
  187. moparisthebest the combination implements it though, I don't see a difference really
  188. daniel has left
  189. daniel has left
  190. daniel has joined
  191. SamWhited dwd: 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.
  192. moparisthebest that'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
  193. moparisthebest evade packet inspecting firewalls that don't seem to exactly exist yet, but no doubt will
  194. daniel Does http have an official alpn value?
  195. moparisthebest yes
  196. moparisthebest http2 iirc
  197. Zash h2
  198. daniel Does browsers set it?
  199. Zash or http/1.1
  200. moparisthebest https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
  201. moparisthebest yea h2, and yes browsers set it
  202. moparisthebest not sure if they set http/1.1 at all
  203. Tobias has left
  204. jere has left
  205. jere has joined
  206. daniel has left
  207. daniel has joined
  208. ralphm has left
  209. ralphm has left
  210. vanitasvitae has left
  211. ralphm has left
  212. ralphm has left
  213. jcbrand has joined
  214. jcbrand has left
  215. vanitasvitae has left
  216. jere has joined
  217. Zash has left
  218. ralphm has left
  219. daniel has left
  220. moparisthebest has joined
  221. daniel has left
  222. jere has joined
  223. jere has left
  224. jere has joined
  225. ralphm has left
  226. jere has joined
  227. jere has joined
  228. ralphm has left
  229. jere has left
  230. jere has joined
  231. peter has joined
  232. ralphm has joined
  233. daniel has left
  234. daniel has left
  235. daniel has left
  236. daniel has left
  237. peter has left
  238. SamWhited has left