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