XSF Discussion - 2015-10-27

  1. goffi

    g'day

  2. Flow

    hi goffi :)

  3. andy

    Flow, yeah, that's pretty much the idea behind KeyTransportElement. It should be super easy to extend/reuse OMEMO-core to encrypt whatever the user may want. We're thinking about also writing a spec for this

  4. Flow

    andy: that's what I thought. btw I see that "messageelement" is explained in means of terms and used in 4.5, but it's nowhere stated what it is in terms of XML. Is it the 'encrypted' element qualified by the omemo namespace?

  5. andy

    Flow, yes. 4.5 states "This is all serialized into a MessageElement, which is transmitted in a <message> as follows:" with the example right after it. Should I make this more explicit somehow?

  6. andy

    Maybe include the term MessageElement in the name of the example or something?

  7. Flow

    andy: examples are not normative

  8. andy

    Flow, ah, I see what you mean.

  9. Flow

    And I'd consider s/MessageElement/EncryptElement/

  10. andy

    Well one could infer its XML structure from the schema, given the information from the glossary description mentioning it's an OMEMO element, which itself is an <encrypted/> element in the omemo NS, and that it has a <payload/>

  11. Flow

    <encrypted/> element: An OMEMO element that contains encrypted data. Its <payload/> element contains human readable text, similar to a message stanza's body element.

  12. Flow

    andy: Sure, I'm just suggesting what could be improved

  13. andy

    Yes, I understand

  14. Flow

    And right now, I'm missing an explicit statement what a MessageElement is

  15. andy

    The problem with that approach is that a KeyTransportElement is also contained in an <encrypted/> element, so I think calling it EncryptElement would lead to confusion

  16. Flow

    I also think that MessageElement is not a good name. I would simply refer to it as "<encrypted/> element" in text. That is was most XEPs do in similar cases.

  17. Flow

    Also the statement that it contains a chat message is wrong, if you want to extend it at some point

  18. andy

    How is it wrong? MessageElements are defined as containing chat messages. That's their explicit purpose

  19. andy

    For anything else, there's KeyTransportElement

  20. Flow

    Well depends on how you define MessageElement

  21. andy

    True

  22. andy

    I'm talking about the current definition

  23. Flow

    but such an definition is missing

  24. andy

    It's all mentioned in the glossary, no?

  25. Flow

    If you say: MessageElement is an <encrypted/> with <payload/> then yes

  26. Flow

    andy: Not really no

  27. andy

    OMEMO element -> An <encrypted> element in the urn:xmpp:omemo:0 namespace. Can be either MessageElement or a KeyTransportElement MessageElement -> An OMEMO element that contains a chat message. Its <payload>, when decrypted, corresponds to a <message>'s <body>. KeyTransportElement -> An OMEMO element that does not have a <payload>. It contains a fresh encryption key, which can be used for purposes external to this XEP. Bundle

  28. andy

    so a Message element is an <encrypted/> element in the omemo ns, which has a <payload/> that contains the chat message

  29. andy

    Maybe I'm missing something because I've been working with this stuff for months, but that seems pretty clear to me?

  30. andy

    oh, and ignore that stray 'Bundle' at the end there. copy/paste fail :X

  31. Flow

    andy: It's not crystal clear for someone new to OMEMO as it could be.

  32. Flow

    Neither the schema nor the examples are considered normative in XEPs

  33. Flow

    So you should write something like "a MessageElement is a <encrypted/> element which MUST posses a <payload/> containing the encrypted chat message".

  34. Flow

    I think MessageElement MUST also have a <header/> which at leat one </key> at at most one <iv/>

  35. Flow

    exactly one <iv/>

  36. andy

    Okay. I actually didn't know the schema wasn't normative. I'll make the definitions clear in the text then

  37. andy

    Thanks.

  38. Flow

    andy: Although it's not that of an issue, I did understand what you meant when I was first reading the XEP a few weeks ago, I now wondered e.g. what exactly an message element is. I didn't found an answer in the text (while the examples and the schema provide a good idea of what it is).

  39. andy

    Flow, I understand. I appreciate the opinion of a fresh pair of eyes. After you've been working on something for quite a while, a lot of things just seem obvious to you, that might confuse people that are new to the matter

  40. Flow

    andy: another question, what' is the value of a <key/> element in a MessageElement? The encrypted key for the <payload/> encrypted with the rid devices pubkey?

  41. andy

    Precisely

  42. andy

    Or rather, it's not encrypted with the rid pubkey

  43. andy

    it's encrypted in the long-standing axolotl session with the rid device

  44. Flow

    valueable information that should go into the xep

  45. Flow

    and what's the value in case of a KeyTransportElement?

  46. andy

    Flow, would you say it's preferable to explicitly state these things a) in the glossary, b) in the section where it's used, c) both ?

  47. Flow

    I'd say never do c) and in this case I would go with b)

  48. andy

    Okay

  49. Flow

    The glossary is mostly to introduce terms maybe unknown to readers and to give them a quick idea about what the term is about.

  50. andy

    I see. I guess I've been treating it more like a place to dump definitions

  51. andy

    But that makes sense

  52. andy

    In a KeyTransportElement, the <key/> is a fresh, unused key, again encrypted with the sid<->rid session

  53. andy

    I guess I'll move these definitions into the relevant sections and expand a bit on them

  54. andy

    Flow, how do you like this: "This is all serialized into a MessageElement. The MessageElement consists of an <encrypted/> element in the urn:xmpp:omemo:0 namespace, which MUST contain a <header> element and a <payload/> element. The <payload/> element contains the encrypted chat message's <body/>. The <header/> element is tagged with an sid attribute and MUST contain one <iv/> element, containing the common IV used to encrypt the <payload/>. It also contains one <key/> element for each recipient, of which there MUST be at least one. The <key/> elements are each tagged with an rid attribute, and contain the key used to encrypt the <payload/> which is encrypted using the long-standing session the sender shares with the recipient's device corresponding to the rid." ?

  55. Flow

    andy: better. :) You should mention that the data is base64 encoded. I also don't like "contain the message's <body/>" element.

  56. Flow

    I did not like "correspondents to <body/>" too. I know what you are trying to tell here. I would simply re-use the definition of the body element here.

  57. andy

    okay

  58. Flow

    It is certainly not the message's <body/> element, because <payload/> only provides a subset of the features the <body/> element provides.

  59. andy

    Yes, I wasn't very happy with that either

  60. andy

    You're right

  61. Flow

    Also it is unclear what should happen if a message stanza has a <encrypted/>+<payload/> and a <body/> element

  62. Flow

    so re using the definition from rfc 6121 5.2.3: the <payload/> element contains encrypted human-readable XML character data.

  63. andy

    Done. Also added to the Sending a key section: "This is all serialized into a KeyTransportElement. The KeyTransportElement is defined analogously to the MessageElement, but it MUST NOT contain a <payload>. The encrypted key contained in the <key/> elements is thus unused and can be used by other protocols."

  64. andy

    Is that clear enough? I don't think it'd be a good idea to repeat the entire definition

  65. Flow

    andy: It's fine by me. I just wanted to make sure that the <key/> element never holds two different types of keys, .e.g pub and private key.

  66. andy

    Ah. Maybe I should explicitly mention that they're 128-bit symmetric keys.

  67. andy

    Or maybe it would be better to make that a minimum, rather than a fixed size. I had actually been thinking about this before. How to make sure this is a flexible as possible without adding a complex request-response type of negotiation...

  68. Flow

    andy: doesn't this mostly depend on axolotl?

  69. Flow

    At one point in the future OMEMO may need to negotiate the axolotl version used.

  70. andy

    Flow, I am referring to the payload key. That's pretty much independent from axolotl, as axolotl is only used to encrypt the key itself. But we can of course choose whatever key we want to put in there

  71. andy

    At the moment, OMEMO uses 128bit AES-GCM for payload encryption, and thus the keys are 128 bit

  72. Flow

    ahh

  73. Flow

    right

  74. andy

    But since the KeyTransportElement is/should be independent of the encryption OMEMO uses for its chat messages, we should think about making this "extensible"

  75. Flow

    andy: question is, does is need to be negotible?

  76. Flow

    or would <payload mode='aes-gcm-256'> be sufficent?

  77. andy

    I *really* don't want it to be. Negotiation is kind of a pain to do

  78. andy

    Well as far as I'm aware, GCM is currently only specified for 128bit block ciphers. And switching away from an AEAD mode would bring a lot of extra complications. So I don't feel too badly about fixing the payload encryption to this one specific cipher/mode combinations

  79. Flow

    Right, but you should prepare that devices may want to announce that they support $cipher in case aes-gcm-128 became insecure

  80. andy

    In that case we would probably want to bump the namespace version I think?

  81. Flow

    not sure, I would maybe simply have devices announce what they support additionally to aes-gcm-128, and add a optional mode attribute to <encrypted/>

  82. Flow

    But I'd like to hear what zash and thjis say about this

  83. andy

    My main concern at this point is that I don't want to limit extension protocols (e.g. if somebody decides to spec full-stanza encryption based on OMEMO) to this certain block size, which is why I was thinking about mandating that implementations provide a minimum of 128bit keys. That way if somebody wants to do aes-ctr/hmac-sha-3 encrypt-then-authenticate or whatever, they can.

  84. andy

    Flow, well the problem I see with that is that it's much more complicated than just simple "i can also do aes-ctr 256", because that's not authenticated encryption anymore. Which means you'd have to also specify integrity protection, which involves a KDF and a MAC. And at that point you're kinda negotiating complex cipher suites, which would need to be well-defined ahead of time, etc...

  85. Flow

    assuming the sender wants authenticated encryption

  86. andy

    And I guess you'd want to put that information into PEP, rather than transmit it in-band

  87. Flow

    the capabilities in pep, of course. but what's actually used within <encrypted/>

  88. andy

    You pretty much never don't want authenticated encryption if you know what you're doing [citation needed]

  89. SamWhited tries to think of a use case for that... one probably exists, just not likely in chat.

  90. Flow

    I won't argue with that :)

  91. andy

    You also don't want your users having to worry about what encryption is used in the back end, especially if different ciphers may have not just different strengths but also different kinds of security guarantees...

  92. andy

    So you would have to define some sort of prioritization list or something... It just gets kinda ugly

  93. Flow

    My point was that you may want to provide an upgrade path regarding the used encryption method in OMEMO that doesn't require an namespace bump.

  94. andy

    I mean crypto agility is nice, don't get me wrong. I just don't really think the benefits are worth the cost in this scenario

  95. SamWhited

    Tying it to a namespace bump seems clean to me. It gives you a nice guarantee that you'll definitely be able to talk to the other client, no matter what.

  96. SamWhited

    (assuming you both support the same namespace)

  97. andy

    Yeah, I don't really have a problem with the idea that a specific protocol version is tied to one specific cipher suite

  98. andy

    If people really do have special needs regarding the cipher usage, they can always extend the protocol

  99. Flow

    So devices need to register to multiple PEP nodes if we have multiple OMEMO namespaces. Not sure if that's what we want.

  100. andy

    Hm, that's true

  101. andy

    I'll think about this for a while

  102. Flow

    I mean we sure will have another OMEMO namespace because protocol changes. But I'm not sure if tying a encryption to namespace is a good idea. Why not say: "This is the default is nothing else is specified. This is how devices can announce support for other modes, and this is how you use them. And make sure your library selects the best suiting mode if multiple are possible".

  103. Flow

    I'm not sure how long aes-128 is considered to be secure. ~2030 seems to be the common answer. But http://www.keylength.com/en/compare/ also says 2015

  104. Zash

    Source?

  105. andy

    According to the BSI

  106. andy

    german federal office for information security

  107. Flow

    but i'm not sure if the site simply misreads the BSI paper

  108. Flow

    And I personally think that AES-128 is fine for the next 1-2 decades.

  109. Flow

    But who can foresee the future without having the right car.

  110. Zash

    Pretty sure I read somewhere than AES-128 is good enough until AES is broken.

  111. SamWhited

    This is probably true.

  112. SamWhited

    AES-128 is fine; I suspect that weaknesses in the protocol will be found before we break 128, and if 128 is broken it's not going to be long before 256 is broken too since it's such a tiny entropy difference (though I can't remember how many extra bits you get off the top of my head... 8 or 16 maybe)

  113. Zash

    And AES-256 was supposedly more broken than AES-128

  114. andy

    I can't actually find any reference to 128bit not recommended after 2015 in that BSI publication

  115. SamWhited

    I doubt that too, but unless I have hardware AES I like to play it on the save side. Side channel and timing attacks like the ones people have hypothisized exist in AES-256 are hard to use in practice. It would probably require a targeted attack, at which point it's easier to just steal your phone.

  116. SamWhited

    But I'm just speculating wildly when it comes down to it.

  117. andy

    There are some scenarios in which aes-192 and aes-256 are less secure than aes-128, that's correct.

  118. SamWhited

    andy: Are there actually proven? I've only ever read about supposed timing attacks and what not.

  119. andy

    SamWhited, A. Biryukov und D. Khovratovich, Related-Key Cryptanalysis of the Full AES-192 and AES-256, Asiacrypt 2009, LNCS 5912/2009, 1-18

  120. SamWhited

    Found it; thanks.

  121. andy

    I'm actually not sure whether AES-128 has been broken further since then as to be weaker than the complexity reduction the authors offer here

  122. Ge0rG

    steal your phone... or unscrew your MBP hard disk... https://twitter.com/i0n1c/status/658761878861139968

  123. andy

    Actually they apparently reduced the complexity even more for those longer block sizes.

  124. andy

    But keep in mind these are related-key attacks

  125. andy

    So, not really applicable here (unless the entropy source of the generating client is severely broken)

  126. SamWhited

    Which has been a problem in Android in the past... but there's also not much we can do about that.

  127. andy

    Well hopefully more than just android clients will adopt OMEMO :P

  128. SamWhited

    I wonder how iOS handles entropy. /me goes to find out.

  129. SamWhited

    Yah, forgot that this wasn't the Conversations room for a moment there.

  130. andy

    Hehe

  131. andy

    also, Ge0rG, scary

  132. edhelas

    hi everyone :)

  133. MattJ

    Evening

  134. edhelas

    I'll try to take some times to work on a new version of Bookmarks

  135. edhelas

    I was wondering if it's possible to just allow bookmarks of URI, then we can actually bookmark everything (from a chatroom, to a url, a pubsub node…) ?

  136. SamWhited

    There's a new version of bookmarks (or will be)? What were the changes?

  137. andy

    SamWhited, it's just brainstorming at this point, I believe. This scratchpad was also posted over in the Conversations channel: https://lite5.framapad.org/p/OlHwr5GBlY

  138. SamWhited

    Oh nifty, I missed that.

  139. edhelas

    SamWhited, I'm working on it :) I'd like to publish it in the upcoming days/week, I have to fix some stuffs on my client before that