(Hm..sorry for the screwed up line lengths.)
Note that my suggestion:
On 13.02.2018 17:57, Simon Friedberger wrote:
> E2. Make the ID verifiable: This is what I had in mind at the summit and
> after some discussion yesterday Jonas and Dave basically immediately
> came up with the same thing, so it might be reasonably
> Basically, the client calculates the ID based on some information that
> it shares with the server like HASH(stream-id || sm-counter). This
> allow the server to verify that the client generated a proper ID.
> suggested HMAC(key=stream-id, msg=sm-counter). If the message is in a
> MUC, the MUC server can provide the user with some salt and then a
> HASH(message-counter || salt) could be used to ensure that proper
> IDs are generated.
> This ID is based on there being a party which is in charge of checking
> the IDs. If you connect to a malicious MUC with malicious clients they
> can still send you whatever. I don't think that is a problem, is it?
Does not solve the problem, that a malicious server can send out
messages with duplicate IDs. The servers or clients receiving
them have no way to check. This could be fixed by including the
message body (and whatever else seems appropriate in the hash).
Which would leave us something like
HASH(message-body || HASH(stream-id || sm-counter))
and HASH(stream-id || sm-counter) would have to be transmitted to
remote servers. This does prevent (C7.)
> C7. When referencing a message for example by "liking" it a forgeable ID
> could get you to like things you didn't intend to like.
> This is a difficult problem because in many cases it requires
> clients and servers and those have a lot of power anyway.
But I'm not sure it is necessary given that messages are not
authenticated anyway. They aren't even for OMEMO.
They could theoretically be but the attack still seems a bit
academic. Anyway, hashes are generally cheap and it might not
hurt to include the entire message in the hash.
Standards mailing list