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
dwdhas joined
intosi has left
intosi has joined
Zashhas left
Zashhas joined
dwdhas left
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?
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?
andy
Maybe include the term MessageElement in the name of the example or something?
Flow
andy: examples are not normative
andy
Flow, ah, I see what you mean.
Flow
And I'd consider s/MessageElement/EncryptElement/
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/>
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.
intosi has left
intosi has joined
Flow
andy: Sure, I'm just suggesting what could be improved
andy
Yes, I understand
Flow
And right now, I'm missing an explicit statement what a MessageElement is
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
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.
Flow
Also the statement that it contains a chat message is wrong, if you want to extend it at some point
andy
How is it wrong? MessageElements are defined as containing chat messages. That's their explicit purpose
ralphmhas left
andy
For anything else, there's KeyTransportElement
Flow
Well depends on how you define MessageElement
andy
True
andy
I'm talking about the current definition
Flow
but such an definition is missing
andy
It's all mentioned in the glossary, no?
Flow
If you say: MessageElement is an <encrypted/> with <payload/> then yes
Flow
andy: Not really no
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
andy
so a Message element is an <encrypted/> element in the omemo ns, which has a <payload/> that contains the chat message
andy
Maybe I'm missing something because I've been working with this stuff for months, but that seems pretty clear to me?
andy
oh, and ignore that stray 'Bundle' at the end there. copy/paste fail :X
Flow
andy: It's not crystal clear for someone new to OMEMO as it could be.
ralphmhas left
Flow
Neither the schema nor the examples are considered normative in XEPs
Flow
So you should write something like "a MessageElement is a <encrypted/> element which MUST posses a <payload/> containing the encrypted chat message".
Flow
I think MessageElement MUST also have a <header/> which at leat one </key> at at most one <iv/>
ralphmhas left
Flow
exactly one <iv/>
andy
Okay. I actually didn't know the schema wasn't normative. I'll make the definitions clear in the text then
andy
Thanks.
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
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).
dwdhas left
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
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?
andy
Precisely
andy
Or rather, it's not encrypted with the rid pubkey
dwdhas left
andy
it's encrypted in the long-standing axolotl session with the rid device
Flow
valueable information that should go into the xep
Flow
and what's the value in case of a KeyTransportElement?
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 ?
Flow
I'd say never do c) and in this case I would go with b)
andy
Okay
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.
andy
I see. I guess I've been treating it more like a place to dump definitions
andy
But that makes sense
andy
In a KeyTransportElement, the <key/> is a fresh, unused key, again encrypted with the sid<->rid session
dwdhas left
andy
I guess I'll move these definitions into the relevant sections and expand a bit on them
danielhas joined
dwdhas left
dwdhas left
ralphmhas left
danielhas left
danielhas joined
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." ?
Flow
andy: better. :) You should mention that the data is base64 encoded. I also don't like "contain the message's <body/>" element.
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.
danielhas joined
danielhas joined
andy
okay
dwdhas left
Flow
It is certainly not the message's <body/> element, because <payload/> only provides a subset of the features the <body/> element provides.
andy
Yes, I wasn't very happy with that either
andy
You're right
Flow
Also it is unclear what should happen if a message stanza has a <encrypted/>+<payload/> and a <body/> element
Flow
so re using the definition from rfc 6121 5.2.3: the <payload/> element contains encrypted human-readable XML character data.
intosi has left
ralphmhas left
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."
andy
Is that clear enough? I don't think it'd be a good idea to repeat the entire definition
ralphmhas left
dwdhas left
dwdhas left
soulianehas left
foss81405971has left
waqashas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
Tobiashas joined
arunehas left
arunehas joined
dwdhas left
xnyhpshas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas joined
artyhas left
artyhas joined
dwdhas left
dwdhas left
dwdhas left
dwdhas left
dwdhas joined
artyhas left
artyhas joined
stpeterhas joined
ralphmhas left
ralphmhas left
dwdhas left
ralphmhas left
daurnimatorhas joined
dwdhas left
dwdhas left
soulianehas joined
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.
dwdhas left
andy
Ah. Maybe I should explicitly mention that they're 128-bit symmetric keys.
Tobiashas left
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...
danielhas joined
artyhas left
Flow
andy: doesn't this mostly depend on axolotl?
Flow
At one point in the future OMEMO may need to negotiate the axolotl version used.
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
andy
At the moment, OMEMO uses 128bit AES-GCM for payload encryption, and thus the keys are 128 bit
Flow
ahh
Flow
right
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"
Lancehas joined
Flow
andy: question is, does is need to be negotible?
Flow
or would <payload mode='aes-gcm-256'> be sufficent?
andy
I *really* don't want it to be. Negotiation is kind of a pain to do
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
Flow
Right, but you should prepare that devices may want to announce that they support $cipher in case aes-gcm-128 became insecure
danielhas joined
andy
In that case we would probably want to bump the namespace version I think?
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/>
Flow
But I'd like to hear what zash and thjis say about this
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.
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...
Flow
assuming the sender wants authenticated encryption
andy
And I guess you'd want to put that information into PEP, rather than transmit it in-band
Flow
the capabilities in pep, of course. but what's actually used within <encrypted/>
andy
You pretty much never don't want authenticated encryption if you know what you're doing [citation needed]
SamWhitedtries to think of a use case for that... one probably exists, just not likely in chat.
Flow
I won't argue with that :)
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...
andy
So you would have to define some sort of prioritization list or something... It just gets kinda ugly
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.
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
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.
SamWhited
(assuming you both support the same namespace)
andy
Yeah, I don't really have a problem with the idea that a specific protocol version is tied to one specific cipher suite
andy
If people really do have special needs regarding the cipher usage, they can always extend the protocol
Flow
So devices need to register to multiple PEP nodes if we have multiple OMEMO namespaces. Not sure if that's what we want.
xnyhpshas left
andy
Hm, that's true
andy
I'll think about this for a while
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".
intosihas left
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
intosi has joined
intosi has left
Zash
Source?
andy
According to the BSI
andy
german federal office for information security
Flow
but i'm not sure if the site simply misreads the BSI paper
Flow
And I personally think that AES-128 is fine for the next 1-2 decades.
Flow
But who can foresee the future without having the right car.
Zash
Pretty sure I read somewhere than AES-128 is good enough until AES is broken.
SamWhited
This is probably true.
dwdhas left
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)
Zash
And AES-256 was supposedly more broken than AES-128
andy
I can't actually find any reference to 128bit not recommended after 2015 in that BSI publication
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.
SamWhited
But I'm just speculating wildly when it comes down to it.
andy
There are some scenarios in which aes-192 and aes-256 are less secure than aes-128, that's correct.
SamWhited
andy: Are there actually proven? I've only ever read about supposed timing attacks and what not.
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
waqashas left
SamWhited
Found it; thanks.
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
Ge0rG
steal your phone... or unscrew your MBP hard disk... https://twitter.com/i0n1c/status/658761878861139968
andy
Actually they apparently reduced the complexity even more for those longer block sizes.
andy
But keep in mind these are related-key attacks
andy
So, not really applicable here (unless the entropy source of the generating client is severely broken)
SamWhited
Which has been a problem in Android in the past... but there's also not much we can do about that.
andy
Well hopefully more than just android clients will adopt OMEMO :P
SamWhited
I wonder how iOS handles entropy. /me goes to find out.
SamWhited
Yah, forgot that this wasn't the Conversations room for a moment there.
andy
Hehe
waqashas joined
andy
also, Ge0rG, scary
goffihas left
Flowhas left
dwdhas left
dwdhas left
ralphmhas left
artyhas joined
dwdhas left
Martinhas left
ralphmhas left
ralphmhas left
Martinhas joined
Martinhas left
ralphmhas left
tim@boese-ban.dehas joined
Lancehas joined
Laurahas left
ralphmhas left
Lancehas joined
Flowhas joined
tim@boese-ban.dehas joined
ralphmhas left
edhelashas joined
edhelas
hi everyone :)
foss81405971has left
MattJ
Evening
ralphmhas left
edhelas
I'll try to take some times to work on a new version of Bookmarks
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ā¦) ?
SamWhited
There's a new version of bookmarks (or will be)? What were the changes?
arunehas left
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
SamWhited
Oh nifty, I missed that.
Alexhas left
Alexhas joined
SamWhitedhas left
SamWhitedhas left
SamWhitedhas left
xnyhpshas left
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