jdev - 2020-01-16


  1. moparisthebest lovetox, MattJ: actually webfolk are implementing a "srv2" RFC currently called httpsvc to support esni and http3 and such
  2. moparisthebest So we'll need a xep0368 successor to let us use it, but we can put more stuff in there, should be interesting
  3. pep. "http"svc :/
  4. moparisthebest This might be the recent one https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 basically allows extra stuff like I was trying to cram into HACX, just implement some more DNS records they are cheap! :)
  5. moparisthebest pep.: Before you get too worked up: > The specific name for this RR type is an open topic > for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as > they are easy to replace. Other names might include "B", "SRV2", > "SVCHTTPS", "HTTPS", and "ALTSVC".
  6. moparisthebest Maybe xsf should officially advocate for one of the better alternatives?
  7. pep. Is there a comparison with SRV? What's the difference/why it's not suitable
  8. pep. ok they add optional key=value pairs to the record and port is now optional
  9. moparisthebest pep.: Look at the psuedo example up top, you can't cram stuff like "use http3" or "here are the esni keys" in regular SRV
  10. pep. There doesn't seem to be a weight anymore either
  11. moparisthebest For xmpp we can have this be 1 lookup and include direct TLS, regular, quic, likely Bosh and websocket too
  12. moparisthebest Hmm why would you want weight when you can just pay a CDN
  13. moparisthebest Too bitter? :)
  14. pep. hmm?
  15. pep. I personally avoid CDNs like the plague
  16. pep. But I don't understand the comment anyway
  17. moparisthebest Http rfcs seem to be dominated by browsers and cdns
  18. pep. You mean CDN would do load balancing themselves so no need for weight?
  19. moparisthebest I wildly assume since weight kind of let's you do your own load balancing, maybe the cdns didn't want to because it could cut on their business
  20. pep. One does wonder when does capitalism ever stop..
  21. pep. Anyway.. this doesn't seem completely useless, the xsf should certainly keep an eye on it
  22. moparisthebest Especially if we want esni and QUIC, which we do :)
  23. moparisthebest pep.: ah https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00#page-29
  24. moparisthebest > Some other similar mechanisms such as SRV have a weight in-addition > to priority. That is excluded here for simplicity. It could always > be added as an optional SVCB parameter.
  25. sonny has left
  26. sonny has joined
  27. debacle has left
  28. bhaveshsgupta has joined
  29. moparisthebest has left
  30. moparisthebest has joined
  31. bhaveshsgupta has left
  32. serge90 has left
  33. bhaveshsgupta has joined
  34. serge90 has joined
  35. actupper has joined
  36. bhaveshsgupta has left
  37. moparisthebest has left
  38. moparisthebest has joined
  39. bhaveshsgupta has joined
  40. bhaveshsgupta has left
  41. bhaveshsgupta has joined
  42. bhaveshsgupta has left
  43. bhaveshsgupta has joined
  44. bhaveshsgupta has left
  45. bhaveshsgupta has joined
  46. bhaveshsgupta has left
  47. bhaveshsgupta has joined
  48. bhaveshsgupta has left
  49. bhaveshsgupta has joined
  50. bhaveshsgupta has left
  51. bhaveshsgupta has joined
  52. bhaveshsgupta has left
  53. bhaveshsgupta has joined
  54. bhaveshsgupta has left
  55. bhaveshsgupta has joined
  56. bhaveshsgupta has left
  57. bhaveshsgupta has joined
  58. actupper has left
  59. actupper has joined
  60. bhaveshsgupta has left
  61. bhaveshsgupta has joined
  62. asterix has joined
  63. bhaveshsgupta has left
  64. bhaveshsgupta has joined
  65. asterix has left
  66. asterix has joined
  67. paul has left
  68. paul has joined
  69. lovetox has joined
  70. bhaveshsgupta has left
  71. bhaveshsgupta has joined
  72. wurstsalat has joined
  73. asterix has left
  74. asterix has joined
  75. asterix has left
  76. asterix has joined
  77. bhaveshsgupta has left
  78. bhaveshsgupta has joined
  79. asterix has left
  80. asterix has joined
  81. asterix has left
  82. asterix has joined
  83. bhaveshsgupta has left
  84. lovetox has left
  85. bhaveshsgupta has joined
  86. bhaveshsgupta has left
  87. bhaveshsgupta has joined
  88. aj has joined
  89. lovetox has joined
  90. bhaveshsgupta has left
  91. aj has left
  92. bhaveshsgupta has joined
  93. bhaveshsgupta has left
  94. bhaveshsgupta has joined
  95. lovetox has left
  96. bhaveshsgupta has left
  97. bhaveshsgupta has joined
  98. asterix has left
  99. asterix has joined
  100. bhaveshsgupta has left
  101. bhaveshsgupta has joined
  102. paul has left
  103. paul has joined
  104. asterix has left
  105. asterix has joined
  106. bhaveshsgupta has left
  107. bhaveshsgupta has joined
  108. bhaveshsgupta has left
  109. bhaveshsgupta has joined
  110. sonny has left
  111. goffi has joined
  112. bhaveshsgupta has left
  113. bhaveshsgupta has joined
  114. bhaveshsgupta has left
  115. sonny has joined
  116. bhaveshsgupta has joined
  117. sonny has left
  118. bhaveshsgupta has left
  119. pulkomandy has left
  120. pulkomandy has joined
  121. kikuchiyo has joined
  122. bhaveshsgupta has joined
  123. Guus has left
  124. Guus has joined
  125. bhaveshsgupta has left
  126. bhaveshsgupta has joined
  127. madhur.garg has joined
  128. pep. https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00#section-6.1 I never understand why one SHOULDs the type of value that a sender can use, and MUSTs receivers not to read it if it doesn't correspond to that type
  129. pep. Especially for a new protocol
  130. pep. What's the goal behind? Allow custom stuff on top of that? Somebody implementing something custom would have a say on both writer and reader, they would be breaking the spec anyway.
  131. pep. And if it's to allow extensions, one would need to say "In this case you can set the value as XXX" alongside "you can read the value as XXX"..
  132. pep. Maybe that was for xsf@, meh. that's where I got the link
  133. sonny has joined
  134. bhaveshsgupta has left
  135. bhaveshsgupta has joined
  136. bhaveshsgupta has left
  137. bhaveshsgupta has joined
  138. rion has left
  139. rion has joined
  140. debacle has joined
  141. sonny has left
  142. bhaveshsgupta has left
  143. Bartek has joined
  144. Bartek has left
  145. bhaveshsgupta has joined
  146. bhaveshsgupta has left
  147. bhaveshsgupta has joined
  148. sonny has joined
  149. sonny has left
  150. Wojtek has joined
  151. pulkomandy has left
  152. pulkomandy has joined
  153. asterix has left
  154. asterix has joined
  155. lovetox has joined
  156. lovetox has left
  157. lovetox has joined
  158. serge90 has left
  159. serge90 has joined
  160. Wojtek has left
  161. flow pep., it's not really "doesn't correspond to that value". It says receivers have to ignore the whole entry if they do not understand the value
  162. flow Clients MUST ignore SVCB RRs where the "alpn" SvcParamValue is unknown or unsupported.
  163. lovetox hm if a user sets a proxy lets say socks5, does he expect DNS resolution via proxy?
  164. lovetox i know TOR users would not like if i dns resolve not via proxy, basically leaking the DNS request
  165. flow lovetox, tor users would say yes
  166. flow lovetox, I think the answer is that some do and some do not
  167. flow i.e. if you just use the socks5 proxy to be able to "reach the internet", but local dns resolves fine, then you are probably fine with dns lookups not using the socks5 proxy
  168. lovetox ok but is this some special case, or would you say this is should be followed always
  169. flow well if you implement support for dns lookups via the proxy, then I would probably simply always do it, and not make it configurable (or at least, only make it an advanced configuration option)
  170. lovetox ah no flow proxys support only very limited DNS resolution
  171. lovetox only A/AAAA
  172. lovetox which is probably still fine for socks5
  173. flow lovetox, IIRC socks5 supports udp?
  174. lovetox but for example its impossible to connect via websocket, without leaking the dns request
  175. flow at least at the protocol layer, not sure about the implementations
  176. flow so you could perform the lookup via udp over the proxy using a well known dns resolver
  177. lovetox of course you could do a dns resolution via socks5, but you have to impl the whole dns resolution protocol
  178. lovetox not really something i want to do to be honest
  179. flow some dns resolver libraries allow you to specify the IP or even the network link (for tunnels) to be used for the lookups
  180. pep. flow, my question was rather why do specs also not use MUST for the writer side ("Thou SHALL not use unsupported values")
  181. MattJ So they can remain extensible
  182. MattJ A future spec might add a new value, for example
  183. pep. Which I don't understand, as I said above
  184. MattJ and it's good to specify what legacy clients should do
  185. pep. MattJ, then the future spec would say "scrap that, you can use a new value here"
  186. MattJ Correct
  187. pep. So.. as the SHOULD is going to be overriten anyway by new specs, that's not an argument for extensibility imo
  188. MattJ Maybe also certain deployment-specific stuff would go there
  189. MattJ and it's good to know that clients that don't implement it will still have a defined behaviour
  190. pep. sure, because it says the reader should ignore it, that's fine
  191. pep. MUST
  192. pep. actually
  193. pep. It's just the fact that it's not symmetrical that confuses me
  194. sonny has joined
  195. MattJ Because the person doing the sending gets to make the choice what value they put there
  196. MattJ The reader doesn't get the option to explode if it sees an unknown value
  197. MattJ That's totally sensible if you ask me
  198. pep. What's the point of sending stuff that's "allowed by the spec" (SHOULD) that nobody can read (MUST) ?
  199. pep. Extensions would redefine both anyway
  200. MattJ But old clients wouldn't update
  201. MattJ So you still want their behaviour to be known
  202. MattJ Rather than undefined
  203. pep. receiving old clients?
  204. pep. Sending old clients would still be fine with MUST/MUST anyway
  205. pep. Receiving old clients are also fine with MUST/MUST anyway
  206. pep. From what I understand
  207. pep. If you can find me a case where it doesn't work anymore with MUST/MUST I'll be happy to oblige :p
  208. MattJ Of course it would *work*
  209. MattJ It just means the spec doesn't restrict stuff that it doesn't have to
  210. MattJ Spec A defines list of types X, everyone implements it, everyone is happy
  211. MattJ Spec B adds new type for that field
  212. MattJ In a MUST/MUST world, anyone who complies with Spec B suddenly stops being compliant with Spec A
  213. MattJ and that's just unnecessary
  214. pep. No, they would implement Spec A + Spec B
  215. pep. Or rather.. they'd implement Spec B
  216. MattJ They can't implement both because Spec A expressly forbids them from implementing Spec B
  217. pep. And they'd use spec B with compatible devices?
  218. pulkomandy has left
  219. MattJ I'm not sure how much there is that I haven't said that isn't obvious
  220. MattJ I have a meeting I'm prepping for, so need to disappear for a bit
  221. pep. Defining something obvious isn't generally helping
  222. pep. Have fun
  223. lovetox has left
  224. bhaveshsgupta has left
  225. bhaveshsgupta has joined
  226. pulkomandy has joined
  227. lovetox has joined
  228. Zash has left
  229. Neustradamus has left
  230. sonny has left
  231. Zash has joined
  232. pulkomandy has left
  233. pulkomandy has joined
  234. bhaveshsgupta has left
  235. bhaveshsgupta has joined
  236. bhaveshsgupta has left
  237. bhaveshsgupta has joined
  238. pulkomandy has left
  239. pulkomandy has joined
  240. kikuchiyo has left
  241. bhaveshsgupta has left
  242. bhaveshsgupta has joined
  243. actupper has left
  244. actupper has joined
  245. actupper has left
  246. actupper has joined
  247. kikuchiyo has joined
  248. Wojtek has joined
  249. sonny has joined
  250. bhaveshsgupta has left
  251. actupper has left
  252. actupper has joined
  253. bhaveshsgupta has joined
  254. lovetox has left
  255. bhaveshsgupta has left
  256. bhaveshsgupta has joined
  257. lovetox has joined
  258. bhaveshsgupta has left
  259. bhaveshsgupta has joined
  260. actupper has left
  261. actupper has joined
  262. sonny has left
  263. goffi has left
  264. bhaveshsgupta has left
  265. bhaveshsgupta has joined
  266. bhaveshsgupta has left
  267. bhaveshsgupta has joined
  268. actupper has left
  269. actupper has joined
  270. kikuchiyo has left
  271. sonny has joined
  272. pulkomandy has left
  273. actupper has left
  274. pulkomandy has joined
  275. rion has left
  276. bhaveshsgupta has left
  277. lovetox has left
  278. bhaveshsgupta has joined
  279. kikuchiyo has joined
  280. rion has joined
  281. debacle has left
  282. lovetox has joined
  283. pulkomandy has left
  284. pulkomandy has joined
  285. lovetox has left
  286. Wojtek has left
  287. bhaveshsgupta has left
  288. bhaveshsgupta has joined
  289. sonny has left
  290. bhaveshsgupta has left
  291. bhaveshsgupta has joined
  292. debacle has joined
  293. pulkomandy has left
  294. paul has left
  295. pulkomandy has joined
  296. Wojtek has joined
  297. bhaveshsgupta has left
  298. bhaveshsgupta has joined
  299. Wojtek has left
  300. asterix has left
  301. asterix has joined
  302. paul has joined
  303. serge90 has left
  304. serge90 has joined
  305. paul has left
  306. asterix has left
  307. asterix has joined
  308. bhaveshsgupta has left
  309. bhaveshsgupta has joined
  310. debacle has left
  311. debacle has joined
  312. wurstsalat has left
  313. wurstsalat has joined
  314. debacle has left
  315. asterix has left
  316. asterix has joined
  317. debacle has joined
  318. asterix has left
  319. asterix has joined
  320. debacle has left
  321. debacle has joined
  322. bhaveshsgupta has left
  323. bhaveshsgupta has joined
  324. strar has left
  325. strar has joined
  326. pulkomandy has left
  327. pulkomandy has joined
  328. bhaveshsgupta has left
  329. asterix has left
  330. bhaveshsgupta has joined
  331. pulkomandy has left
  332. pulkomandy has joined
  333. Syndace has left
  334. Syndace has joined
  335. bhaveshsgupta has left
  336. bhaveshsgupta has joined
  337. sonny has joined
  338. MattJ has left
  339. sonny has left
  340. paul has joined
  341. bhaveshsgupta has left
  342. sonny has joined
  343. paul has left
  344. bhaveshsgupta has joined
  345. MattJ has joined
  346. kikuchiyo has left
  347. kikuchiyo has joined
  348. sonny has left
  349. sonny has joined
  350. debacle has left
  351. debacle has joined
  352. kikuchiyo has left
  353. kikuchiyo has joined
  354. strar has left
  355. strar has joined
  356. sonny has left
  357. kikuchiyo has left
  358. kikuchiyo has joined
  359. paul has joined
  360. strar has left
  361. strar has joined
  362. strar has left
  363. kikuchiyo has left
  364. strar has joined
  365. bhaveshsgupta has left
  366. sonny has joined
  367. bhaveshsgupta has joined
  368. kikuchiyo has joined
  369. Zash has left
  370. Alex has left
  371. Alex has joined
  372. sonny has left
  373. paul has left
  374. Zash has joined
  375. paul has joined
  376. sonny has joined
  377. Zash has left
  378. wurstsalat has left
  379. Zash has joined
  380. bhaveshsgupta has left
  381. bhaveshsgupta has joined
  382. sonny has left
  383. sonny has joined
  384. bhaveshsgupta has left
  385. bhaveshsgupta has joined
  386. debacle has left
  387. debacle has joined