XSF logo jdev - 2020-01-11


  1. strar has left
  2. strar has joined
  3. sonny has left
  4. asterix has left
  5. sonny has joined
  6. sonny has left
  7. sonny has joined
  8. Zash has left
  9. sonny has left
  10. Zash has joined
  11. sonny has joined
  12. aj has joined
  13. sonny has left
  14. serge90 has left
  15. sonny has joined
  16. Lance has left
  17. serge90 has joined
  18. sonny has left
  19. sonny has joined
  20. debacle has left
  21. Lance has joined
  22. sonny has left
  23. Lance has left
  24. sonny has joined
  25. sonny has left
  26. wurstsalat has left
  27. Bartek has joined
  28. Bartek has left
  29. Lance has joined
  30. Lance has left
  31. paul has joined
  32. Lance has joined
  33. Lance has left
  34. asterix has joined
  35. asterix has left
  36. asterix has joined
  37. asterix has left
  38. asterix has joined
  39. paul has left
  40. paul has joined
  41. asterix has left
  42. asterix has joined
  43. lovetox has joined
  44. asterix has left
  45. asterix has joined
  46. skyfar has left
  47. pulkomandy has left
  48. pulkomandy has joined
  49. lovetox has left
  50. wurstsalat has joined
  51. skyfar has joined
  52. asterix has left
  53. asterix has joined
  54. lovetox has joined
  55. debacle has joined
  56. Lance has joined
  57. pulkomandy has left
  58. pulkomandy has joined
  59. Lance has left
  60. Lance has joined
  61. Lance has left
  62. pulkomandy has left
  63. larma has left
  64. pulkomandy has joined
  65. larma has joined
  66. asterix has left
  67. asterix has joined
  68. pulkomandy has left
  69. pulkomandy has joined
  70. asterix has left
  71. asterix has joined
  72. lovetox why does 0368 say we should treat xmpps and xmpp as the same record and mix it?
  73. lovetox these connection methods have different security properties
  74. lovetox why is xmpps not prefered over xmpp
  75. 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
  76. 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.
  77. sonny has joined
  78. pulkomandy has left
  79. sonny has left
  80. sonny has joined
  81. sonny has left
  82. sonny has joined
  83. asterix has left
  84. asterix has joined
  85. pulkomandy has joined
  86. lovetox has left
  87. sonny has left
  88. sonny has joined
  89. lovetox has joined
  90. lovetox Zash no DIRECT TLS is not equivalent to START TLS
  91. lovetox with the later, metadata are transfered unencrypted
  92. lovetox and yes we save roundtrips so another reason why to prefer xmpps
  93. Zash Both expose the name of the service and the fact that you're speaking XMPP
  94. Zash Becasue SNI, ALPN and the service certificate are all sent unencrypted.
  95. lovetox because of unencrypted SNI
  96. lovetox or what
  97. lovetox still, i dont see a reason why a server admin would tell a client what it should prefer
  98. 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
  99. lovetox but not if one connection method has simply other properties, like fewer roundtrips
  100. lovetox of course a mobile client has to ignore the preference of the server admin here
  101. lovetox is it possible to setup multiple xmpps records?
  102. lovetox or can one only set one SRV record with the same name
  103. jonas’ the whole point of SRV is that you can setup multiple records with different weights and priorities.
  104. asterix has left
  105. asterix has joined
  106. lovetox so then the admin should setup more than one xmpps record if he wants to load balance between hosts or ports
  107. lovetox and not prefer one over the other connection method
  108. sonny has left
  109. lovetox i also tend to ignoring this specific rule of the XEP
  110. jonas’ you’re not the first
  111. jonas’ and nowadays I’m not sure why this rule was a good idea in the first place
  112. lovetox direct tls is in every superior and i see no reason why i should not prefer it
  113. jonas’ I’m pretty sure I argued in favour of it in the past, but I can’t figure out why
  114. jonas’ well, it’s not superior if you cannot do ALPN but the service requires it
  115. jonas’ then weird things may happen
  116. lovetox yeah of course if i cant tecnically do it, then i should not do it
  117. jonas’ ALPN is not a MUST tho
  118. jonas’ lovetox, another reason may be that only some of the servers of the deployment support xmpps
  119. Zash I'm still not entirely happy about what amounts to an optimization of a security thing.
  120. jonas’ ah, I recall
  121. jonas’ ah, I recall what the reason was
  122. lovetox why that, if it does not work without setting it if the server uses alpn
  123. jonas’ ah, I recall what the reason was, but I don’t think it really makes sense given true network behaviour
  124. jonas’ lovetox, because it depends on the deployment whether ALPN is required or not :)
  125. lovetox yeah but if the client cant figure that out ...
  126. lovetox ok so this is just so a server can say i use 0368, but i dont use ALPN
  127. lovetox so i dont care if clients set it or not
  128. lovetox but i still can say im 0368 compliant
  129. lovetox hm the should is on client side
  130. 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
  131. 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.
  132. 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
  133. lovetox because weird stuff happens
  134. jonas’ lovetox, probably true
  135. sonny has joined
  136. goffi has joined
  137. tsk has left
  138. tsk has joined
  139. pulkomandy has left
  140. lovetox this not mixing xmpps and xmpp would make my impl a lot smaller
  141. pulkomandy has joined
  142. 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
  143. lovetox what would be reasons a server admin says i over direct tls but i want everyone to try lasz
  144. lovetox what would be reasons a server admin says i over direct tls but i want everyone to try last
  145. lovetox what would be reasons a server admin says i offer direct tls but i want everyone to try last
  146. jonas’ so, what I was thinking about earlier
  147. jonas’ if you have a multi-tiered HA deployment, where clients should not connect to the second tier if the first tier is online
  148. jonas’ but not all servers of the first tier support XMPPS
  149. Lance has joined
  150. jonas’ but only the second tier supports XMPPS
  151. jonas’ then the xmpp-server records would have a prio of 10 for the first tier and prio of 20 for the second tier
  152. jonas’ the xmpps-server records obviously only exist for prio 20
  153. jonas’ when mixing them, the correct thing would happen. when looking at them separately, the wrong thing happens.
  154. 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
  155. jonas’ so this is kind of an awkward thing to have in SRV in general
  156. 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)
  157. 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
  158. jonas’ so the HA cluster needs to be aware of this problem and handle it in some way, probably with a <redirect/>
  159. Zash But would a generic SRV resolver thing support this mixing thing?
  160. lovetox so as a xmpp client do i have to support START TLS?
  161. jonas’ Zash, probably not, which is what I meant by "so this is kind of an awkward thing to have in SRV in general"
  162. jonas’ lovetox, yes.
  163. lovetox what if iam a client that only implements direct tls
  164. lovetox ..
  165. jonas’ lovetox, that’s not compliant.
  166. Zash Altho, doesn't the email SRV RFC do this too?
  167. Zash ... but for imap, imaps, pop3 and pop3s
  168. jonas’ lovetox, STARTTLS is the default way if no SRV records are found at all, which is a valid XMPP deployment
  169. jonas’ Zash, nobody does email with SRV tho
  170. lovetox has left
  171. jonas’ lovetox, not to mention that direct TLS is still not possible for a virtualised (i.e. with multiple virtual hosts) prosody server
  172. jonas’ (due to lack of SNI)
  173. Zash (0.12 tho)
  174. jonas’ also I don’t believe in direct TLS and won’t offer it due to the extra work this is ;)
  175. aj has left
  176. Lance has left
  177. pulkomandy has left
  178. pulkomandy has joined
  179. sonny has left
  180. tao has joined
  181. tao has left
  182. Tao has joined
  183. sonny has joined
  184. Tao has left
  185. paul has left
  186. paul has joined
  187. asterix has left
  188. asterix has joined
  189. debacle has left
  190. kikuchiyo has left
  191. kikuchiyo has joined
  192. Tao has joined
  193. lovetox has joined
  194. pulkomandy has left
  195. Tao has left
  196. pulkomandy has joined
  197. sonny has left
  198. sonny has joined
  199. pulkomandy has left
  200. Lance has joined
  201. Lance has left
  202. lovetox has left
  203. kikuchiyo has left
  204. kikuchiyo has joined
  205. kikuchiyo has left
  206. lovetox has joined
  207. sonny has left
  208. sonny has joined
  209. kikuchiyo has joined
  210. kikuchiyo has left
  211. kikuchiyo has joined
  212. kikuchiyo has left
  213. kikuchiyo has joined
  214. rion has left
  215. rion has joined
  216. lovetox has left
  217. lovetox has joined
  218. debacle has joined
  219. serge90 has left
  220. rion has left
  221. serge90 has joined
  222. lovetox has left
  223. lovetox has joined
  224. moparisthebest lovetox: mixing was a must but is now a should
  225. moparisthebest Zash: conversations does mix, I wrote that patch before the xep even
  226. moparisthebest The argument for changing it was basically "maybe I just want to prefer direct TLS" which makes sense
  227. moparisthebest Also Zash the service certificate is encrypted with TLS 1.3 right?
  228. moparisthebest And now with ESNI... :)
  229. flow I think I potentially once thought that mixing would make sense, but I tend to not mix these days
  230. moparisthebest I would agree with that flow
  231. flow Mostly because SRV RRs are meant to distribute load over cluster nodes (and backup closter nodes)
  232. 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"
  233. Zash moparisthebest, false, SNI, ALPN and cert are still unencrypted in TLS 1.3
  234. Zash Haven't seen ESNI anywhere yet
  235. 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
  236. jonas’ flow, you do realize that it’s both widely deployed and implemented?
  237. 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.
  238. jonas’ aioxmpp supports it, some other libraries do so, too
  239. jonas’ though not all support mixing and not-mixing
  240. moparisthebest Zash: cloudflare has fully deployed ESNI I think, also curl supports it
  241. moparisthebest Zash: > Although TLS 1.3 [RFC8446] encrypts most of the handshake, including the server certificate,
  242. moparisthebest I knew I had read that somewhere
  243. moparisthebest From https://tools.ietf.org/html/draft-ietf-tls-esni-05
  244. moparisthebest So with ESNI and TLS 1.3, alpn is the only thing still plaintext
  245. Zash Interesting, seems they do encrypt before sending the cert. OpenSSL of course doesn't.
  246. jonas’ isn’t ESNI that thing which isn’t going to work with XMPP?
  247. jonas’ something about how the DNS records assume that the world is HTTP
  248. Zash DNS records?
  249. jonas’ ah, another/earlier draft had the public keys for the ESNI encryption in DNS
  250. moparisthebest I think it will, just requires DNS records with a key to encrypt the SNI
  251. jonas’ moparisthebest, last time I checked, those records would not allow to publish different ESNI keys for different services on the same domain
  252. jonas’ which is a no-go if your XMPP service and HTTP service are in separate trust domains
  253. 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
  254. moparisthebest Yea I haven't been following closely either
  255. moparisthebest Also I use the same certificate for my xmpp and https server meh
  256. Zash jonas’, fun thing with openssl, you can't have different certs based on ALPN afaik, only based on SNI.
  257. Zash I don't. Don't even have them on the same server.
  258. moparisthebest Well wait still one esni key would be fine
  259. moparisthebest You wouldn't need to use the same cert on multiple servers, just the same esni key
  260. moparisthebest So in worst case compromise, an attacker could decrypt the esni only of your other servers?
  261. jonas’ moparisthebest, that still requires to keep them in sync on different things, possibly restarting services etc. whenever you roll the key over
  262. jonas’ that’s awful
  263. jonas’ and there’s no good reason for this requirement except ignorance for non-HTTP things
  264. jonas’ (if it is still true, that is)
  265. moparisthebest Well it is simpler from an implementation point of view
  266. moparisthebest I understand your point though
  267. Zash DANE allows putting the full public key in DNS. Why not do that and start with a key agreement?
  268. Zash Don't even need a certificate, https://tools.ietf.org/html/rfc7250
  269. lovetox has left
  270. jonas’ Zash, interesting
  271. moparisthebest Oh yes I love DANE and have had it set up for years
  272. moparisthebest Shame only postfix seems to support it :'(
  273. moparisthebest Used to be a Firefox plugin that did but it broke
  274. pulkomandy has joined
  275. moparisthebest Oh no I just read that esni RFC and it depends on "srv2"
  276. asterix has left
  277. moparisthebest Which means it'll require whole new mechanism instead of xep368 :'(
  278. asterix has joined
  279. moparisthebest Good news is it's an esni key per domain/port combo though Zash / jonas’
  280. moparisthebest Srv2: https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
  281. tao has joined
  282. Zash Ugh
  283. tao has left
  284. moparisthebest They called it httpsvc lol
  285. Zash Hrrrrr
  286. asterix has left
  287. asterix has joined
  288. pulkomandy has left
  289. pulkomandy has joined
  290. paul has left
  291. asterix has left
  292. asterix has joined
  293. paul has joined
  294. Lance has joined
  295. asterix has left
  296. asterix has joined
  297. wurstsalat has left
  298. wurstsalat has joined
  299. asterix has left
  300. asterix has joined
  301. asterix has left
  302. asterix has joined
  303. asterix has left
  304. asterix has joined
  305. strar has left
  306. strar has joined
  307. kikuchiyo has left
  308. pulkomandy has left
  309. kikuchiyo has joined
  310. skyfar has left
  311. skyfar has joined
  312. asterix has left
  313. asterix has joined
  314. asterix has left
  315. kikuchiyo has left
  316. pulkomandy has joined
  317. kikuchiyo has joined
  318. moparisthebest has left
  319. moparisthebest has joined
  320. Lance has left
  321. Lance has joined
  322. debacle has left
  323. sonny has left
  324. sonny has joined
  325. sonny has left
  326. sonny has joined
  327. sonny has left
  328. Lance has left
  329. sonny has joined
  330. sonny has left
  331. sonny has joined
  332. sonny has left
  333. sonny has joined