XMPP Council - 2017-01-25

  1. moparisthebest

    I figured I should show up for this council meeting since you'll be discussing advancing XEP-0368, I'll just stay quiet unless someone highlights me :)

  2. Tobias

    seems it's about time

  3. Tobias

    1) Roll call

  4. daniel


  5. Dave Cridland

    Here, but not be for long.

  6. Dave Cridland

    (Daughter has a doctor's appt)

  7. Tobias

    Link Mauve, SamWhited?

  8. Tobias

    maybe they'll join later

  9. Tobias

    2) Minute taker

  10. Tobias

    I offer to do it, if nobody else wants

  11. Link Mauve

    I’m here.

  12. daniel

    i was just about to say that it's my turn again. but I can do it next time

  13. daniel

    oh no actually I can't because i'm probably going to be on a train to brussels

  14. Tobias

    ok..last week we didn't clearly indicate that we wanted to vote on things..so here explitily again

  15. Tobias

    3) Voting to Advance XEP-0333 to Last Call

  16. SamWhited

    Sorry, here

  17. Tobias


  18. daniel


  19. SamWhited


  20. Link Mauve


  21. Tobias

    Dave Cridland, still there?

  22. Dave Cridland

    Yes, sorry. +1.

  23. Tobias


  24. Tobias

    4) Voting to Advance XEP-0233 to Last Call

  25. Tobias


  26. daniel

    on list

  27. Dave Cridland


  28. Dave Cridland

    Still confused as to why Mili Verma's not listed as an author, mind.

  29. Link Mauve

    On list too, I started reading the referenced specifications but I still don’t grasp all of the mechanisms there.

  30. SamWhited

    +1; Mind you, I don't feel that I have enough knowledge of Kerberos to know if this is a valid way to do things, or if it's used anywhere or if there have been deployment issues, etc. but I figure that's what LC is for.

  31. Dave Cridland

    SamWhited, Mili's edits basically were in response to developing this on WIndows and UNIX.

  32. Dave Cridland

    SamWhited, So I think it's well past ready.

  33. Tobias

    5) Voting on moving XEP-0368 forward (issuing LC)

  34. Link Mauve


  35. Tobias


  36. daniel


  37. SamWhited


  38. Dave Cridland


  39. Tobias

    6) Short update on XEP-0300 fixing

  40. Tobias

    I've updated XEP-0300 https://github.com/xsf/xeps/commit/2f21fbef22d484d1651596aeb279b3386398c183 would be nice if people could give a quick overview sometime if they see issues with that, if not we can issue an LC to move that to draft in a couple weeks

  41. Tobias

    7) Voting on moving 2010 compliance suites to obsolete to prevent confusion while we work on the 2017 ones

  42. Tobias


  43. SamWhited


  44. daniel


  45. SamWhited

    for background, I plan on writing the 2017 ones on the flight to Brussels and withdrawing the 2016 ones

  46. Link Mauve

    I’ve read it earlier, I was wondering whether making sha3-256 and blake2b-256 mandatory is that sensible before every crypto library is well updated to support them.

  47. Link Mauve

    Re: 6)

  48. Link Mauve

    Tobias, +1.

  49. Link Mauve

    Tobias, also obsoleting the 2012 ones.

  50. Dave Cridland


  51. SamWhited

    Oh are there 2012 ones too? Yah, +1 to obsoleting both of them.

  52. Dave Cridland

    I don't really care, but I'm not sure it's worth the effort.

  53. Dave Cridland

    But absolutely not a hill for me to die on.

  54. Tobias

    Link Mauve, something for the next meeting to vote on then...don't want the topics/voting issues to change mid-meeting, especially not mid-voting

  55. Link Mauve


  56. Tobias

    8) Date of next

  57. Tobias

    Does next week work for everyone, or do we want to skip a week?

  58. Link Mauve

    I won’t be here next week, I’ll be on the train to Brussels.

  59. Dave Cridland

    I'm not here next week.

  60. daniel

    i have to check my train schedule again. but i'm fairly certain i'm on a train at 1600Z

  61. SamWhited

    We could have a small impromptu meeting a little bit later in the day next week

  62. Dave Cridland

    I'll be driving to Bristol. To take a plane to Amsterdam. To take a train to Brussels.

  63. SamWhited

    Or on the 2nd

  64. Tobias

    right, so it'll probably make sense to skip a week

  65. Dave Cridland

    How many of us are in Brussels on Thursday?

  66. daniel

    either move it back a couple of hours or skip it

  67. daniel

    Thursdays yes. also wednesday

  68. Tobias

    Dave Cridland, i guess everyone

  69. Dave Cridland

    We have had a Council meeting in the Summit before, could be fun to do again - might get someone else to take minutes.

  70. Link Mauve

    Finally! \o/

  71. SamWhited

    Find a pub and rope someone in to take minutes with the promise that I'll buy them a beer :)

  72. Tobias

    sure..so sometime thursdays next week?

  73. Link Mauve


  74. daniel


  75. Tobias

    great...even if we fail to arrange it, there'll still be a week afterwards :)

  76. Tobias

    9) AOB

  77. Tobias

    doesn't look like it

  78. Tobias bangs the gavel

  79. SamWhited


  80. Tobias

    thanks everyone

  81. daniel

    thank you

  82. Link Mauve

    Thank you.

  83. SamWhited

    Tobias: RE 0300, I had the same thought as Link Mauve — how wide spread is sha3? I know the Go standard library has an implementation, but it tends to be ahead of other things. Eg. does Java have one? I don't think Rust does yet (not that that's very relavant, but it's the only other thing I really pay attention too)

  84. Tobias

    Link Mauve, what environments do you know of with bad sha3 support?

  85. Link Mauve

    None actually, but probably older openssl don’t have it yet.

  86. Tobias

    for anything C/C++ related it's probably a little issue as there's ready to use reference impementation code for sha3 and blake

  87. SamWhited

    Does stable Debian OpenSSL?

  88. Zash

    OpenSSL doesn't

  89. Zash

    There's code, but it's not exposed

  90. Tobias

    recent openssl has blake, they should have sha3 too, not?

  91. SamWhited

    Oh hey, I lied, Rust has sha3 in the standard library already.

  92. Tobias

    bouncycastle also has SHA3

  93. SamWhited

    or rather, it has an implementation already.

  94. Link Mauve

    OpenSSL apparently still doesn’t have it, according to https://github.com/openssl/openssl/issues/439

  95. SamWhited

    Personally I think it would be good to leave it as a SHOULD at least until OpenSSL has it.

  96. Tobias

    Oracle Java seems to have it since, earlier this month https://bugs.openjdk.java.net/browse/JDK-8004078 ^^

  97. Zash

    There's a keccak1600.c in the sources, however it's not used by anything

  98. Link Mauve

    daniel, any information about Android?

  99. daniel

    Link Mauve, not from the top of my head

  100. SamWhited

    If bouncy castle has it would it not work on Android?

  101. daniel

    SamWhited, if bc has it everything is fine

  102. Link Mauve


  103. Link Mauve

    Fyi, Python got both sha3 and blake2 only in 3.6.

  104. Tobias

    also the idea was having multiple algorithms set to MUST, so implementations strive to support as many of the MUST ones as possible...the it's more likely that there is matching support between two entities

  105. Link Mauve

    I’m not against it, I was just wondering whether it wouldn’t be a bit too early.

  106. Tobias

    Link Mauve, considering how rarely we seem to have updated XEP-0300 the idea was to make it more future proof :) but happy either way...but we should at least aggree on it before voting on it to LC

  107. SamWhited

    Hmm, I could go either way now. Future proof sounds good; I wouldn't want to block either way.

  108. Link Mauve

    Same, I’m fine with LC as is.

  109. Zash

    Isn't there some RFC / BCP you can point to for recommendations, so we don't need to update it as best practices change?

  110. Tobias

    great...also added a table for the textual names of the new hashes...IANA is a bit slow there, as their table was last updated 2006

  111. Tobias

    Zash, i don't know of one

  112. Tobias

    Zash, I imagine the TLS spec has hash recommendations

  113. Tobias

    Zash, then again, RFCs don't get updated..only replaced by other RFCs