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