XMPP Council - 2018-03-21


  1. dwd

    In my view, you can't add a bunch of stuff about SRV fallback into XEP-0368.

  2. jonasw

    dwd, not even if it defines new SRV records?

  3. moparisthebest

    dwd, the thing is, the SRV fallback, uh, algorithm?, affects how a server admin MUST set up their records

  4. moparisthebest

    as I found out the hard way, dino tries xep-368, doesn't do alpn, and does not fall back if the TCP connection succeeds

  5. moparisthebest

    no one using dino can use my server then

  6. jonasw

    moparisthebest, I’m not sure why a server operator would give ALPN-requiring SRV records high priroity though

  7. jonasw

    that is, preference

  8. dwd

    Sure, but those records are defined in RFC 6120, and not in XEP-0368. Ideally, we'd merge '368 into an RFC update, mind, but the SRV fallback strategy applies to any SRV records, not just ;368 ones.

  9. moparisthebest

    because I prefer them to connect that way first, it works in all my other clients :)

  10. jonasw

    putting them with low preference in the list would work for the case where 5222 is filtered, wouldn’t it?

  11. moparisthebest

    dwd, well sure but more to say 'if you implement 368, you MUST implement SRV fallback like so...'

  12. moparisthebest

    that wouldn't be appropriate?

  13. moparisthebest

    and I agree re: RFC update, but until then, it should be specified *somewhere*

  14. Zash

    Is there not precedent in writing down things in XEPs that are later rolled into RFC updates?

  15. Kev

    There is, but in this case it's something that implementing just the RFC won't be able to connect to at all.

  16. Kev

    We can't really have things in SRV records that connect ok at the TCP level but then fail for 6120.

  17. jonasw

    Kev, they don’t fail for rfc6120

  18. jonasw

    because RFC 6120 doesn’t konw a thing about TLS over XMPP

  19. Kev

    > as I found out the hard way, dino tries xep-368, doesn't do alpn, and does not fall back if the TCP connection succeeds > no one using dino can use my server then

  20. Kev

    Ah, ok.

  21. Kev

    So this isn't SRV fallback, it's 368 fallback.

  22. jonasw

    Kev, yeah, but that’s because dino fails to implement xep-0368 (by adding ALPN) but still tries XEP-0368 records first.

  23. dwd

    Welcome to write a SRV fallback strategy in a new XEP. Just not in '368.

  24. moparisthebest

    Kev, no it's SRV fallback in general, the rules are not defined

  25. jonasw

    moparisthebest, but technically there would be no issue to let clients prefer the 5222 method, would there?

  26. dwd

    Kev: It's not specific to '368 direct TLS SRV records.

  27. Holger

    jonasw: ALPN is a SHOULD in 0368.

  28. moparisthebest

    other than then they would try that first, might be a bit slower, I wouldn't prefer it

  29. jonasw

    moparisthebest, okay, so it’s actually a configuration issue at your side, IMO

  30. moparisthebest

    all I'm saying is the way you set up records depends on SRV fallback behavior, 368 or not, it just happens to matter more with 368

  31. moparisthebest

    or be more visible

  32. jonasw

    preferring a 443-multiplexing-hack over something which works with all clients seems broken to me.

  33. moparisthebest

    so I'd probably want to put this in 368, or create a new SRV fallback XEP, and make 368 depend on it

  34. moparisthebest

    would the second be ok if you don't like the first?

  35. Holger

    Why not make ALPN a MUST?

  36. moparisthebest

    various reasons, still support isn't widespread, but also privacy reasons

  37. Holger

    (I don't like ALPN at all, but that SRV fallback seems even uglier to me.)

  38. moparisthebest

    ALPN support is far better in 2018 than it was in 2015

  39. moparisthebest

    well again SRV fallback is an issue without 368/alpn too

  40. dwd

    moparisthebest: Not sure that 368 needs to depend on it at all, really.

  41. jonasw

    moparisthebest, how is it an issue without 368/alpn?

  42. moparisthebest

    just one example of many, you have multiple servers for redundancy

  43. moparisthebest

    and your top priority one messes up, has wrong certificate, accepts the connection but the xmpp server is messed up, any number of ways

  44. moparisthebest

    now nothing falls back to the other ones, oops you actually have no redundancy

  45. Holger

    Should we fall back if everything succeeds up to the bind request?

  46. moparisthebest

    I think I covered a few such scenarios in my email, I remember the BGP one :P

  47. Kev

    As I mentioned on list, I think, things can go wrong post-bind too.

  48. dwd

    Fair warning: I'm going to shut you all up in fifteen for the Council meeting, BTW.

  49. Kev

    Yay.

  50. moparisthebest

    yea I don't know the exact point we define as 'no more fallback', it seems clearer on c2s to me than s2s

  51. dwd

    But if somebody wants to hang about and do the minutes...

  52. dwd

    (Since you're all here).

  53. moparisthebest

    but right now it's totally ambiguous/wrong in the RFC

  54. SamWhited

    Please hang around and do the minutes; live minutes are the best minutes!

  55. dwd

    I can't do them this time; I'm on a train - and since this train gets into Paddington at 16:30, I'm on a hard stop for the meeting.

  56. moparisthebest

    but the general council consensus seems to be defining SRV fallback should be new xep?

  57. moparisthebest

    if so, I'll try to find time to work on that

  58. Kev

    I think a new XEP seems most appropriate here.

  59. moparisthebest

    that's fair, will be easiest to work out the details there too

  60. SamWhited

    Having it in 0368 seems fine to me, but we probably want to work out the details somewhere else first.

  61. SamWhited

    Since 0368 is in draft.

  62. moparisthebest

    at a basic level, if you stop at TCP connection, or any place before at least validating the certificate, an attacker controlling a path to any higher priority server can prevent a successful connection, and that's wrong

  63. dwd

    Oooh, every device I have just told me Council's in ten minutes. How exciting.

  64. dwd

    SamWhited: I'd actually like to get everything sorted in XEPs, and we'll gather them into an RFC to update RFC 6120. (As in, an RFC that updates, not an RFC that obsoletes, unless the mythic XMPP2 stuff actually happens)

  65. SamWhited

    That makes sense too

  66. SamWhited

    We could also combine with 0368 if/when the SRV fallback one goes to draft if it doesn't look like an RFC is going to happen.

  67. dwd

    It might *even* be worth doing this straight into an Internet Draft... We'd get review from the IETF folks on this. I was chatting to Chris Newman at the weekend about XEP-0368 anyway. (Chris did STARTTLS back in the day, and now leans toward direct TLS).

  68. Ge0rG

    STARTTLS always felt like a hack to me.

  69. Zash

    Direct TLS is the hack! :(

  70. MattJ

    What would you have done at the time?

  71. MattJ

    HTTPS spent a long time with the IP-per-host situation

  72. Ge0rG

    MattJ: what HTTPS did. One certificate per IP address.

  73. dwd

    Ge0rG: There were lots of reasons behind STARTTLS. None of them apply anymore (or the arguments are massively weakened)

  74. SamWhited

    Direct TLS just makes sense now that everything should be TLS… why use application level protocol negotiation to negotiate something at a lower level in the stack? Just do the lower level thing first, then do the application level thing.

  75. Ge0rG

    dwd: I know

  76. dwd

    SamWhited: Sure... But back in the day, there was also Kerberos etc. It's just that now, Kerberos runs over TLS, instead of doing its own crypto.

  77. Ge0rG

    Now let me get started about how the CA industry and the NSA lobbied us security folks into believing that no security is better than opportunistic security.

  78. Ge0rG

    Or maybe we skip that for the Council meeting.

  79. Kev

    'tis time.

  80. dwd

    'tis time.

  81. dwd

    So I should warn you all that I'm on a train, therefore on a number of G's hopefully more than 3.

  82. dwd

    Ouch, lag.

  83. Zash

    Relativistic G-forces? Ouch indeed

  84. Ge0rG

    dwd: I can't imagine regular trains exceeding something like 1.5G

  85. dwd

    1) Roll Call:

  86. dwd

    I'm for bacon and cheese, myself.

  87. Ge0rG

    bacon and cheese rolls? I'm in!

  88. dwd

    SamWhited, daniel?

  89. SamWhited

    I thought I was supposed to be the one to ask for cheese? We put cheese on (or in) everything.

  90. Kev

    I'm here, obviously.

  91. SamWhited

    I guess I'll have to ask for kippers just to even things out.

  92. dwd

    OK, I don't see daniel but maybe he'll join us later.

  93. dwd

    2) Advance XEP-0066 to Final

  94. Ge0rG

    It looks like there was some major resistance to that.

  95. Kev

    It's not clear to me that we have satisfied the implementation requirements, even ignoring all the other issues onlist :)

  96. dwd

    I think I'm -1 on this, I don't think it meets the implementation criteria.

  97. Kev

    So I don't think it even needs a Council vote, I don't think it meets requirements for us to vote.

  98. dwd

    Votes, please?

  99. Kev

    But if it did, I'd be -1.

  100. Ge0rG

    -1

  101. Ge0rG

    I still think 66 is a good candidate for the "take the best parts and run" approach suggested some Meetings ago

  102. dwd

    Kev: I'm actually unclear who decides the implementation criteria, so I shall assume that's for us to veto if we believe it doesn't.

  103. dwd

    SamWhited: Any vote?

  104. SamWhited

    It seems "good enough" to me, I'm +1. Although with the note that there is a bit of awkwardness and I agree that "take the best parts and run" sounds good too.

  105. dwd

    3) Advance XEP-0048 to Final

  106. Ge0rG

    -1

  107. dwd

    Note there is a competing proposal in bookmarks2, we're voting on that later.

  108. dwd

    I'm -1 to advance, I'd rather move this to historical again.

  109. SamWhited

    +1 to freeze 0048 and new work can go into bookmarks2

  110. Kev

    Again, this wasn't clear that there are two independent implementations of what's specced in this version. Plus assorted issues with it.

  111. Kev

    (-1)

  112. SamWhited

    Although I also agree that this could be historical.

  113. Ge0rG

    SamWhited: freeze as final or as historical?

  114. SamWhited

    Freeze as in final, but if we want to have a historical vote I'd +1 that either way.

  115. dwd

    4) Adopt Proposal "Bookmarks 2 (This Time it's Serious)"

  116. Ge0rG

    I'd like to see where Bookmarks2TTiS leads

  117. Kev

    Aside: I'd be in favour of revert 48 to iq:private, and make it Historical, and advance bookmarks2 in PIP.

  118. SamWhited

    +1 assuming "adopt" means "accept as experimental"

  119. Kev

    +1

  120. Ge0rG

    +1 to what Sam said

  121. dwd

    For the record, I'm happy if this changes title, but it'd be good if we changed '48's title at the same time...

  122. dwd

    ALso +1.

  123. dwd

    (Obv)

  124. Kev

    Suggestion: Change 48 to Bookmarks in Private Storage, and change TTiF to Bookmarks in Pubsub or something.

  125. Kev

    If we want to change titles.

  126. SamWhited

    I would be -1 to reverting it to private storage.

  127. Kev

    Even while also changing it to historical (documenting what's in place), when it's what's in place and PIP isn't?

  128. dwd

    SamWhited: Seems that's what's implemented, mind.

  129. dwd

    5) XEP-0050 Ad-Hoc Commands: Clarify 'execute' actions equivalence.

  130. Kev

    There is a fundamental choice her.

  131. Kev

    There is a fundamental choice here.

  132. dwd

    This is PR #591 by the way.

  133. dwd

    And there is *also* #598 which competes.

  134. Kev

    Either change the text to be clear that there's a bad state, which is a clarification, or change the text to be sensible and avoid the bad state.

  135. Kev

    Flow's is the technically better change, I think, but is a breaking change to xep50.

  136. Kev

    Mine is just clarifying that if you do something in particular, you're being stupid.

  137. dwd

    Kev: Breaking in theory or practise?

  138. Kev

    dwd: This conversation came about because of people doing silly things. So I think in practice.

  139. Kev

    Although possibly not in an untenable way.

  140. Ge0rG

    Wouldn't it be better to fix things in practice then?

  141. Kev

    Ge0rG: Well, that's why my text explains that doing this is broken. Which it always has been, people just don't realise.

  142. Kev

    I'm -1 on Flow's PR as-is, because I think it needs to explain the breaking change, but I could be persuaded either way on the basic approach. Noting that breaking changes to Draft XEPs we should be trying to avoid.

  143. Ge0rG

    Kev: if people didn't realize that, they probably never ran into the issue so fixing the XEP to have a better behavior won't make them run into even more things?

  144. SamWhited

    I'm +1 to flows change, but also agree that an explanation would be useful.

  145. Kev

    SamWhited: What's the justification here for a breaking change to a Draft XEP?

  146. dwd

    Hmmm. So I think I'm +1 on one of these, but I'm not sure I care which...

  147. Kev

    I think I can be persuaded about making the breaking change, but I don't think I am yet.

  148. dwd

    Kev: I'm not sure what this change is breaking. I mean, it means something works which previously did not.

  149. Kev

    dwd: It means behaviour will change.

  150. Ge0rG

    dwd: people following the "new" XEP could run into broken servers

  151. dwd

    Ge0rG: Ah, good point.

  152. Kev

    Where previously an illegal state would prevent you doing anything other than cancel, now it'll silently succeed in doing something that it wouldn't before.

  153. Ge0rG

    so I'm +1 if we add a note similar to what we did in 0045 last week

  154. Ge0rG

    I'm not insisting on a feature though.

  155. dwd

    Kev: I think that's a stretch for a claim this is breaking, though.

  156. Kev

    I think if you change the required behaviour of entities, that's a breaking change.

  157. dwd

    Yeah, I think I'm +1 on both of these.

  158. SamWhited

    It seems worth cleaning this up, and since it doesn't seem like it would be the end of the world we might as well do it right.

  159. Kev

    Oh, wait wait.

  160. Kev

    I think both PRs might actually be wrong.

  161. dwd

    I'm waiting.

  162. Kev

    Because execute is used for setting a default.

  163. dwd

    You're going to veto your own PR?

  164. Kev

    So in Flow's case, I think this change means that where it was previously possible to set 'no default', now it forces a default to be set.

  165. Kev

    And in my case where I claim it's not a legal state, actually it is saying that there's no default action.

  166. Kev

    Except that's also contradictory.

  167. dwd

    Hmmmm.

  168. Ge0rG

    Now I'm completely lost.

  169. Kev

    Ge0rG: exactly

  170. Kev

    I propose

  171. dwd

    So in this case I'll change my vote to no vote, and can you take this to the list.

  172. dwd

    Anyone voting on this one?

  173. Ge0rG

    Kev: ELI5 on-list please.

  174. Kev

    We -1 both of these PRs now, and we each commit to reading this bit of the XEP *in detail* until we understand it properly, and then discuss properly next week.

  175. SamWhited

    yah, I'll also go on list since this wasn't my understanding

  176. SamWhited

    I'll re-read and make sure I didn't interpret something wrong.

  177. Kev

    Because I spent a good chunk of time on this and I think I got it slightly wrong last time.

  178. Ge0rG

    Kev: feel free to collaborate with flow so that you prepare a single PR :)

  179. dwd

    Ge0rG: SamWhited: You vetoing or what? I'm completely lost now.

  180. Kev

    This is a badly defined bit of spec.

  181. Kev

    I am -1 to both for now.

  182. dwd

    Kev: Badly specified bit of definition.

  183. SamWhited

    dwd: I am on list.

  184. Ge0rG

    dwd: on-list as well

  185. dwd

    Cool. For the next one too?

  186. Ge0rG

    Yes.

  187. SamWhited

    Yes, sorry, for both of these PRs.

  188. Kev

    Yes, on-list might work for me too, I guess, default to -1 if I don't reply :)

  189. Ge0rG

    Kev: is that a -0.5?

  190. dwd

    7) XEP-0223: Add a warning about publish-options support https://github.com/xsf/xeps/pull/608

  191. Kev

    Peter always liked it when Isode folks disagreed on list. I wonder what he thinks of Isode folks disagreeing with their own PRs :)

  192. Kev

    +1

  193. dwd

    This seems like a +1

  194. Ge0rG

    the PR comes with a notice about making discovery a MUST.

  195. Ge0rG

    Can we vote on that too?

  196. dwd

    Kev: I've rejected my own protoXEP once. I think I beat you. (So has Peter, mind)

  197. SamWhited

    +1

  198. Ge0rG

    +1

  199. Kev

    dwd: Yes, but that was a protoXEP, I don't remember anyone doing it for a PR (but might have).

  200. Kev

    As a note to Editor, PEP needs to change to Pubsub in this PR before merge, I think.

  201. Kev

    This isn't storing anything in PEP.

  202. SamWhited

    oh good point; add a note on the PR?

  203. jonasw

    Kev: put that on the pr please

  204. Kev

    (Meaning is clear, but terminology is wrong, commenting now)

  205. dwd

    OK, I'm changing my mind and vetoing - yeah, I prefer MUST check discovery and I'm find with changing it to Pubsub.

  206. Kev

    I'm fine with just giving a provisional +1 to the PR after SHOULD/MUST and PEP/Pubsub, if that speeds things along.

  207. Kev

    dwd: You?

  208. Ge0rG

    dwd: couldn't you "+1 under the following conditions" instead?

  209. dwd

    Well, probably. But I'll hold a veto on it to make sure it happens. :-)

  210. SamWhited

    I also prefer MUST, I figured we might as well go ahead and merge this, but if a pr changing the wording can happen quickly that's fine too.

  211. dwd

    But yeah, I'll change to a +1 the moment the MUST happens.

  212. dwd

    8) Next Meeting

  213. Ge0rG

    +1W?

  214. dwd

    I have a feeling that Europe changes timezone at the weekend, is that right?

  215. Zash

    Yes

  216. Ge0rG

    rumors!

  217. Kev

    Yes, Sunday at 1AM

  218. Kev

    Which is great news for those of us running a 10K Sunday morning.

  219. dwd

    Shall we shift it to 1500Z in that case for next week? (Sorry SamWhited).

  220. Kev

    Yes, please.

  221. Ge0rG

    So it will "move" to 1700 CEST?

  222. dwd

    Everyone else in agreement? (Just keeping it at the same time next week for Europeans, and messing Sam about)

  223. dwd

    Ge0rG: Erm. Yes?

  224. SamWhited

    I will most likely be getting off the bus at that time, so I'll be late probably

  225. Ge0rG

    +1

  226. SamWhited

    15:15Z would probably be better, if we could do that.

  227. Kev

    That'd work for me next week.

  228. dwd

    OK, 1515Z then. I'm fine with that.

  229. dwd

    9) AOB

  230. dwd

    Hopefully not because we're coming into Paddington.

  231. Ge0rG

    +1 for 1515Z

  232. Ge0rG

    I wanted to vote on abolishing Pidgin.

  233. dwd

    Ge0rG: Hmmm.

  234. jonasw

    ceterum pidgin delendam esse

  235. jonasw

    *ceterum censeo

  236. dwd

    Assuming none, or at least nothing serious...

  237. dwd

    10) Ite, Meeting Est.

  238. dwd

    Thanks all.

  239. Kev

    Thanks all.

  240. Ge0rG

    I feel cheated now. I was told we can vote on *anything*!

  241. dwd

    (If nobody else is writing minutes, I'll get to them... eventually.)

  242. dwd

    Ge0rG: Yes, but not every vote will have any effect...

  243. Ge0rG

    dwd: sometimes it is purely about the signals we send and not about actual actions.

  244. Ge0rG

    Thanks, though :)

  245. SamWhited

    Motion for all XSF business to be conducted in Latin from now on.

  246. Ge0rG

    Motion to change "Latin" to "Latin-15"

  247. Ge0rG

    Motion to change "Latin" to "Latin-9"

  248. moparisthebest

    utf-16 with a BOM ?

  249. Zash

    Motion to deprecate the letter U

  250. Zash

    No need for U when we have V

  251. moparisthebest

    ooh can you abolish BOMs

  252. Zash

    Don't yov agree?

  253. Kev

    Zash: But we don't have V.

  254. Ge0rG

    Obligatory reference to http://grammar.ccc.commnet.edu/grammar/twain.htm

  255. Kev

    (Welsh doesn't have K, V, X or Z)

  256. SamWhited

    Or vowels, apparently.

  257. Ge0rG

    Now someone needs to make a cheap pun on the pronunciation of I, U and V.

  258. moparisthebest

    but re: starttls discussion I missed pre-meeting, it was 100% the correct way to go at the time, in my opinion

  259. SamWhited

    I love that possibly-Twin thing, I wonder if that was the inspiration for Guy Steel's "Growing a Language" talk (which is fantastic and you should watch it): https://www.youtube.com/watch?v=_ahvzDzKdB0

  260. moparisthebest

    in fact it seems to me IANA basically required it at the time for port assignments and such?

  261. SamWhited

    possibly-Twain, even.

  262. moparisthebest

    and today, it's worse than useless and everything should just be direct TLS, just something that changed meh

  263. Ge0rG

    moparisthebest: STARTTLS always was a dirty hack. It just happened to be the only viable dirty hack for some years

  264. moparisthebest

    yes, the only viable and officially IANA/IETF sanctioned hack

  265. Dave

    I'm actually sitting next to its author now.

  266. Dave

    Chris recently wrote an I-D saying its time was passed, I think.

  267. Zash

    Wait wasn't IETF last week? Or is it now?

  268. Dave

    Now. I'm in the plenary.

  269. Zash

    My sense of time is weird.

  270. Dave

    Started last Saturday, mind.

  271. moparisthebest

    I thought I read that but can't find it now, all I can find is a lone blog post https://www.agwa.name/blog/post/starttls_considered_harmful