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