XSF Discussion - 2017-09-22


  1. edhelas

    that's what my mom told me yes

  2. Guus

    That CFE that was issued for XEP-0368 got me thinking about multiplexing services, using the ALPN TLS extension.

  3. Guus

    I'm new to this, so if I'm asking silly questions, feel free to point that out

  4. Zash

    That's all silly

  5. Guus

    (please wait until I've actually started questions)

  6. Guus

    can we multiplex Direct TLS and STARTTLS somehow?

  7. Zash

    In theory

  8. Guus

    as the latter doesn't start out as a TLS connection, I'm assuming ALPN isn't usable there?

  9. Zash

    More like redundant, like SNI

  10. zinid

    sni is redundant?

  11. Guus

    I don't get that last statement

  12. Zash

    I'm somewhat anti all those things. As I see it, all it does is move stuff into the TLS library.

  13. Guus

    second question: if we'd add BOSH to the multiplexing-mix, would that need a new ALPN protocol ID, or use one of the HTTP-ones? The latter would prevent multiplexing with another (non-XMPP) webservice, right?

  14. Zash

    XMPP, HTTP, TLS are all fairly easily identifiable from the first few bytes, so they can be multiplexed

  15. Guus

    third question for Zash: if not use SNI / ALPN, what's the alternative for multiplexing protocols (and hosts) on one port?

  16. Guus

    with existing tooling?

  17. Zash

    Prosody does it just fine, except TLS and STARTTLS can't be on the same port.

  18. Zash

    Duno if there are other tools

  19. Holger

    TCPMUX on Port 1!

  20. Holger

    https://en.wikipedia.org/wiki/TCP_Port_Service_Multiplexer

  21. Holger

    Guus: There's sslh, for example: http://www.rutschle.net/tech/sslh.shtml

  22. Zash

    Holger: Yeah, now we get TLSMUX on port 443 instead. All this has happened before etc.

  23. Ge0rG

    History is repeating itself.

  24. zinid

    you cannot offload TLS efficiently with starttls

  25. Zash

    Because?

  26. zinid

    because how?

  27. SouL

    Has anyone used http://tsung.erlang-projects.org/1/01/about/?

  28. zinid

    Zash: will you write your own balancer understanding starttls?

  29. Zash

    Is it really that hard?

  30. zinid

    Zash: writing haproxy or nginx?

  31. Zash

    zinid: I did that once, FWIW.

  32. zinid

    I think yes, it's hard

  33. zinid

    nobody interested in your handmade toys

  34. zinid

    SouL: I used tsung a lot of course

  35. Zash

    Hrrr

  36. Zash

    Doesn't nginx have starttls for its email things?

  37. Zash

    And didn't that Fastmail guy add XMPP support to nginx?

  38. zinid

    so you will use SMTP STARTTLS for XMPP STARTTLS?

  39. zinid

    if "add support" means writing shitty patch, then yes, he did

  40. Zash

    I don't think I want to hear this argument agaidn

  41. zinid

    what do you want to here?

  42. zinid

    nginx out of the box doesn't support xmpp starttls

  43. zinid

    also, some guys prefer haproxy

  44. zinid

    they will not change it only because of xmpp starttls

  45. Guus

    second question: if we'd add BOSH to the multiplexing-mix, would that need a new ALPN protocol ID, or use one of the HTTP-ones? The latter would prevent multiplexing with another (non-XMPP) webservice, right?

  46. Ge0rG

    I'd say bosh is http

  47. jonasw

    Guus, I thnik you’d multiplex based on the requested resource then

  48. jonasw

    layer 7 routing etc.

  49. Guus

    that makes sense

  50. Zash

    Did ALPN allow the client to set multiple types?

  51. Guus

    I like how you talk in the past tense :)

  52. Guus

    (and: I don't know)

  53. Zash

    Looks like it does. > "ProtocolNameList" contains the list of protocols advertised by the > client, in descending order of preference.

  54. Zash

    So, registering bosh wouldn't be too crazy.

  55. stefandxm

    is there any "larger" collective of error-messages than the one in xmpp core?

  56. stefandxm

    i am thinking now we get a lot of extended error codes that could probably be more generic if they were not in core.

  57. stefandxm

    so then maybe it already exists :)

  58. SamWhited

    Ge0rG: I was thinking more about tying message attaching to XEP-0359 IDs. I'm not sure that it gets us all that much anymore, because you have to support attaching by origin ID and by IDs set by the server, which feels just as weird as attaching based on the id attribute which may or may not exist.

  59. Ge0rG

    Yeah, non-mandatory non-unique IDs are what brought us into the trouble

  60. SamWhited

    I'm not actually a fan of having two different entities that can set IDs either.

  61. Ge0rG

    Two entities, three kinds of IDs. What could go wrong?

  62. Ge0rG

    Oh, all of them are optional.

  63. jonasw

    hm, right, you couldn’t attach something on a message without ID :/

  64. jonasw

    you can’t use the MAM ID anyways, thinking of it, because other clients don’t know it

  65. Ge0rG

    maybe it would be useful to enforce origin-id == message-id.

  66. jonasw

    interesting idea

  67. jonasw

    bring that up on standards@

  68. Ge0rG

    There seems to be no discussion of that XEP on standards at all.

  69. Ge0rG

    oh, nevermind. my filter-fu is bad

  70. SamWhited

    Why even have origin-id at that point? Clients could just set message-id

  71. Ge0rG

    because message-ids are not guaranteed to be unique, random or even present

  72. SamWhited

    I don't follow. If you're going to say in the spec "set both of these to the same thing and make it unique and random" why not just say "set the message-id and make sure it's unique and random"

  73. SamWhited

    ?

  74. Ge0rG

    SamWhited: because as a receiving entity, you don't know the rules that the sender used to generate the ID

  75. SamWhited

    Sure you do, they say they support stanza-id in their disco

  76. MattJ

    Right, that's why it exists

  77. SamWhited

    Actually, no, I lied

  78. MattJ

    and yes, it's optional, but I think it's fine for a XEP to fail gracefully on that

  79. SamWhited

    You're getting stuff from a MAM archive, and the client that sent it originally is online… you don't have the disco info for context.

  80. SamWhited

    is offline, even.

  81. MattJ

    You don't need disco, just the element existing or not

  82. Ge0rG

    MattJ: only if there is an origin-id in the message.

  83. SamWhited

    MattJ: I was suggesting the element didn't need to exist (if you're going to set it in both places, just use the id attr), but I was confused, that doesn't provide enough context.

  84. MattJ

    Oh right, yeah, you can't rely on that

  85. SamWhited

    So yah, I agree, if you're going to support stanza-id forcing the origin-id and the id attr to be the same sounds sensible to me.

  86. MattJ

    Also some servers think it's ok to modify that whenever they want anyway :)

  87. Ge0rG

    Yeah.

  88. Ge0rG

    But then the value of message-id doesn't matter anyway.

  89. Ge0rG

    And other servers (transports) tend to remove XML payload from MUC messages.

  90. SamWhited

    It matters for things that don't support stanza-id

  91. Ge0rG

    So we are fu... doomed anyway.

  92. SamWhited

    This doesn't "fix" anything, it just makes things slightly more consistent at the cost of a tiny bit of weird useless duplication

  93. fippo

    has anyone running a public server ever tried to run yahoos open_nsfw image classifier on the avatar data?

  94. fippo

    (you can probably guess what this classifier does)

  95. Ge0rG

    Hey that's funny. I've read the "Opportunistic TLS" proposal, then thought the term isn't correct, then thought that would be bike shedding. And now that exact discussion has happened anyway.

  96. moparisthebest

    Guus: yes I use sslh to multiplex everything