XSF Discussion - 2016-01-21

  1. Link Mauve

    Flow, what’s the rationale for having moved everything out of signcrypt, in OX?

  2. Flow

    Link Mauve: please define "everything" :)

  3. Link Mauve

    Err, not out, more like moved the attributes to elements.

  4. Flow

    ahh I assumed that is what you meant

  5. Flow

    short answer: because you can't have multiple attributes with the same name

  6. Link Mauve

    And you want to, in this case?

  7. Flow

    and we want to be able to specify multiple recipients

  8. Flow

    so the initial idea was to <signcrypt to='foo@bar.com' to='baz@bar.com'>

  9. Flow

    but that's not valid xml

  10. Flow

    so now we have <signcrypt ...><to .../><to .../>...

  11. Link Mauve

    Oh, the <to/> are there to list every recipient that can decrypt?

  12. Flow

    Link Mauve: Yes "OpenPGP content elements MUST possess at least one 'to' ..." and "The 'to' element(s) MUST have a 'jid' attribute which contains the intended recipient's XMPP address..."

  13. Link Mauve

    s/recipient's/recipients'/ then.

  14. Flow

    RFC 4880 already allows multiple recipients and there is no reasion to restrict an OX OpenPGP content element to one

  15. Link Mauve

    So should there always be a <to/> for yourself?

  16. Link Mauve


  17. Flow

    Link Mauve: I don't think so

  18. Flow

    The encrypt to self is to allow users to read their own send messages

  19. Flow

    The <to/> in OpenPGP content elements is there to prevent attacks where the message is send by an attacker to a third party

  20. Flow

    which was not the intended recipient in the first place

  21. Link Mauve

    It might be useful to define what to do if you (the recipient) don’t match any of the <to/>.

  22. Flow

    Link Mauve: I think what we have in OX § 3.2 is sufficient right now

  23. Flow

    You can't specify what an implementation should to if the verification fails

  24. Flow

    If I wouild ask you what you plan to do in profanity, and then I would ask daniel what he plans to do in conversations, I would likely get two different answers.

  25. Link Mauve

    poezio* :)

  26. Link Mauve

    Actually, just slixmpp for now.

  27. Flow

    Link Mauve: Uhh, sorry.

  28. Flow

    Isn't the profanity dev also here?

  29. Link Mauve

    I know the mcabber dev is here, coucou McKael.

  30. Link Mauve

    Also the primitivus dev is here, coucou goffi.

  31. Flow

    Link Mauve: Are you going to the Summit/FOSDEM?

  32. Link Mauve

    Sure. :)

  33. Link Mauve

    Will miss the first morning of Summit though. :(

  34. goffi

    I need to check this OX stuff, it can be interesting for our private blog feature

  35. mathieui

    afaik the profanity dev is boothj5, and he’s not here

  36. Ge0rG

    am I reading OX right, that the <openpgp> element contains base64-encoded xml elements?

  37. Flow

    Ge0rG: no base64 encoded RFC 4880 messages which contain an encrypted and/or signed UTF-8 string which contains XML.

  38. Flow


  39. Ge0rG

    maybe section 3 should more clearly state that, and provide a rationale

  40. Flow

    a rationale for?

  41. Ge0rG

    a rationale for putting base64-encoded xml into xml.

  42. Flow

    But that's not the case

  43. Ge0rG

    besides, there is no format specification in section 3, and only a brief examle of one of the three use cases

  44. Flow

    I admit that § 3.1 format specification is not very well written, but it is there: "The text content <openpgp/> (BASE64_OPENPGP_MESSAGE) is a Base64 encoded, as specified in RFC 4648 [3] § 4, OpenPGP message which contains an encrypted and/or signed UTF-8 encoded string. Note that OpenPGP's ASCII armor is not used, instead the XMPP client MUST encode the raw OpenPGP message, as specified in RFC 4880 [4], using Base64. This string MUST represent exactly one OpenPGP content element, that is either a <signcrypt/>, a <sign/> or a <crypt/> extension element qualified by the 'urn:xmpp:openpgp:0' namespace."

  45. Ge0rG

    also why use base64 over ascii armor?

  46. Flow

    because we encode the OpenPGP message

  47. Ge0rG

    "This string MUST represent ..." maybe "correspond to" would be a better wording.

  48. Ge0rG

    the OpenPGP message format also encodes whether it's a signed/encrypted message and which key-ids it is encrypted for. Why is this data duplicated inside?

  49. Flow

    key-ids != jids

  50. Zash


  51. Zash

    Ge0rG: I thougt "ascii armor" was base64?

  52. moparisthebest

    Ge0rG, it looks like base64 is used INSTEAD of ascii armor, not over it?

  53. Ge0rG

    moparisthebest: that's what I intended to say

  54. Flow

    and as for <signcrypt/>, <sign/> and <crypt>, for one, it is a fail safe, if an implementation constructs a <signcrypt/> message, because it wants to send a signed and encrtyped message, but only encrypts it using OpenPGP

  55. Ge0rG

    Zash: yes, but with dashes and headers added.

  56. moparisthebest

    oh so is it the same as the old spec? ascii armor stripped of whitespace and headers?

  57. Ge0rG

    Flow: how should a client receiving such a failed message behave?

  58. Flow

    Ge0rG: What woud you suggest?

  59. moparisthebest


  60. Flow

    atomic ones?

  61. moparisthebest

    I was thinking more firecracker-like

  62. Flow

    uhh :(

  63. Flow

    Ge0rG: Link Mauve asked a similar question just before you today. I don't have an answer other then "it should consider the message as unverified", and I don't think a spec should specify what a client should/must do if a message is unverified.

  64. Zash

    Light the thermite failsafe device

  65. moparisthebest

    clients don't do nearly the same with with current pgp if decryption fails, I was messing around with this yesterday with a command-line pgp-capable sendxmpp command

  66. Flow

    moparisthebest: "don't do nearly the same"?

  67. moparisthebest

    conversations displays "can't decrypt, maybe you don't have the right private key?" even when 'encrypted content' is 'bla'

  68. moparisthebest

    and gajim sometimes displays the content of <body>, and sometimes shows no indication of having received a message at all

  69. Flow


  70. moparisthebest

    Flow, I'm saying they aren't consistent in what they do when receiving bad pgp encrypted messages

  71. moparisthebest

    it would be nice if they were somewhat consistent though, I don't like gajim just dropping messages silently

  72. moparisthebest

    you probably don't want to specify what exactly they should say, maybe you could just specify they should inform the user in some way?

  73. Ge0rG

    what about sending an error back?

  74. Ge0rG

    though what do you do if a client (of multiple) just doesn't have the right key?

  75. Ge0rG

    Flow: by not having the redundancy, one could prevent the existence of these border cases.

  76. Flow

    Ge0rG: error as response of a presence has the potential for a presence leak, but if you check before sending that the entity has access to your presence anyway, then yes why not

  77. moparisthebest

    and they could *get* the key later, due to the nature of pgp

  78. moparisthebest

    like I set up conversations on a new phone and haven't set up openkeychain yet

  79. Ge0rG

    sending an error as a response to a malformed message doesn't seem too far-reached

  80. moparisthebest

    and do you still send the error back when you are retrieving with MAM ?

  81. Flow

    Ge0rG: I think a bad programmer is more likely to be able to construct an XML string prefixed with <signcrypt/>, <crypt/> and <sign/> then to use a OpenPGP library correctly

  82. moparisthebest

    or do all your devices receiving the carbon send messages?

  83. Flow

    So it's not about removinga border case, but about having a fail safe for this case

  84. moparisthebest

    there might be a difference to what you do if you don't have a key vs not-pgp, I'm not sure it'd be a problem outside of development

  85. Ge0rG

    Flow: I think that adding this redundancy creates the border cases in the first place

  86. Ge0rG

    "in the range of tenth of kilobytes" --> "in the range of tens of kilobytes" I suppose

  87. Ge0rG

    the timestamp is redundant as well.

  88. Flow


  89. Ge0rG

    so a client may receive a message with three (different) timestamps. XEP-203, openpgp and <time>

  90. Ge0rG

    which one do you display?

  91. Flow

    I would display <time>

  92. xnyhps

    Ge0rG: And possibly timestamps added by multiple different servers. ;)

  93. Flow

    xnyhps: Which remindes me, I wanted to reply to your latest mail on standards@

  94. xnyhps

    Timestamps are quite messy because it's not easy to say who to trust in general.

  95. Flow

    I'd be interested in persuing the added:by approach

  96. Flow

    And from what I can read, daniel too

  97. Flow

    I'd like to hear from some more server guys what they think about it

  98. Flow

    I believe most of the business rules from xep359 could go into the added:by xep

  99. xnyhps

    Flow: Some of them, yeah

  100. xnyhps

    Still not sure the complexity is really worth it.

  101. Flow

    xnyhps: That's basically why I didn't replly initially

  102. xnyhps

    My main reason was that the things the server strips might have changed between when the message was originally sent and when the client received it (from MAM), but as long as servers also strip messages outgoing on MAM that's not a problem.

  103. Link Mauve

    Flow, might be useful to add a section about what to do if there are e.g. both an openpgp and a body element in a message or presence (iq obviously can’t have that).

  104. Flow

    Link Mauve: Hmmm, undecided, I personally don't think it is necessary

  105. Flow

    but patches welcome :)

  106. Flow

    XMPP-IM neither specifies what to do when a message with two <body/> arrives

  107. Flow

    (or maybe it does and I don't remember)

  108. Ge0rG

    Flow: "For example, direct child elements found in either <signcrypt/>, <sign/> and <crypt/> could be: " <- shouldn't that read "For example, <payload/> child elements..."?

  109. Flow

    Ge0rG: Thanks, that is a leftover from the attribute to elements migration

  110. Flow

    fixing right now

  111. Ge0rG

    Flow: also s/my/by/ in the §8.3 text

  112. Flow


  113. Ge0rG

    Flow: the link from §6.1 to http://tools.ietf.org/html/rfc4880#section-5.5.2 talks about key packets, not about message formats

  114. Ge0rG

    I hope I didn't kill the OX thread with my long response.

  115. Link Mauve

    Given the date, I’d even say the opposite. :)

  116. Ge0rG

    Link Mauve: oh, right. I've been on holiday and missed it. Just found the time to read up, and the messages all were "new" to me

  117. Flow

    Ge0rG: it's just an example of packets where v4 must be used. The most important one, but just an example