XSF Discussion - 2020-01-24


  1. dwd

    Ge0rG, Genuinely, because people seem to get very confused over the idea.

  2. Ge0rG

    dwd: I agree with that, and was just wondering about motivation and about what kind of HPKE you want to enroll

  3. dwd

    Ge0rG, Not entirely sure. HPKE is simple enough that it's relatively easy to build, but has the advantage that we could use the same mechanism based on it for password-based and per-device authentication, since it'll support private keys on both sides, etc. Might be a better/longer-term replacement for SCRAM-SHA-1 than SCRAM-SHA-SOMETHING-ELSE. But I have no clue if there's sufficient eneergy within Kitten to do anything about it.

  4. Ge0rG

    dwd: do you use HPKE as an acronym for the generic combo of symmetric and asymmetric crypto, or for some specific algo/approach?

  5. Ge0rG

    Also I'm not quite sure how that fits into the authentication flow

  6. dwd

    Ge0rG, https://tools.ietf.org/html/draft-irtf-cfrg-hpke-02 and https://github.com/dwd/crypto-examples/blob/master/hpke-demo.py

  7. Ge0rG

    dwd: this is about encryption of data

  8. dwd

    Ge0rG, It is. But I think one could build a SASL mechanism around it, sending an encrypted password and establishing a device private key. AAD with channel binding in, too.

  9. dwd

    In particular, I think you end up with a possibility for a 1-RTT mechanism which has optional per-device keying. But I'm not beyond vague consideration here, I have nothing concrete.

  10. Zash

    How do those password based TLS key agreement things work?

  11. Ge0rG

    dwd: I have a vague feeling about doing such a thing over HPKE or actually any asymmetric sign+encrypt thing, but this is designing a new crypto protocol and I don't really feel confident there

  12. Zash

    PAKE?

  13. dwd

    Ge0rG, Oh, me neither. I'm confident in putting something together and then asking Richard Barnes, though.

  14. dwd

    Zash, Deriving a keypair from a password? As I recall, they're nearly all patented in odd ways.

  15. Ge0rG

    Go north and take it to the mountains?

  16. dwd

    Zash, Although obviously one could just PBKDF-2 -> 25519 or 448 and be done, these days.

  17. Zash

    I was under the impression that this existed in TLS already, but wasn't used

  18. Zash

    Or am I confusing it with pre-shakred static keys?

  19. dwd

    Zash, Oh, password-based TLS? Yes, that exists.

  20. Ge0rG

    pre-shaked keys. I want those.

  21. dwd

    Zash, It's PSK, rather than passwords, but that is again a mere PBKDF-2 away.

  22. dwd

    Ge0rG, Preshaken keys, never prestirred keys.

  23. Zash

    Ge0rG: XEP-0257 ?

  24. dwd

    Zash, IIRC, wetried taking that to th IETF and it died due to lack of interest.

  25. Guus

    "pre-shakred static keys" "pre-shaked keys" "prestirred keys" <-- I'm having trouble determining which of these, if any, are typo's...

  26. Ge0rG

    A shakra is a circular vortex of energy on the spinal column.

  27. Ge0rG

    it only goes downhimm from there.

  28. Guus

    In MAM, what to do, server sided, with queries that contain unsupported data fields? Ignore them (which adds to confusion)? Throw exceptions (which likely breaks clients)?

  29. MattJ

    I'd fail with an error

  30. MattJ

    You can't break what's already broken :)

  31. MattJ

    and if the client is expecting you to do some filtering that you're not going to do, providing a response is likely to also break it, just in more subtle ways

  32. Guus

    true

  33. MattJ

    All but the core fields should be discovered before use, the XEP is clear about that

  34. dwd

    Guus, I agree with MattJ - silently ignoring it is unlikely to do whatever the client was trying to do.

  35. Guus

    already putting the code in.

  36. ralphm

    Well, arguably, the client is trying to do the wrong thing if it is sending unsupported fields.

  37. Zash

    But what about including the fields but no values . ..

  38. Guus

    semantically, the client doesn't want to use those, right?

  39. Guus

    so, ignore them?

  40. ralphm

    In the general sense, ignoring unknown things has always been to go-to approach. Why would this be different, dwd?

  41. ralphm

    (or MattJ)

  42. MattJ

    Ignoring things isn't always the best approach, even if it is often done

  43. MattJ

    In this case it is demonstrably bad

  44. MattJ

    It's one thing to ignore stuff that you are passing through/routing

  45. MattJ

    But if someone sends you a query with stuff you don't understand, you can't be sure you are properly answering their query

  46. ralphm

    But the client shouldn't be sending that stuff to begin with?

  47. dwd

    ralphm, We ignore unknown things because the protocols are designed that way. With this case, we have an explicit discovery step that the client is missing - it'd be like sending an unknown IQ, therefore, not like additional elements within a message.

  48. ralphm

    fair

  49. Kev

    I don't think I'd blame an implementation for ignoring them, but I think error is probably preferable.

  50. MattJ

    I can't help but read that as "the implementation I wrote ignores them, but an error is probably preferable" ;)

  51. Kev

    TBH, I've no idea what we do :)

  52. MattJ

    (fwiw Prosody probably ignores them)

  53. MattJ

    Obviously the fault lies with the client, it's just a question of how easy we make it for client devs to debug what's wrong

  54. Kev

    I think if I was implementing it, I would make it ignore them, because that'd be the default without writing extra code and thinking about it.

  55. Guus

    Openfire now throws errors on non-empty, unrecognized fields.

  56. Kev

    Empty fields is another bundle of joy.

  57. pep.

    maybe we should add in xep guidelines "specify what to do with empty fields" (consider them as .. or sth)

  58. dwd

    What time do we think we'll get to Cisco on Thursday? 09:30 start?

  59. Guus

    I think we previously did 10.

  60. Guus

    last year, I traveled on Thursday morning. 10 was tight.

  61. Guus

    This year, I'll be in Brussels on Wednesday though, so it doesn't matter much to me.

  62. Zash

    Ejabberd returns errors if you include whit/start/end fields without values in the query and I was very confused about this until recently

  63. ralphm

    Might be good to ask for more agenda items. Thanks nyco for adding a bunch.

  64. Guus

    I just did ask, in summit@

  65. dwd

    I have bought a load of post-its, marker pens, and dot stickers, so it's not too critical (though it's nice if people think in advance).

  66. Zash

    Gone trough the meeting introspection notes from previous years? :)

  67. Daniel

    nyco: '... Xabbers approach seems good' do you have a link to that approach?

  68. nyco

    they are translating their XEP

  69. ralphm

    Everyone: If you are coming to the Summit, but haven't added your name to https://wiki.xmpp.org/web/Conferences/Summit_24, please do!

  70. dwd

    ralphm, Guus - might be good to put the venue details on there too.

  71. dwd

    Oh, they are now, sorry!

  72. pep.

    nyco: just realized we haven't sent yesterday's minutes. I can't now, can you have a look? otherwise I'll do that tonight

  73. nyco

    sorry, no time, and moreover I did not follow correctly the meeting