XSF Discussion - 2015-10-27

  1. Zash has joined

  2. Lance has joined

  3. intosi has left

  4. Zash has left

  5. Zash has joined

  6. Zash has joined

  7. SamWhited has left

  8. SamWhited has left

  9. SamWhited has left

  10. SamWhited has left

  11. SamWhited has joined

  12. SamWhited has left

  13. SamWhited has left

  14. arty has left

  15. arty has joined

  16. Tobias has left

  17. arty has left

  18. waqas has joined

  19. SamWhited has left

  20. SamWhited has left

  21. SamWhited has left

  22. foss81405971 has left

  23. Lance has joined

  24. SamWhited has left

  25. ralphm has left

  26. intosi has joined

  27. intosi has left

  28. intosi has joined

  29. waqas has left

  30. waqas has joined

  31. waqas has left

  32. younss has joined

  33. younss has left

  34. SamWhited has joined

  35. xnyhps has left

  36. xnyhps has left

  37. intosi has left

  38. intosi has joined

  39. intosi has left

  40. intosi has joined

  41. arty has joined

  42. intosi has left

  43. intosi has joined

  44. goffi has joined

  45. goffi

    g'day

  46. Flow has joined

  47. arune has left

  48. intosi has left

  49. intosi has joined

  50. arune has left

  51. SamWhited has joined

  52. arty has left

  53. souliane has joined

  54. Flow

    hi goffi :)

  55. Zash has joined

  56. arty has joined

  57. Will has joined

  58. Will has left

  59. goffi has left

  60. Martin has joined

  61. Alex has joined

  62. Laura has joined

  63. goffi has joined

  64. ralphm has left

  65. ralphm has left

  66. Alex has left

  67. Alex has joined

  68. Zash has joined

  69. arune has left

  70. ralphm has left

  71. marcelo has joined

  72. marcelo has left

  73. ralphm has left

  74. SouL has left

  75. SouL has joined

  76. xnyhps has joined

  77. intosi has left

  78. intosi has joined

  79. 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

  80. dwd has joined

  81. intosi has left

  82. intosi has joined

  83. Zash has left

  84. Zash has joined

  85. dwd has left

  86. 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?

  87. 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?

  88. andy

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

  89. Flow

    andy: examples are not normative

  90. andy

    Flow, ah, I see what you mean.

  91. Flow

    And I'd consider s/MessageElement/EncryptElement/

  92. 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/>

  93. 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.

  94. intosi has left

  95. intosi has joined

  96. Flow

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

  97. andy

    Yes, I understand

  98. Flow

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

  99. 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

  100. 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.

  101. Flow

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

  102. andy

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

  103. ralphm has left

  104. andy

    For anything else, there's KeyTransportElement

  105. Flow

    Well depends on how you define MessageElement

  106. andy

    True

  107. andy

    I'm talking about the current definition

  108. Flow

    but such an definition is missing

  109. andy

    It's all mentioned in the glossary, no?

  110. Flow

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

  111. Flow

    andy: Not really no

  112. 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

  113. andy

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

  114. andy

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

  115. andy

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

  116. Flow

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

  117. ralphm has left

  118. Flow

    Neither the schema nor the examples are considered normative in XEPs

  119. Flow

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

  120. Flow

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

  121. ralphm has left

  122. Flow

    exactly one <iv/>

  123. andy

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

  124. andy

    Thanks.

  125. tim@boese-ban.de has left

  126. tim@boese-ban.de has joined

  127. 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).

  128. dwd has left

  129. 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

  130. 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?

  131. andy

    Precisely

  132. andy

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

  133. dwd has left

  134. andy

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

  135. Flow

    valueable information that should go into the xep

  136. Flow

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

  137. 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 ?

  138. Flow

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

  139. andy

    Okay

  140. 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.

  141. andy

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

  142. andy

    But that makes sense

  143. andy

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

  144. dwd has left

  145. andy

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

  146. daniel has joined

  147. dwd has left

  148. dwd has left

  149. ralphm has left

  150. daniel has left

  151. daniel has joined

  152. 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." ?

  153. Flow

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

  154. 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.

  155. daniel has joined

  156. daniel has joined

  157. andy

    okay

  158. dwd has left

  159. Flow

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

  160. andy

    Yes, I wasn't very happy with that either

  161. andy

    You're right

  162. Flow

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

  163. Flow

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

  164. intosi has left

  165. ralphm has left

  166. 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."

  167. andy

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

  168. ralphm has left

  169. dwd has left

  170. dwd has left

  171. souliane has left

  172. foss81405971 has left

  173. waqas has joined

  174. dwd has left

  175. dwd has left

  176. dwd has left

  177. dwd has left

  178. Tobias has joined

  179. arune has left

  180. arune has joined

  181. dwd has left

  182. xnyhps has left

  183. dwd has left

  184. dwd has left

  185. dwd has left

  186. dwd has left

  187. dwd has left

  188. dwd has left

  189. dwd has joined

  190. arty has left

  191. arty has joined

  192. dwd has left

  193. dwd has left

  194. dwd has left

  195. dwd has left

  196. dwd has joined

  197. arty has left

  198. arty has joined

  199. stpeter has joined

  200. ralphm has left

  201. ralphm has left

  202. dwd has left

  203. ralphm has left

  204. daurnimator has joined

  205. dwd has left

  206. dwd has left

  207. souliane has joined

  208. 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.

  209. dwd has left

  210. andy

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

  211. Tobias has left

  212. 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...

  213. daniel has joined

  214. arty has left

  215. Flow

    andy: doesn't this mostly depend on axolotl?

  216. Flow

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

  217. 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

  218. andy

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

  219. Flow

    ahh

  220. Flow

    right

  221. 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"

  222. Lance has joined

  223. Flow

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

  224. Flow

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

  225. andy

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

  226. 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

  227. Flow

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

  228. daniel has joined

  229. andy

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

  230. 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/>

  231. Flow

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

  232. 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.

  233. 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...

  234. Flow

    assuming the sender wants authenticated encryption

  235. andy

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

  236. Flow

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

  237. andy

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

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

  239. Flow

    I won't argue with that :)

  240. 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...

  241. andy

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

  242. 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.

  243. 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

  244. 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.

  245. SamWhited

    (assuming you both support the same namespace)

  246. andy

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

  247. andy

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

  248. Flow

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

  249. xnyhps has left

  250. andy

    Hm, that's true

  251. andy

    I'll think about this for a while

  252. 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".

  253. intosi has left

  254. 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

  255. intosi has joined

  256. intosi has left

  257. Zash

    Source?

  258. andy

    According to the BSI

  259. andy

    german federal office for information security

  260. Flow

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

  261. Flow

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

  262. Flow

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

  263. Zash

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

  264. SamWhited

    This is probably true.

  265. dwd has left

  266. 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)

  267. Zash

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

  268. andy

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

  269. 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.

  270. SamWhited

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

  271. andy

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

  272. SamWhited

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

  273. 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

  274. waqas has left

  275. SamWhited

    Found it; thanks.

  276. 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

  277. Ge0rG

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

  278. andy

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

  279. andy

    But keep in mind these are related-key attacks

  280. andy

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

  281. SamWhited

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

  282. andy

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

  283. SamWhited

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

  284. SamWhited

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

  285. andy

    Hehe

  286. waqas has joined

  287. andy

    also, Ge0rG, scary

  288. goffi has left

  289. Flow has left

  290. dwd has left

  291. dwd has left

  292. ralphm has left

  293. arty has joined

  294. dwd has left

  295. Martin has left

  296. ralphm has left

  297. ralphm has left

  298. Martin has joined

  299. Martin has left

  300. ralphm has left

  301. tim@boese-ban.de has joined

  302. Lance has joined

  303. Laura has left

  304. ralphm has left

  305. Lance has joined

  306. Flow has joined

  307. tim@boese-ban.de has joined

  308. ralphm has left

  309. edhelas has joined

  310. edhelas

    hi everyone :)

  311. foss81405971 has left

  312. MattJ

    Evening

  313. ralphm has left

  314. edhelas

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

  315. 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…) ?

  316. SamWhited

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

  317. arune has left

  318. 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

  319. SamWhited

    Oh nifty, I missed that.

  320. Alex has left

  321. Alex has joined

  322. SamWhited has left

  323. SamWhited has left

  324. SamWhited has left

  325. xnyhps has left

  326. 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

  327. ralphm has left

  328. dwd has left

  329. ralphm has left

  330. intosi has joined

  331. intosi has left

  332. ralphm has left

  333. dwd has left

  334. ralphm has left

  335. Zash has left

  336. dwd has left

  337. ralphm has left

  338. Jef has joined

  339. Jef has left

  340. Tobias has left

  341. intosi has joined

  342. Lance has joined

  343. SamWhited has left

  344. ralphm has left

  345. ralphm has left

  346. Flow has joined

  347. dwd has left

  348. Lance has joined

  349. tim@boese-ban.de has left

  350. Alex has left

  351. daurnimator has left

  352. arune has left

  353. dwd has left

  354. dwd has left

  355. souliane has left

  356. stpeter has left

  357. foss81405971 has left

  358. dwd has left

  359. stpeter has joined

  360. stpeter has left