Party receiving TLV type 1 does not reveal final MAC keys?
cobratbq opened this issue · comments
Section "Revealing MAC Keys" describes how we either expose used MAC keys on every first message of a new ratchet (message ID == 0) or when disconnecting (sending remaining MAC keys as TLV type 1 payload). However, there is also the receiving party.
How does the receiving party act when receiving a TLV type 1 (DISCONNECT)? It may still have a number of MAC-keys-to-reveal. However, the session has been ended on the opposite site, so how do we now reveal the remaining MAC keys?
I hope I am understanding the rotation correctly. This would not be an issue in OTRv3 due to that version using a different ratcheting mechanism. I believe this is a problem for OTRv4 in case multiple messages are sent with the last message containing TLV 1. (I.e. the receiving party would be saving up MAC keys but never gets an opportunity to send them.)
As stated in the ADR#2, only the receiver can reveal MAC keys every new DH ratchet.
How does the receiving party act when receiving a TLV type 1 (DISCONNECT)?
It doesn't. The MAC keys are symmetrical which means that when you reveal from one side, you are reveling the ones of the other side as well. The only MAC keys that could remain unrevealed are the ones of delayed messages.
Due to the fact that we have better deniability and security properties from other mechanisms in the protocol (the DAKE, the double ratchet, ...), we don't need to be so strict about revealing MAC keys (in fact, we even considered not even including this).
Notice also that this TLV type 1 with the revealing keys is only used when the session is expired, to reveal from whom it is expiring. If there are delayed messages, it does not make sense to expire the MAC keys from them, as they will no longer be able to be received (a new DAKE). From an implementation point of view, you can queue these messages to be sent in the next session.
I understand that one party's sender keys are equal to the other party's receiver keys. (Otherwise decrypting or verifying a message wouldn't be possible.) However, one party's receiving keys are different from its sending keys, right? (Or said differently, the keys are present at both parties, but only one party is expected to reveal them and each party reveals a different set of keys.)
Note that TLV type 1 is also sent when user ends the encrypted session. ("User requests to end an OTR Conversation")
On revealing not being a critical activity anymore: Okay. Good to know.
I understand that one party's sender keys are equal to the other party's receiver keys. (Otherwise decrypting or verifying a message wouldn't be possible.) However, one party's receiving keys are different from its sending keys, right? (Or said differently, the keys are present at both parties, but only one party is expected to reveal them and each party reveals a different set of keys.)
I don't understand this. Yes, sending and receiving chains are different from one party; but mac keys and encryption keys are derived from the appropriate one. You don't reveal the chain keys.
Note that TLV type 1 is also sent when user ends the encrypted session. ("User requests to end an OTR Conversation")
Sure, but you don't have to reveal the MAC keys there. Only when you expire the session is that you reveal them, as it section states, and you reveal the ones from the stored messages keys, nothing else.
I don't understand this. Yes, sending and receiving chains are different from one party; but mac keys and encryption keys are derived from the appropriate one. You don't reveal the chain keys.
Indeed, you do not reveal the chain keys. However, any message keys (MKenc and indirectly MKmac) are derived from the chain key. The way I understand it, each party has a set of unique keys to be revealed. At any moment in time, the keys from one party are a different set of keys than the keys from the other party. The protocol expects that the receiving (verifying) party reveals the keys. So, if we want all keys to be revealed upon ending the session, both parties should reveal keys.
Sure, but you don't have to reveal the MAC keys there. Only when you expire the session is that you reveal them, as it section states, and you reveal the ones from the stored messages keys, nothing else.
Ah right. For some reason, I've read the spec as "... in any case, when TLV 1 is sent, attach remaining MACs-to-be-revealed.". I'm not sure what section hinted me to this line of reasoning.
Indeed, you do not reveal the chain keys. However, any message keys (MKenc and indirectly MKmac) are derived from the chain key. The way I understand it, each party has a set of unique keys to be revealed. At any moment in time, the keys from one party are a different set of keys than the keys from the other party. The protocol expects that the receiving (verifying) party reveals the keys. So, if we want all keys to be revealed upon ending the session, both parties should reveal keys.
No, when you receive a data mesage, you put that MAC key of that data message (which is equal for sender and receiver) and reveal that on the next data message of the next DH ratchet. The keys are similar like this:
Bob sending chain key == Alice receiving chain key
Alice sending chain key == Bob receiving chain key
and
Bob sending chain key == Alice receiving chain key != Alice sending chain key == Bob receiving chain key
So, no, no need that both parties reveal. The only special case is when they are delayed messages not arriving. When you reveal MAC keys (as sender or receiver), you are revealing the keys of both parties, because they are the same.
It goes like this:
Bob encrypts and macs a message_1 with enc_key_1 and mac_key_1
Alice decrypts and macs a message_1 with enc_key_1 and mac_key_1. Puts mac_key_1 in the list to be revealed.
Alice encrypts and macs a message_2 with enc_key_2 and mac_key_2. Reveals on this data message mac_key_1 (for Bob and herself).
Bob decrypts and macs a message_2 with enc_key_2 and mac_key_2. Puts mac_key_2 in the list to be revealed.
Bob encrypts and macs a message_3 with enc_key_3 and mac_key_3. Reveals on this data message mac_key_2 (for Alice and himself).
and so on.
Okay, so far your explanation is as I expected the DR to behave. To continue with the running example ...
In first section: Alice puts mac_key_1 in her list. Alice is the only one that is expected to reveal mac_key_1. (Even though Bob knows the MAC key, we expect the receiving end to reveal.)
In the second section, Bob puts mac_key_2 on his list. Bob is the only one that is expected to reveal mac_key_2.
Note: mac_key_1 != mac_key_2, in your example above. (Correct?)
Now let's say the conversation is cut short, and looks like this:
Bob encrypts and macs a message_1 with enc_key_1 and mac_key_1
Bob encrypts and macs a message_2 with enc_key_2 and mac_key_2, containing TLV type 1 to end session.
Alice decrypts and macs a message_1 with enc_key_1 and mac_key_1. Puts mac_key_1 in the list to be revealed.
Alice decrypts and macs a message_2 with enc_key_2 and mac_key_2. Puts mac_key_2 in the list to be revealed. Alice interprets the TLV type 1 and acts on the DISCONNECT TLV: transitions to "FINISHED" state.
Now how can Alice reveal mac_key_1 and mac_key_2 if she has to transition and there is no longer an encrypted session in which to reveal the remaining MAC keys?
I expect your answer will be that revealing is not necessary at this point. I just want to point out that there can be lingering MAC keys for the party receiving the TLV type 1.
As said on message#2 of this thread, we acknowledged that on ADR#2. In fact, as it is stated there, there is a vulnerability if you allow both sender and receiver to immediately reveal the MAC keys, which is stated in the paper quoted on that ADR. That is why only the receiver reveals, and that is why we have the situation you pointed out, which we know and have acknowledged.
OTRv3 made the decision to only allow the receiver to reveal MAC keys.
I just want to point out that there can be lingering MAC keys for the party receiving the TLV type 1.
There are no lingering MAC keys because you forget all keys when you receive the TLV type 1.
This has been acknowledged. Is there something else missing for you?
And as said on message#2 of this thread, we are not putting the whole trust of the security properties on the revealing of MAC keys, as the other techniques we have, already give us enough.
I think we've come full circle now. Thanks! 👍
Great!! Thanks! @cobratbq