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. 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

  26. pep.

    Especially for a new protocol

  27. 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.

  28. 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"..

  29. pep.

    Maybe that was for xsf@, meh. that's where I got the link

  30. 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

  31. flow

    Clients MUST ignore SVCB RRs where the "alpn" SvcParamValue is unknown or unsupported.

  32. lovetox

    hm if a user sets a proxy lets say socks5, does he expect DNS resolution via proxy?

  33. lovetox

    i know TOR users would not like if i dns resolve not via proxy, basically leaking the DNS request

  34. flow

    lovetox, tor users would say yes

  35. flow

    lovetox, I think the answer is that some do and some do not

  36. 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

  37. lovetox

    ok but is this some special case, or would you say this is should be followed always

  38. 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)

  39. lovetox

    ah no flow proxys support only very limited DNS resolution

  40. lovetox

    only A/AAAA

  41. lovetox

    which is probably still fine for socks5

  42. flow

    lovetox, IIRC socks5 supports udp?

  43. lovetox

    but for example its impossible to connect via websocket, without leaking the dns request

  44. flow

    at least at the protocol layer, not sure about the implementations

  45. flow

    so you could perform the lookup via udp over the proxy using a well known dns resolver

  46. lovetox

    of course you could do a dns resolution via socks5, but you have to impl the whole dns resolution protocol

  47. lovetox

    not really something i want to do to be honest

  48. flow

    some dns resolver libraries allow you to specify the IP or even the network link (for tunnels) to be used for the lookups

  49. pep.

    flow, my question was rather why do specs also not use MUST for the writer side ("Thou SHALL not use unsupported values")

  50. MattJ

    So they can remain extensible

  51. MattJ

    A future spec might add a new value, for example

  52. pep.

    Which I don't understand, as I said above

  53. MattJ

    and it's good to specify what legacy clients should do

  54. pep.

    MattJ, then the future spec would say "scrap that, you can use a new value here"

  55. MattJ

    Correct

  56. pep.

    So.. as the SHOULD is going to be overriten anyway by new specs, that's not an argument for extensibility imo

  57. MattJ

    Maybe also certain deployment-specific stuff would go there

  58. MattJ

    and it's good to know that clients that don't implement it will still have a defined behaviour

  59. pep.

    sure, because it says the reader should ignore it, that's fine

  60. pep.

    MUST

  61. pep.

    actually

  62. pep.

    It's just the fact that it's not symmetrical that confuses me

  63. MattJ

    Because the person doing the sending gets to make the choice what value they put there

  64. MattJ

    The reader doesn't get the option to explode if it sees an unknown value

  65. MattJ

    That's totally sensible if you ask me

  66. pep.

    What's the point of sending stuff that's "allowed by the spec" (SHOULD) that nobody can read (MUST) ?

  67. pep.

    Extensions would redefine both anyway

  68. MattJ

    But old clients wouldn't update

  69. MattJ

    So you still want their behaviour to be known

  70. MattJ

    Rather than undefined

  71. pep.

    receiving old clients?

  72. pep.

    Sending old clients would still be fine with MUST/MUST anyway

  73. pep.

    Receiving old clients are also fine with MUST/MUST anyway

  74. pep.

    From what I understand

  75. pep.

    If you can find me a case where it doesn't work anymore with MUST/MUST I'll be happy to oblige :p

  76. MattJ

    Of course it would *work*

  77. MattJ

    It just means the spec doesn't restrict stuff that it doesn't have to

  78. MattJ

    Spec A defines list of types X, everyone implements it, everyone is happy

  79. MattJ

    Spec B adds new type for that field

  80. MattJ

    In a MUST/MUST world, anyone who complies with Spec B suddenly stops being compliant with Spec A

  81. MattJ

    and that's just unnecessary

  82. pep.

    No, they would implement Spec A + Spec B

  83. pep.

    Or rather.. they'd implement Spec B

  84. MattJ

    They can't implement both because Spec A expressly forbids them from implementing Spec B

  85. pep.

    And they'd use spec B with compatible devices?

  86. MattJ

    I'm not sure how much there is that I haven't said that isn't obvious

  87. MattJ

    I have a meeting I'm prepping for, so need to disappear for a bit

  88. pep.

    Defining something obvious isn't generally helping

  89. pep.

    Have fun