XSF Discussion - 2020-05-10

  1. j.r has left
  2. j.r has joined
  3. j.r has left
  4. j.r has joined
  5. stpeter has left
  6. mukt2 has left
  7. j.r has left
  8. j.r has joined
  9. debacle has left
  10. debacle has joined
  11. neshtaxmpp has left
  12. neshtaxmpp has joined
  13. debacle has left
  14. debacle has joined
  15. xsf has left
  16. neshtaxmpp has left
  17. xsf has joined
  18. moparisthebest has left
  19. Neustradamus has left
  20. Neustradamus has joined
  21. lorddavidiii has left
  22. debacle has left
  23. karoshi has joined
  24. moparisthebest has joined
  25. karoshi has left
  26. mukt2 has joined
  27. karoshi has joined
  28. sonny has left
  29. sonny has joined
  30. sonny has left
  31. sonny has joined
  32. karoshi has left
  33. karoshi has joined
  34. mukt2 has left
  35. pdurbin has joined
  36. govanify has left
  37. govanify has joined
  38. govanify has left
  39. govanify has joined
  40. sonny has left
  41. sonny has joined
  42. pdurbin has left
  43. govanify has left
  44. govanify has joined
  45. mukt2 has joined
  46. sonny has left
  47. sonny has joined
  48. stpeter has joined
  49. govanify has left
  50. govanify has joined
  51. mukt2 has left
  52. alexis has joined
  53. stpeter has left
  54. govanify has left
  55. govanify has joined
  56. arc has left
  57. arc has joined
  58. calvin has joined
  59. arc has left
  60. arc has joined
  61. govanify has left
  62. govanify has joined
  63. govanify has left
  64. govanify has joined
  65. alexis has left
  66. lorddavidiii has joined
  67. sonny has left
  68. sonny has joined
  69. mukt2 has joined
  70. govanify has left
  71. govanify has joined
  72. govanify has left
  73. govanify has joined
  74. pdurbin has joined
  75. paul has left
  76. govanify has left
  77. govanify has joined
  78. mukt2 has left
  79. calvin has left
  80. moparisthebest has left
  81. Yagiza has joined
  82. sonny has left
  83. sonny has joined
  84. arc has left
  85. arc has joined
  86. karoshi has left
  87. adiaholic_ has left
  88. adiaholic_ has joined
  89. arc has left
  90. arc has joined
  91. mukt2 has joined
  92. adiaholic_ has left
  93. adiaholic_ has joined
  94. sonny has left
  95. sonny has joined
  96. mukt2 has left
  97. sonny has left
  98. sonny has joined
  99. stpeter has joined
  100. DebXWoody has joined
  101. neshtaxmpp has joined
  102. govanify has left
  103. govanify has joined
  104. arc has left
  105. arc has joined
  106. adiaholic_ has left
  107. adiaholic_ has joined
  108. stpeter has left
  109. govanify has left
  110. govanify has joined
  111. govanify has left
  112. govanify has joined
  113. sonny has left
  114. sonny has joined
  115. bear has left
  116. arc has left
  117. arc has joined
  118. govanify has left
  119. govanify has joined
  120. sonny has left
  121. sonny has joined
  122. adiaholic_ has left
  123. adiaholic_ has joined
  124. govanify has left
  125. govanify has joined
  126. sonny has left
  127. sonny has joined
  128. govanify has left
  129. govanify has joined
  130. bear has joined
  131. govanify has left
  132. govanify has joined
  133. paul has joined
  134. govanify has left
  135. govanify has joined
  136. mukt2 has joined
  137. govanify has left
  138. govanify has joined
  139. mukt2 has left
  140. Jeybe has joined
  141. neshtaxmpp has left
  142. Half-Shot has left
  143. Half-Shot has joined
  144. stpeter has joined
  145. Jeybe has left
  146. Jeybe has joined
  147. arc has left
  148. arc has joined
  149. stpeter has left
  150. lovetox has joined
  151. andy has joined
  152. Yagiza has left
  153. goffi has joined
  154. mukt2 has joined
  155. Jeybe has left
  156. lskdjf has joined
  157. Jeybe has joined
  158. Tobias has joined
  159. Nekit has joined
  160. krauq has left
  161. Jeybe has left
  162. Jeybe has joined
  163. krauq has joined
  164. govanify has left
  165. govanify has joined
  166. krauq has left
  167. xecks has joined
  168. xecks has left
  169. xecks has joined
  170. rion has left
  171. karoshi has joined
  172. karoshi has left
  173. eevvoor has joined
  174. xsf has left
  175. stpeter has joined
  176. flow larma, I think we are probably saying the same: you may can deduce RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema
  177. flow larma, I think we are probably saying the same: you may can provide a indication of RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema
  178. debacle has joined
  179. flow larma, I think we are probably saying the same: you may can provide a "hint" towards RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema
  180. Zash Deriving intent from the schema?
  181. krauq has joined
  182. krauq has left
  183. krauq has joined
  184. Shell has joined
  185. flow I think I do that all the time, e.g. when it is unclear if the value provided by the xml-layer should be an integer or a string
  186. flow or if a certain element or attribute is required
  187. sonny has left
  188. sonny has joined
  189. sonny has left
  190. sonny has joined
  191. waqas has left
  192. Zash That seems fine to me. Isn't it primarily when the text and the schema disagree that the text takes priority? Like with examples.
  193. stpeter has left
  194. Jeybe has left
  195. Jeybe has joined
  196. sonny has left
  197. sonny has joined
  198. Mikaela has joined
  199. lorddavidiii has left
  200. lorddavidiii has joined
  201. Shell has left
  202. Shell has joined
  203. mukt2 has left
  204. Shell has left
  205. Shell has joined
  206. debacle has left
  207. debacle has joined
  208. debacle has left
  209. debacle has joined
  210. LNJ has joined
  211. LNJ has left
  212. arc has left
  213. LNJ has joined
  214. arc has joined
  215. lovetox has left
  216. werdan has joined
  217. lovetox has joined
  218. werdan has left
  219. lovetox has left
  220. debacle has left
  221. debacle has joined
  222. Shell has left
  223. Shell has joined
  224. APach has left
  225. APach has joined
  226. Shell has left
  227. Shell has joined
  228. emus has joined
  229. mukt2 has joined
  230. vanitasvitae has left
  231. vanitasvitae has joined
  232. lovetox has joined
  233. Yagiza has joined
  234. mimi89999 has left
  235. mimi89999 has joined
  236. Steve Kille has left
  237. lovetox has left
  238. Shell has left
  239. Shell has joined
  240. Steve Kille has joined
  241. mukt2 has left
  242. mukt2 has joined
  243. flow That certainly is the case. Although, I'm not sure about meaning of the "primarily" part, sometimes the text underspecifies the wire protocol, and the schema helps
  244. debacle has left
  245. debacle has joined
  246. debacle has left
  247. jonas’ has left
  248. sonny has left
  249. jonas’ has joined
  250. sonny has joined
  251. jonas’ has left
  252. jonas’ has joined
  253. debacle has joined
  254. j.r has left
  255. j.r has joined
  256. adiaholic_ has left
  257. adiaholic_ has joined
  258. debacle has left
  259. debacle has joined
  260. jonas’ has left
  261. jonas’ has joined
  262. jonas’ has left
  263. jonas’ has joined
  264. stpeter has joined
  265. jonas’ has left
  266. jonas’ has joined
  267. karoshi has joined
  268. Daniel has left
  269. !XSF_Martin has left
  270. Daniel has joined
  271. !XSF_Martin has joined
  272. !XSF_Martin has left
  273. !XSF_Martin has joined
  274. stpeter has left
  275. jonas’ has left
  276. jonas’ has joined
  277. mukt2 has left
  278. mukt2 has joined
  279. Maranda has left
  280. Maranda has joined
  281. Maranda has left
  282. Maranda has joined
  283. karoshi has left
  284. karoshi has joined
  285. Zash has left
  286. sonny has left
  287. sonny has joined
  288. LNJ has left
  289. Zash has joined
  290. adiaholic_ has left
  291. adiaholic_ has joined
  292. chyna has joined
  293. Shell has left
  294. mukt2 has left
  295. sonny has left
  296. sonny has joined
  297. Jeybe has left
  298. Shell has joined
  299. rion has joined
  300. karoshi has left
  301. karoshi has joined
  302. mukt2 has joined
  303. Jeybe has joined
  304. debacle has left
  305. sonny has left
  306. mukt2 has left
  307. sonny has joined
  308. mukt2 has joined
  309. stpeter has joined
  310. sonny has left
  311. sonny has joined
  312. Dele Olajide has joined
  313. pdurbin has left
  314. Dele Olajide has left
  315. Dele Olajide has joined
  316. krauq has left
  317. krauq has joined
  318. stpeter has left
  319. mukt2 has left
  320. mukt2 has joined
  321. sonny has left
  322. sonny has joined
  323. jonas’ has left
  324. jonas’ has joined
  325. sonny has left
  326. sonny has joined
  327. Max has left
  328. DebXWoody has left
  329. Max has joined
  330. Yagiza has left
  331. jonas’ has left
  332. jonas’ has joined
  333. mukt2 has left
  334. j.r has left
  335. j.r has joined
  336. karoshi has left
  337. mukt2 has joined
  338. adiaholic_ has left
  339. karoshi has joined
  340. adiaholic_ has joined
  341. Jeybe has left
  342. Max has left
  343. jonas’ has left
  344. jonas’ has joined
  345. Max has joined
  346. mukt2 has left
  347. lovetox has joined
  348. Yagiza has joined
  349. stpeter has joined
  350. pdurbin has joined
  351. Max has left
  352. pdurbin has left
  353. stpeter has left
  354. DebXWoody has joined
  355. nyco has left
  356. nyco has joined
  357. DebXWoody has left
  358. Shell has left
  359. robertooo has left
  360. robertooo has joined
  361. mukt2 has joined
  362. karoshi has left
  363. karoshi has joined
  364. Nekit has left
  365. Dele Olajide has left
  366. mukt2 has left
  367. mukt2 has joined
  368. lovetox has left
  369. calvin has joined
  370. eevvoor has left
  371. Zash has left
  372. Zash has joined
  373. calvin has left
  374. calvin has joined
  375. chyna has left
  376. david has left
  377. david has joined
  378. adiaholic_ has left
  379. adiaholic_ has joined
  380. j.r has left
  381. j.r has joined
  382. Jeybe has joined
  383. Jeybe has left
  384. Jeybe has joined
  385. pdurbin has joined
  386. stpeter has joined
  387. calvin has left
  388. pdurbin has left
  389. calvin has joined
  390. stpeter has left
  391. Kev has joined
  392. Neustradamus has left
  393. Neustradamus_ has left
  394. LNJ has joined
  395. Neustradamus has joined
  396. Neustradamus_ has joined
  397. debacle has joined
  398. calvin has left
  399. DebXWoody has joined
  400. Jeybe has left
  401. Jeybe has joined
  402. calvin has joined
  403. mukt2 has left
  404. arc has left
  405. arc has joined
  406. sonny has left
  407. sonny has joined
  408. emus has left
  409. emus has joined
  410. adiaholic_ has left
  411. adiaholic_ has joined
  412. werdan has joined
  413. chyna has joined
  414. sonny has left
  415. sonny has joined
  416. sonny has left
  417. sonny has joined
  418. mukt2 has joined
  419. lovetox has joined
  420. karoshi has left
  421. karoshi has joined
  422. adiaholic_ has left
  423. calvin has left
  424. j.r has left
  425. j.r has joined
  426. Jeybe has left
  427. Jeybe has joined
  428. adiaholic_ has joined
  429. pdurbin has joined
  430. stpeter has joined
  431. pdurbin has left
  432. stpeter has left
  433. govanify has left
  434. govanify has joined
  435. karoshi has left
  436. karoshi has joined
  437. adiaholic_ has left
  438. adiaholic_ has joined
  439. Nekit has joined
  440. xsf has joined
  441. lorddavidiii has left
  442. lovetox has left
  443. larma flow, not sure if I missed something in the channel binding discussion, but what would be wrong with `<mechanism xmlns='urn:xmpp:channel-binding' type='tls-exporter'>SCRAM-SHA-1-PLUS</mechanism>`. This looks a lot cleaner to me...
  444. Daniel i didn’t read the whole thread (just the initial xep proposal) but i like that solution
  445. flow larma, as special case for a hypothetical sasl mechanism channel binding type? I think I would rather go with a child element of <channel-binding/> to signal that. But again, I don't see why it should be signalled at all
  446. andrey.g has left
  447. flow larma, as special case for a hypothetical sasl mechanism exclusive channel binding type? I think I would rather go with a child element of <channel-binding/> to signal that. But again, I don't see why it should be signalled at all
  448. moparisthebest has joined
  449. Shell has joined
  450. larma flow, I thought it wasn't properly defined which type to use and that is an issue, isn't it?
  451. flow larma, no, the issue is that you do not know which cb types the remote endpoint supports
  452. flow -PLUS just signalls that cb is used, but not which cb type
  453. flow all currently registered cb types with IANA are currently available for all -PLUS sasl mechanisms
  454. flow and tls-server-end-point should be (basically) always available
  455. flow but tls-unique may not
  456. flow so if a client tries to do -PLUS with tls-unique, then things get a bit ugly
  457. Zash My understanding is that PLUS being advertised means channel binding is supported, and then negotiated in a header in a header in SCRAM.
  458. flow Zash, yes, but the server has no way to signal the supported cb types to the client
  459. flow IIRC there is no negotiation in gss api
  460. Zash Yes
  461. flow the client just says, I do cb type x and hopes the server support x
  462. flow the client just says, I do cb type x and hopes the server supports x
  463. Zash Right, which is weird and why it's good to try to solve that.
  464. flow correct, and I think my proposal solves that in a neat and clean way
  465. karoshi has left
  466. karoshi has joined
  467. calvin has joined
  468. lovetox has joined
  469. arc has left
  470. arc has joined
  471. calvin has left
  472. larma flow, I like yours more than the original proposal. But looking at the specs again, I was just wondering if instead of signaling it we could just define that a) in TLS < 1.3, only tls-unique may be used, b) in TLS 1.3 only tls-exporter may be used (although we'd probably want to wait for it to be IANA registered before defining that)
  473. sonny has left
  474. sonny has joined
  475. sonny has left
  476. sonny has joined
  477. calvin has joined
  478. flow why only tls-unique for tls 1.3? and why close the door for tls-server-end-point? all other cb's are probably blocked or at least stalled until the TLS APIs provide a way to extract the cb data, tls-server-end-point should usually be easily implementable and is probably better than performing no channel binding at all
  479. flow larma, ^
  480. flow also why no cb type agility? if something the past has shown is that cb types are not easy to get right
  481. Zash flow, funny tho that in Prosody, tls-unique is already implemented and my attempts at tls-server-end-point is stalled by not having access to the needed info
  482. larma flow: according to scram rfc, tls-unique is the default and must be implemented by servers. So as client, it's safe to use it even without further negotiation.
  483. stpeter has joined
  484. flow larma, unfortunately, I think, the reality is different
  485. flow larma, that is, chances are higher that you find tls-server-end-point than tls-unique
  486. flow Zash, isn't tls-server-end-point just the hash of the certificate?
  487. Zash flow, go read the rules for what hash algorithm to use, then try to implementing it given only an opaque binary blob
  488. goffi has left
  489. flow wheras tls-unique requires you to get the tls finial message, which is often not exposed (as raw bytes) by TLS APIs
  490. waqas has joined
  491. Zash I would be happy if TLS libs could have an API to tell what channel bindings are supported and then return the data for those by channel binding name.
  492. larma flow: so you are saying servers in practice are not rfc compliant?
  493. flow Zash, IIRC the rules just say "use whatever the cert uses as hash algorithm, unless if it is MD5 or SHA-1, in this case use SHA-256"
  494. Zash It's exposed by OpenSSL and LuaSec.
  495. flow larma, yep, there is always a discrepancy between whoe specifications writers wish the world would be, and how the world actually is
  496. Zash The hash algorithm of a certificate is not exposed however.
  497. flow Zash, it being the tls finished message?
  498. Zash Yes.
  499. Zash Interestingly it also does this for TLS 1.3
  500. Zash I have some WIP somewhere that just always uses SHA-256, and since that's what all certificates use it'll probably work until the day someone gets a SHA-512 or SHA-3 certificate.
  501. flow Zash, don't you have another way to get a hold of the whole certificate, as far as I understand it, the hash algorithm used is noted there
  502. calvin has left
  503. calvin has joined
  504. Zash are you telling me to implement another ASN.1 parser?
  505. flow anyway, last time I checked the situation in java land was the opposite: you can not get the tls finish message, but doing tls-server-endpoint is easy
  506. Zash I'd very much rather not.
  507. flow (with the standard Java SE API)
  508. Daniel Agility if it can be achieved with reasonable Syntax (and I like flows proposal in that regard) should be preferred to convention
  509. Daniel Yes in Java Standard api that's correct
  510. Daniel That's why I never implemented it
  511. Zash Sure, that'd be good. (why data in attributes tho?)
  512. flow Zash, data in attributes?
  513. Daniel Conscrypt does support unique. But then came tls1.3
  514. Daniel Zash: flows. Not Marvin's
  515. Zash flow, `<cb name='tls-unique'/>` instead of `<cb>tls-unique</cb>`, but this is a nit
  516. Zash Daniel, ?
  517. flow Zash, right, I actually think the latter should be considered an anti-pattern when designing xmpp wire protocol
  518. flow because <cb name=""/> alows us to extend <cb/> with child elements if that ever becomes necessary
  519. Zash No, that's the opposite of what it is
  520. Daniel Ah. Sorry. I was confused
  521. Daniel Yeah I don't care
  522. Zash In general data should go in text nodes and metadata in attributes.
  523. flow so this was a deliberate design choice, and I think pattern to list something as cdata in elements should be avoided
  524. flow Zash, because?
  525. Zash Because.
  526. Zash General XMPP or XML design advice that I don't remember the exact location of
  527. mukt2 has left
  528. flow well I think keeping the door open to child element based extensibility is a better argument than some handwaving rule ;)
  529. stpeter has left
  530. mukt2 has joined
  531. flow that design advice *may* is sensible if you allow mixed content, but we do not allow mixed content
  532. Zash Also because `stanza:get_child_text()` in Prosody is the best API ever :)
  533. DebXWoody has left
  534. flow Zash, I am sure your get_attribute_value() API is of similar quality ;)
  535. Zash There's no such thing.
  536. flow because it's a map (or table?)
  537. flow because it's a map (or table?)?
  538. Zash yes
  539. larma If it was <mechanism name='SCRAM-SHA-1-PLUS' /> we could do <mechanism name='SCRAM-SHA-1-PLUS'><cb type='tls-unique' /></mechanism> now, so I'm totally on flows side to prefer attributes for extensibility
  540. Zash Then why isn't it like that in SASL2?
  541. adiaholic_ has left
  542. adiaholic_ has joined
  543. larma If it's not clear that extensibility is not needed of course.
  544. flow larma, yep, that is the point. but i really like to stress that there is no reason to list cb types per sasl mechanism, and that this is also verly likely to be true in the future
  545. flow Zash, good point, guess someone would need to convince dave to change it
  546. Zash <mechanisms> <mechanism> <name>PLAIN</name> <channel-bindings> <channel-binding> <name>tls-unique</name> </////>
  547. werdan has left
  548. flow using a <name/> element has the drawback that there could be multiple, whereas there can only be one attribute with the name 'name'
  549. Zash You can't extend attributes either tho.
  550. flow right, but I can extend the element they are declared at
  551. larma flow: well I agree that cb is unlikely to be specific to a single mechanism, on the other hand, one typically also doesn't support multiple mechanisms with channel binding either. And the supported cb are clearly related to that mechanism and not related to all of them.
  552. flow larma, wait, one typically also does not support multiple mechanisms with channel binding either? I'd assume quite the contrary to be the case, given that SCRAM-SHA-256 starts to gain popularity
  553. flow the server presents you with a list of sasl mechanism currently. my propsal adds another list with supported cb types alongside the sasl mechanism list. the client is free to choose the combination he deems to be best
  554. larma Well, a server that supports SCRAM-SHA-256 is not better in any regard if it also supports SCRAM-SHA-1
  555. moparisthebest has left
  556. flow I am not sure if this is true. you are probably hinting towards that the server also has to store the auth data using the weaker hash
  557. larma Yes.
  558. Zash If you see a Prosody offering both then it is most likely storing the password in plain text.
  559. Zash Or someone implemented a way to store two credentials without me knowing
  560. flow I think there are lot of cases where the password is stored in plain text server side, but does that mean that those servers should continue to offer only scram sha-1 for eternity?
  561. Yagiza has left
  562. flow larma, I see, of course, your point. but this is not an argument to closely couple the sasl mechanisms and the cb types in the sasl mechanism stream feature
  563. Zash currently it's a matter of whether the sasl mechanism supports gss-api, or somesuch.
  564. flow Zash, please clarify 'it'? I'd assume that every -PLUS mechanism supports gss-api (or maybe I confuse gss-api with something different)?
  565. larma flow: it's scram that supports gssapi, no?
  566. Zash SCRAM supports GSS-API. GSS-API supports channel bindings.
  567. Zash Or something like that.
  568. flow IIRC I did gss-api stuff when implementing the -PLUS variants of scram
  569. Zash Point is that there's some indirection.
  570. flow yes, the whole existence of -PLUS is a design weakness
  571. larma And -PLUS is just a dirty hack to announce that the server supports cb
  572. flow not sure if it was because channel binding came after SASL was initialy invented
  573. flow if the RFC SASL profile would also allow for a list of supported cb types, alongside the list of supported sasl mechanisms, then gss-api would be sufficient to negotiate cb
  574. Zash Redefine PLUS to mean `tls-unique`? Invent a new SCRAM-SHA-256-PLSCRT for tls-server-endpoint? :D
  575. Zash Wait that's basically what Sam proposed
  576. Zash Almost.
  577. lovetox has left
  578. arc has left
  579. arc has joined
  580. larma Given that `tls-unique` is a MUST on servers that do -PLUS and SHOULD on clients, it's not even incompatible to define -PLUS = `tls-unique` ;)
  581. Zash Mmmmmm `SCRAM-SHA-256-DOUBLEPLUS`
  582. Zash Except it's too long
  583. larma I like -PLUSPLUS more :D
  584. Zash SCRAM-SHA-2-PLUSPLUS is 20 chars
  585. bear has left
  586. Tobias has left
  587. larma Or maybe we just should stop with -PLUS, because if we announce cb types anyway, we don't need -PLUS anymore
  588. Zash True
  589. LNJ has left
  590. LNJ has joined
  591. karoshi has left
  592. Jeybe has left
  593. Jeybe has joined
  594. Jeybe has left
  595. Jeybe has joined
  596. karoshi has joined
  597. LNJ has left
  598. sonny has left
  599. sonny has joined
  600. Nekit has left
  601. Nekit has joined
  602. fredpunk has joined
  603. fredpunk has left
  604. bear has joined
  605. govanify has left
  606. govanify has joined
  607. stpeter has joined
  608. govanify has left
  609. govanify has joined
  610. calvin has left
  611. calvin has joined
  612. pdurbin has joined
  613. Mikaela has left
  614. robertooo has left
  615. robertooo has joined
  616. sonny has left
  617. sonny has joined
  618. sonny has left
  619. govanify has left
  620. govanify has joined
  621. govanify has left
  622. govanify has joined
  623. xecks has left
  624. xecks has joined
  625. debacle has left
  626. debacle has joined
  627. pdurbin has left
  628. xecks has left
  629. xecks has joined
  630. Daniel has left
  631. sonny has joined
  632. debacle has left
  633. Daniel has joined
  634. karoshi has left
  635. lskdjf has left
  636. calvin has left
  637. karoshi has joined
  638. andy has left
  639. Jeybe has left
  640. Seve has left
  641. arc has left
  642. arc has joined
  643. stpeter has left
  644. krauq has left
  645. krauq has joined
  646. xecks has left
  647. calvin has joined
  648. govanify has left
  649. govanify has joined
  650. sonny has left
  651. sonny has joined
  652. arc has left
  653. arc has joined
  654. Shell has left
  655. chyna has left
  656. pdurbin has joined
  657. karoshi has left
  658. karoshi has joined