XMPP Council - 2012-08-15

  1. m&m

    T - ~5 minutes

  2. stpeter


  3. m&m


  4. m&m


  5. stpeter

    you need last message correction!

  6. m&m

    I was testing you all

  7. m&m


  8. stpeter

    a use case!

  9. stpeter

    I really really need to spend some quality time with XEP-0301 again

  10. m&m

    I think there needs to be a lock-down on 301 updates for a week or two

  11. stpeter


  12. ralphm

    i'm about to set up a filter

  13. stpeter

    'tis time?

  14. ralphm


  15. Kev

    It is.

  16. Kev

    1) Roll call

  17. Kev

    MattJ sends apologies.

  18. ralphm


  19. m&m


  20. m&m


  21. ralphm

    it's getting old quickly now^Uhaha

  22. Kev

    Tobias: ?

  23. m&m

    It's just getting started

  24. Tobias


  25. m&m

    s/it's just getting started/indeed/

  26. Kev


  27. Kev

    2) Matt's IETF report.

  28. m&m


  29. m&m

    2.1) E2E — still progressing, mostly in JOSE not XMPP directly

  30. m&m

    by the way, if anyone is interested in a solution here, I would recommend joining the jose@ietf.org mailer and commenting on any non-OpenId use cases

  31. m&m

    2.2) DNA — Stpeter and I wrote up a series of drafts for domain name associations (formerly assertions)

  32. m&m

    they are light on examples, and there is desire for more guidelines; which to do first, signaling preferences, etc

  33. m&m

    also includes prooftypes using DNSSEC/DANE and POSH

  34. stpeter

    POSH being "PKIX over Secure HTTP" -- basically parking your certificate at a well-known URI

  35. m&m

    thank you

  36. m&m

    2.3) 6122bis — mostly waiting on PRECIS, but there are some changes to processing order, and what to do with certain classes of code points (e.g. full- and half-width)

  37. ralphm

    to be sure, this is the certificate proving that a host may act for a particular domain, right?

  38. m&m

    ralphm: yes, by virtue of HTTPS 30x redirects

  39. m&m

    request https://mydomain.com/.well-known/posh._xmpp-client._tcp.cer , get redirected to https://thathostingcomany.net/.well-known/posh._xmpp-client._tcp.cer

  40. m&m

    DNSSEC is our existing SRV lookups, but with the expectation the record(s) are signed (valid)

  41. Kev

    Oh, that's a bit icky isn't it?

  42. m&m

    Kev: it's not perfect, but it is deployable

  43. Kev

    Requiring people not just to know how to get to the final resource, but also to keep track of how HTTP panned out getting there, I mean.

  44. Kev

    Well-known-URIs are themselves icky, but I can hold my nose for that.

  45. m&m

    most HTTP libraries will let you know when a redirect is followed, and how

  46. Kev

    Does this allow more than one jump?

  47. m&m

    that right now is not specified … it could, and we'll probably need to put some limits around it

  48. Kev

    I've got a feeling of general unease about redirects and proofs, because you need to keep track of cert trust at each hop and blah.

  49. ralphm

    indeed. There have been issues with this in other protocols

  50. m&m

    Kev: alternate suggestions welcome

  51. Kev

    Not that this is a deal-breaker, I just enter it with trepidation.

  52. m&m

    so do most of us

  53. m&m


  54. m&m

    it's at least something that could get implemented and deployed before universal IPv6

  55. stpeter

    well, universal DNSSEC

  56. stpeter

    (and DANE)

  57. Kev

    xmpp:jabber.org has IPv6.

  58. m&m

    I assert that universal DNSSEC will happen just after universal IPv6

  59. Kev

    Anyone using HE can't route to it...

  60. m&m

    Kev: that's not universal

  61. m&m


  62. m&m

    POSH is one possible approach, DNSSEC/DANE is another

  63. m&m

    both have the potential to make dialback even more relevant than before

  64. Kev

    OK. I need to use my time machine to create some more time to look at this better.

  65. m&m

    Kev: I know exactly what you mean (-:

  66. Kev

    Was that the IETF report done with?

  67. ralphm

    Kev: go back further and tell those IPv4 people to do it right

  68. Kev

    ralphm: I think the IPv4 people /did/ do it right.

  69. Kev

    IPv6 is much more contentious.

  70. m&m

    re IETF report — there's probably some things happening in PRECIS that are relevant to us also

  71. m&m


  72. ralphm

    Kev: point

  73. m&m finds link

  74. m&m


  75. m&m

    this is a draft for using XMPP pubsub for propagating layer-3 VPN information

  76. ralphm


  77. Kev

    Oh, neato.

  78. m&m

    well, it's a lot of things, but XMPP is in there

  79. m&m

    they do need some help, though

  80. Kev

    Maybe this XMPP lark will take off.

  81. m&m

    HTTP(s) is the One True Protocol™

  82. m&m

    anyway, I would recommend those enthusiastic about pubsub to read that draft ...

  83. ralphm

    oh collection nodes

  84. m&m

    … and contact Pedro Marques <roque@contrailsystems.com> with corrections, suggestions, questions, etc

  85. m&m

    ralphm: yeah, although I don't think they actually need them for what they are doing

  86. ralphm

    m&m: pretty unlikely

  87. m&m

    Also, anyone interested in end-to-end encryption and signing should pay attention to JOSE

  88. m&m

    and that is all

  89. Kev

    Perhaps if I didn't lose the best part of a day to dealing with DDoS attacks I'd have time for this.

  90. Kev


  91. Kev

    OK, thanks Matt.

  92. stpeter


  93. Kev

    3) Date of next meeting.

  94. m&m


  95. Kev

    We'll have 308's LC ended by next Wednesday, so we should have something to discuss...

  96. m&m


  97. Kev

    SBTSBC works for me, I think.

  98. Tobias


  99. ralphm


  100. Kev


  101. Kev

    4) Any other business?

  102. m&m

    not for me

  103. Kev

    OK, we're done then.

  104. Kev

    Thanks all

  105. Kev bangs the gavel.

  106. stpeter

    yes, thanks

  107. m&m


  108. ralphm