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.


  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


  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.


  192. pep.


  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