Several questions regarding Client Profile

[cobratbq]

Hi all, I've got several questions regarding the Client Profile sections and the use of client profiles. Some of these are intended for confirmation of correct understanding.

1. I should validate the signatures in the ClientProfile using the long-term public keys in the same Client Profile message, correct? (That is, there is no other external information used for verifying these signatures.)
2. Is it expected that the OTRv3 DSA public key is known by the chat client already? I.e. it is not transmitted in the current (interactive) DAKE. Meaning, users of an existing OTRv3 capable chat client may already have these public keys. Then when they upgrade to OTRv4, they can use gathered public keys to verify the transitional signature and confirm this is the same party that previously chatted using OTRv3.
   If so, not all clients will keep public keys. The OTRv3 spec defines using its fingerprint as the identifier. So, that would mean there is no way to verify the transitional signature, correct?
3. Multiple long-term public keys (Maybe already fixed after #154.) a) Are the multiple keys meant for rotating the keys. Hence the multiple keys in transition phase between old key and new key?
   b) Why do they have different expiration date as client profile. What is the use of making the clientprofile expire in short timespan if long-term public keys expire in long timespan?
4. There is no identifier in https://github.com/otrv4/otrv4/blob/master/otrv4.md#client-profile-data-type. Is the identifier still relevant?
5. The long-term public keys in the client profile are the same long-term public keys that are talked about in other parts of the spec, right? That is, it is a long-term key to identify that the same chat client is used multiple times. (I'm in doubt because of the expirations/rotations mentioned in question above.)
6. There is only a long-term public key that is specific to a single client, but there is no long-term key to be used by a single user that is shared over clients, correct?
7. The owner instance tag that is mentioned in the Client Profile is the same tag that is used in every OTR-encoded message, right? This instance tag is expected to be persistent. Is it desirable that this persistent identifier follows the user in every conversation? (At least in OTRv3 one could generate a new instance tag all the time.)

Sorry if the questions seem a bit like hurried scribbles. I'm happy to clarify further. Please let me know which parts are unclear.

Note that I also have a bit of concern about the "maintenance" involved for users (or ideally chat clients) for these client profiles. If the Client Profile is a long-lived payload/record/whatever, you might publish it on a channel of a static nature, such as a "about" HTML page link-ref tag or something. However, due to the expiration and such, it seems to severely limited the number of options and increase maintenance.

[claucece]

Hey!

Thanks so much for your questions!

I should validate the signatures in the ClientProfile using the long-term public keys in the same Client Profile message, correct? (That is, there is no other external information used for verifying these signatures.)

You validate the Client Profile Signature with the Ed448 public key contained in the Client Profile. You validate the Transitional Signature with the OTRv3 public authentication DSA key, which is not contained in the Client Profile; but must be on client's local storage.

Is it expected that the OTRv3 DSA public key is known by the chat client already? I.e. it is not transmitted in the current (interactive) DAKE. Meaning, users of an existing OTRv3 capable chat client may already have these public keys. Then when they upgrade to OTRv4, they can use gathered public keys to verify the transitional signature and confirm this is the same party that previously chatted using OTRv3.

Yes, it is expected that the OTRv3 DSA public key is known by the chat client already, as clients that use OTRv3 and OTRv4 must already have the OTRv3 DSA public key.

If so, not all clients will keep public keys. The OTRv3 spec defines using its fingerprint as the identifier. So, that would mean there is no way to verify the transitional signature, correct?

I don't understand this. A client must have somewhere the public key so the fingerprint can be generated, and the functions of OTRv3 used.

Multiple long-term public keys (Maybe already fixed after #154.)

They are already removed ;) But:

a) Are the multiple keys meant for rotating the keys. Hence the multiple keys in transition phase between old key and new key?

No. Sometimes in clients, you can generate several long-term public keys that are valid at the same time. There is no restriction on this. Ideally, there should only be one long-term public key at one time.

b) Why do they have different expiration date as client profile. What is the use of making the client profile expire in short timespan if long-term public keys expire in long timespan?

The Client Profile has a short expiration date so when its published it provides deniability.

There is no identifier in https://github.com/otrv4/otrv4/blob/master/otrv4.md#client-profile-data-type. Is the identifier still relevant?

Yes. I included it again ;)

The long-term public keys in the client profile are the same long-term public keys that are talked about in other parts of the spec, right? That is, it is a long-term key to identify that the same chat client is used multiple times. (I'm in doubt because of the expirations/rotations mentioned in question above.)

Yes. But then again, you can have per client several long-term public keys. Not ideal, but can happen.

There is only a long-term public key that is specific to a single client, but there is no long-term key to be used by a single user that is shared over clients, correct?

Ideally, there is only a long-term public key that is specific to a single client. But I have seen clients that allow having more than one valid long-term public key. You can import and export long-term public keys; but not necessarily a user will have a unique long-term public key for all its clients.

The owner instance tag that is mentioned in the Client Profile is the same tag that is used in every OTR-encoded message, right? This instance tag is expected to be persistent. Is it desirable that this persistent identifier follows the user in every conversation? (At least in OTRv3 one could generate a new instance tag all the time.)

Yes. I have to think about this further.

Note that I also have a bit of concern about the "maintenance" involved for users (or ideally chat clients) for these client profiles. If the Client Profile is a long-lived payload/record/whatever, you might publish it on a channel of a static nature, such as a "about" HTML page link-ref tag or something. However, due to the expiration and such, it seems to severely limited the number of options and increase maintenance.

You only publish it for deniability reasons. You don't use the published Client Profile for anything else. So for functions on the spec, you only need the locally stored Client Profiles.

Thanks!

[juniorz]

The owner instance tag that is mentioned in the Client Profile is the same tag that is used in every OTR-encoded message, right? This instance tag is expected to be persistent. Is it desirable that this persistent identifier follows the user in every conversation? (At least in OTRv3 one could generate a new instance tag all the time.)

I guess it is important to make a distinction here: the instance tag identifies the instance (or client/device) running the OTR protocol.

The instant messaging user (alice@otr.im in the XMPP network, for example) is not identified by the instance tag across devices. For each OTR-over-XMPP client (Pidgin, CoyIM, etc), the "user" is expected to have a separate instance tag with a corresponding Client Profile published. These Client Profiles may share the same long-term public key, but that is not required.

This is also why we renamed User Profile to Client Profile. They don't identify a user, only its client/device.

[olabini]

Is it expected that the OTRv3 DSA public key is known by the chat client already? I.e. it is not transmitted in the current (interactive) DAKE. Meaning, users of an existing OTRv3 capable chat client may already have these public keys. Then when they upgrade to OTRv4, they can use gathered public keys to verify the transitional signature and confirm this is the same party that previously chatted using OTRv3. If so, not all clients will keep public keys. The OTRv3 spec defines using its fingerprint as the identifier. So, that would mean there is no way to verify the transitional signature, correct?

Hey - yeah, this is absolutely a problem. I'm feeling kinda stupid for not noticing it before. OTRv3 clients will only store fingerprints for verified OTRv3 keys - they will not save public keys.

We have two possible solutions. The first one is to put the DSA OTRv3 key a an optional field in the Client Profile as well. The other solution would be to require clients to do an OTRv3 AKE with the peer, and then explicitly save the key, in order to verify the transitional signature in the future.

[claucece]

We have two possible solutions. The first one is to put the DSA OTRv3 key a an optional field in the Client Profile as well. The other solution would be to require clients to do an OTRv3 AKE with the peer, and then explicitly save the key, in order to verify the transitional signature in the future.

True.. I thought they will still keep it.. but anyhow. I vote for the first option: to make it part of the Client Profile.

[cobratbq]

Ah, okay, check. It's about maintaining multiple long-term keys, not about key rotation. That's clear. I am aware of clients having various configurations, of which the choice is based on session identifier. One can already generate a long-term key per session identifier in the extreme case. That would bring a lot of variation, but you would still only send one public key at a time. (That way you can, for example, generate a different public key for each chat network.) Of course, I'm not saying that's the only relevant case. Just making sure you're aware.

On Client Profile vs User Profile: I'm aware of the purpose for the Client Profile public key to "tie" to a specific client only. (Hence also the discouragement of importing/exporting keypairs.) However, I read about keys in a few places, and the "multiple keys per profile" that additionally have their own expiration date, made me wonder if I missed something.

Actually, with Client Profiles that have a short expiration date and long-term public keys with a deviating (I expect significantly longer) expiration date, I'm lost on the purpose. I expected the "Deniability" property to be "I can deny that I was the one who started this conversation, because anyone could have just downloaded my profile and sent it as part of this chat conversation." (Hence, I can easily deny I was the participant in this chat conversation.) But I don't see how the short expiration date helps there. Why not generate a single Client Profile, put it on your website and keep reusing the same Client Profile in your (dedicated, single) client? (Hence, 5 clients, 5 client profiles.) I'm aware that I'm probably showing my lack of experience with crypto, but then again, that's not the kind of knowledge I'm providing anyways :-P

As I understand the spec, the OTRv3 DSA key will only be added in case we initiate through a query. Any client of which we are aware of OTRv4 capabilities, we can ideally immediately start an OTRv4 conversation by sending an IdentityMessage. That could be used to determine whether or not the OTRv3 DSA key is useful at all. (I.e. you can immediately initiate an OTRv4-only session if you are aware of client profiles for this user, hence you know his clients OTRv4 capabilities. If you don't have a client profile, you play more conservatively by default and go through query message. Of course overriding to OTRv4-only is fine too, but then it's an explicit choice such as a configuration option.) In that case, would you want a flag in the client profile indicating whether a client should: Optimistically try OTRv4-only mode first, or stay conservative and initiate by sending Query/Whitespace messages first? That might help the client to determine a reasonable course of action without checking with the user. (Come to think of it ... it would basically signal to assume encryption capabilities i.s.o. sending a carefully crafted query/whitespace message first.)

In any case, thanks all for the quick responses!

[olabini]

Actually, with Client Profiles that have a short expiration date and long-term public keys with a deviating (I expect significantly longer) expiration date, I'm lost on the purpose. I expected the "Deniability" property to be "I can deny that I was the one who started this conversation, because anyone could have just downloaded my profile and sent it as part of this chat conversation." (Hence, I can easily deny I was the participant in this chat conversation.) But I don't see how the short expiration date helps there. Why not generate a single Client Profile, put it on your website and keep reusing the same Client Profile in your (dedicated, single) client? (Hence, 5 clients, 5 client profiles.)

The real problem here is revocation. Since there are no other revocation mechanisms or expiry in the keys themselves, expiry of the profile is the only measure we have to make it possible to revoke an existing key, and to show a new key as valid. We had some other reasons for the short expiry as well, but honestly my brain is drawing a blank on it right now.

[claucece]

Hey!

Ah, okay, check. It's about maintaining multiple long-term keys, not about key rotation. That's clear. I am aware of clients having various configurations, of which the choice is based on session identifier. One can already generate a long-term key per session identifier in the extreme case. That would bring a lot of variation, but you would still only send one public key at a time. (That way you can, for example, generate a different public key for each chat network.) Of course, I'm not saying that's the only relevant case. Just making sure you're aware.

Yes.. this is quite interesting ;)

On Client Profile vs User Profile: I'm aware of the purpose for the Client Profile public key to "tie" to a specific client only. (Hence also the discouragement of importing/exporting keypairs.) However, I read about keys in a few places, and the "multiple keys per profile" that additionally have their own expiration date, made me wonder if I missed something.

Yeah.. this was an idea that was introduced that did not work well. I think is clearer now on the spec.

Actually, with Client Profiles that have a short expiration date and long-term public keys with a deviating (I expect significantly longer) expiration date, I'm lost on the purpose. I expected the "Deniability" property to be "I can deny that I was the one who started this conversation, because anyone could have just downloaded my profile and sent it as part of this chat conversation." (Hence, I can easily deny I was the participant in this chat conversation.) But I don't see how the short expiration date helps there. Why not generate a single Client Profile, put it on your website and keep reusing the same Client Profile in your (dedicated, single) client? (Hence, 5 clients, 5 client profiles.) I'm aware that I'm probably showing my lack of experience with crypto, but then again, that's not the kind of knowledge I'm providing anyways :-P

Well, you publish the client profile with its signature, which allows it to send it signed during the DAKE without compromising deniability (so the other party knows that this is yours, but anyone could have used it). But you don't want this signature of the whole profile to last forever so you expire it regularly.

As I understand the spec, the OTRv3 DSA key will only be added in case we initiate through a query. Any client of which we are aware of OTRv4 capabilities, we can ideally immediately start an OTRv4 conversation by sending an IdentityMessage. That could be used to determine whether or not the OTRv3 DSA key is useful at all. (I.e. you can immediately initiate an OTRv4-only session if you are aware of client profiles for this user, hence you know his clients OTRv4 capabilities. If you don't have a client profile, you play more conservatively by default and go through query message. Of course overriding to OTRv4-only is fine too, but then it's an explicit choice such as a configuration option.) In that case, would you want a flag in the client profile indicating whether a client should: Optimistically try OTRv4-only mode first, or stay conservative and initiate by sending Query/Whitespace messages first? That might help the client to determine a reasonable course of action without checking with the user. (Come to think of it ... it would basically signal to assume encryption capabilities i.s.o. sending a carefully crafted query/whitespace message first.)

So, the modes work like this: in the case of OTRv3-compatible mode that is the only mode that will allow query messages and the transitional signature, as it is the only one that understands that. The other modes does not allow that, meaning, that if you have a Client Profile with a transitional signature, and you use it with the OTRv4-only mode, you will ignore the transitional signature field if present.

Thanks!!

[cobratbq]

@olabini I would be curious to know what other reasons there were. I don't think they are documented in ADR-003. If all these reasons are only applicable to the Client Profile used in the Prekey Ensemble, then I would recommend simplifying the Client Profile for the Interactive DAKE. (Less moving parts, easier to adopt.)

I don't see how the expiration date would influence the decisions for clients operating interactively. I can imagine a few cases (when mentioning DAKE, I always mean the Interactive DAKE):

1. No client profile present A DAKE is performed. The Client Profile is received. Two subcases exist: a) Expiration date is valid: DAKE is successfully finished; b) Expiration date is invalid: Other party uses a bad client as a bad profile is propagated. You can either accept or reject, but expiration date will only introduce more doubt.
2. Client profile is present, valid i.e. not expired A DAKE is performed. In any case, you will receive a new client profile. You'll want to trust the newly received client profile. What information does the original client profile give you? You can compare public key in both client profiles to correllate and figure out that one client profile succeeds the other. However, it does not give you any new information as you have received a full, new client profile which contains all needed information. You continue with the new client profile. Valid or invalid, use cases are the same as (1.)
3. Client profile is present, expired A DAKE is performed. In any case, you will receive a new client profile, so there is little use in knowing that your cached information is out-of-date. Follows like (2.).

With the information I am aware of, I would claim that the expiration date does not offer any value. Even if it is used to indicate expiry of the long-term public key, I wouldn't care, because a new Client Profile is provided at initiation of the DAKE. (I haven't read into the Non-interactive DAKE yet. So I cannot comment on that.)

[claucece]

Hey @cobratbq

@olabini I would be curious to know what other reasons there were. I don't think they are documented in ADR-003. If all these reasons are only applicable to the Client Profile used in the Prekey Ensemble, then I would recommend simplifying the Client Profile for the Interactive DAKE. (Less moving parts, easier to adopt.)

The client profile as said has more information than the public key only. It expires for several reasons: it is signed, so this signature also has to expire. It has versions. As version advertisement is public information, a participant is not able to delete it from public servers. To facilitate versions revocation, the client profile should have a short expiration date. A client profile is also for future versions of OTR, so it cannot be a forever client profile, as it is, how can a user state that they support a new version?

No client profile present A DAKE is performed. The Client Profile is received. Two subcases exist: a) Expiration date is valid: DAKE is successfully finished; b) Expiration date is invalid: Other party uses a bad client as a bad profile is propagated. You can either accept or reject, but expiration date will only introduce more doubt.

If the expiration date is invalid, the DAKE is simply not performed.

Client profile is present, valid i.e. not expired A DAKE is performed. In any case, you will receive a new client profile. You'll want to trust the newly received client profile. What information does the original client profile give you? You can compare public key in both client profiles to correllate and figure out that one client profile succeeds the other. However, it does not give you any new information as you have received a full, new client profile which contains all needed information. You continue with the new client profile. Valid or invalid, use cases are the same as (1.)

I think this is a source of confusion. You don't create a client profile for each DAKE you perform. If you already have a valid Client Profile, you use that one.

Client profile is present, expired A DAKE is performed. In any case, you will receive a new client profile, so there is little use in knowing that your cached information is out-of-date. Follows like (2.).

A DAKE should never accept an expired Client Profile.

With the information I am aware of, I would claim that the expiration date does not offer any value. Even if it is used to indicate expiry of the long-term public key, I wouldn't care, because a new Client Profile is provided at initiation of the DAKE. (I haven't read into the Non-interactive DAKE yet. So I cannot comment on that.)

No. You don't create a new Client Profile every time you do a DAKE. If you already have a valid one, you use it, as far as I think. I'll try to update the spec with this.

Thanks!

[claucece]

I think we are missing a big section around publication/retrieval/expiration of Client Profile.. I'll create an issue for this :)

[cobratbq]

The client profile as said has more information than the public key only. It expires for several reasons: it is signed, so this signature also has to expire. It has versions. As version advertisement is public information, a participant is not able to delete it from public servers. To facilitate versions revocation, the client profile should have a short expiration date. A client profile is also for future versions of OTR, so it cannot be a forever client profile, as it is, how can a user state that they support a new version?

Few questions as follow-up:

• Probably lack of understanding of crypto, but why should the signature expire?
• Versions, info may be outdated: Sure, that means you need to distinguish between client profiles and pick which profile is most current. This implies a creation date, rather than an expiration date.
• Advertised on public servers, not able to delete: sure, but it is only there to provide deniability, so nobody cares that there is one client profile too many, just that the current client profile is among them. (As mentioned, the creation date is sufficient here.)
• As mentioned before, the published profile is not actually used. It's there for people to abuse.

I cannot say anything about the expiration of the signature. For the remaining arguments, however, it seems like it is sufficient to publish a Client Profile with a newer creation date (indicating that older Client Profiles are superseeded). That would mean, 1 publication each time some aspect of the Client Profile changes, instead of periodically - say once a week. Frequency would be small enough to be viable to more flavours of networks.

About comments on not accepting an expired Client Profile. That's clear. I was iterating through the use cases.

I think this is a source of confusion. You don't create a client profile for each DAKE you perform. If you already have a valid Client Profile, you use that one.

True, I am aware of that. However, you do receive one from the counter-party on every initiation. Each Identity Message carries a Client Profile, as does every Auth-R message. So what is the use of keeping the Client Profile? (That is, for Interactive DAKE.)

(Note that I approach this from the Client Profile receiver point-of-view. For the Sender this is a trivial generate/load from cache operation. The Client Profile is supposed to be informational to the receiver.)

I think we are missing a big section around publication/retrieval/expiration of Client Profile.. I'll create an issue for this :)

Additional clarification around publication/retrieval/expiration might be useful. Right now I'm either missing something, or we're trying to support a non-existent use case.

UPDATE: The way the client profile is handled seems similar to how you would handle a GPG key (publication). Note, however, that when using GPG you do not get handed the same/newer GPG public key as soon as you start typing an email. The nature of the interaction is different.

[claucece]

Ok, so in this I'm also going to mix the non-interactive:

Versions, info may be outdated: Sure, that means you need to distinguish between client profiles and pick which profile is most current. This implies a creation date, rather than an expiration date.

Locally, you should only have the valid Client Profile which you know is not expired. Published you have the Client Profile which you use for several things: check the versions, deniability and the non-interactive path. It is true that we have defined that you publish on the Prekey Server the Client Profile by replacing the old one, but in reality it can be multiple Client Profiles published, and, then you always check the one with latest expirity date, not the one with the first creation.

This is for slight prevention of version rollback: It is possible for the receiver of a Query Message that contains versions lower than four to check for a published Client Profile and thus detect a rollback attack for older versions. This Client Profile used to check should be the one with the latest expiration date. For me it has an expiration date because it revokes the latest one, not keep alive the ones with different creation dates.

Advertised on public servers, not able to delete: sure, but it is only there to provide deniability, so nobody cares that there is one client profile too many, just that the current client profile is among them. (As mentioned, the creation date is sufficient here.)

No. You also use the published Client Profile for the non-interactive path. In the case of the interactive path only, it is used for versions (to very slightly prevent version rollback) and for deniability.

As mentioned before, the published profile is not actually used. It's there for people to abuse.

You need it for the non-interactive path. I don't know how people will abuse it.. how will they?

True, I am aware of that. However, you do receive one from the counter-party on every initiation. Each Identity Message carries a Client Profile, as does every Auth-R message. So what is the use of keeping the Client Profile? (That is, for Interactive DAKE.)

The sender keeps its sending Client Profile for the interactive DAKE. I don't understand why they will not keep it ;) The receiver does not keep it.

Additional clarification around publication/retrieval/expiration might be useful. Right now I'm either missing something, or we're trying to support a non-existent use case.

Ok. I'll try to answer all of this in an ADR or something ;)

Thanks!!

[claucece]

I also like what @olabini said, the only way you can actually expire a key in OTR is by expiring the client.. how else will you expire the key?

[cobratbq]

I understand from the story at the top, that most value is for the non-interactive DAKE. If it means the same Client Profile content is needed for Interactive DAKE, so be it.

Ah, and I picked up two additional points from your explanation:

1. The version rollback. I did not link that to the client profile. So that is the action where you rely on a previously known Client Profile during Interactive DAKE.
2. If you are sent a Client Profile from an unknown counter-party, you cannot be sure that they sent you the latest revision. Hence without expiration date, the sender could abuse this by sending an old version, as the receiving party might not be aware of the latest revision of the Client Profile. Hence, you rely on an expiration date. In addition, you rely on a short expiration date such that you are able to publish updates frequently, if necessary.

You need it for the non-interactive path. I don't know how people will abuse it.. how will they?

My wording was inconvenient. I meant for "Deniability", you need to claim that other people would use your client profile, thus publish it. In any case, we're on the same page here, so you can ignore the comment.

The sender keeps its sending Client Profile for the interactive DAKE. I don't understand why they will not keep it ;) The receiver does not keep it.

Sure, the sender keeps a previously generated client profile as long as it is valid. No sense in performing the same action multiple times. My remarks are only about the receiver.

I also like what @olabini said, the only way you can actually expire a key in OTR is by expiring the client.. how else will you expire the key?

I'm sorry, but I really don't see how this works. There is no dedicated expiraion date for the public key contained in the profile. Hence, as soon as you use the public key again, it becomes valid again, given that you sign a new Client Profile with the same public key. So it does not prevent abuse in case the public key is stolen. If the key is lost, nobody cares, because it's never going to be used anymore. (Right, or is that too short sighted?) If you replace your key, you simply generate a new Client Profile with the new public key. There is no concept of "expiration" in here, or "transitioning away from old to new key" with a Client Profile including both, right?

I appreciate you taking the time to answer my questions. I don't mean to be a PITA. I simply want to understand how this works.

[claucece]

Ok, about the signature, this is how I think about it:

Let's say that an attacker manages to compromise your long-term private ed448 key and has your signed Client Profile (signed with the current symmetric key). You know that you have to refresh your long-term keys and still preserve the deniability for your future conversations at least. You therefore create a new Client Profile to be published with a new expiration date that revokes the older one (this one is not expired yet but will expire prior to the new one). Not only conversations contents are at risk with the compromise of the long-term private ed448 key but deniability. The only way you can refresh your key material is by creating a new key and publishing it, so both integrity and deniability of the conversation is kept. By using only the creation date of something, you are not revoking anything.. because those profiles are still "valid"; expiration, in this context, means revoked, not useful anymore. Therefore, you can easily revoke something, in the case, something happens. The published signed Client Profiles therefore, need to expire because sometimes the user cannot replace them (they are published on public servers), and therefore, it will use expiration as revokation.

[claucece]

I'll answer this tomorrow ;)

I appreciate you taking the time to answer my questions. I don't mean to be a PITA. I simply want to understand how this works.

Don't worry, I like this things ;)

[cobratbq]

IIUC, the key difference between my suggestion (creation date) and current strategy (expiration date) is that the creation date is only effective once you are aware of a Client Profile with a newer creation date. Until you receive/discover this information, you cannot determine if your local cached Client Profile is still trustworthy. (Or even received Client Profile is still trustworthy.)

With the expiration date, on the other hand, you force the client to regularly look for updated information, given that the Client Profile is only valid for a short while. (After which it should not be used/trusted anymore.)

I think I'm convinced now :-P

[claucece]

Mmm.. I think we still have to think more about this... anyhow, thanks for bringing this questions!

[cobratbq]

I think I have some more questions too. I'll think about it for a while first. Additional clarification is welcome indeed :-). At least, let me summarize some of the observations so far:

Improvements:

• Client Profile needs a OTRv3 DSA public key field (Public key for transitional signature)
• Missing step in https://github.com/otrv4/otrv4/blob/master/otrv4.md#validating-a-client-profile: compare expiration date against Client Profile previously encountered by receiver. (Right? Maybe also explain on whether or not to store locally. I think I got mixed signals from spec and explanations here.)

Observations: (Should these be documented somewhere to support in reviewing the drafts?)

• Persistent instance tag allows correlation of multiple conversations? (Not able to arbitrarily generate instance tags for each new conversation, due to need to use it as persistent identification of client.)

Update: Note that if you store Client Profiles locally, it would give an indication within the range of a week when you chatted with someone last. (I know this is deniable and I'm not sure if this considered an issue.)

[olabini]

Missing step in https://github.com/otrv4/otrv4/blob/master/otrv4.md#validating-a-client-profile: compare expiration date against Client Profile previously encountered by receiver. (Right? Maybe also explain on whether or not to store locally. I think I got mixed signals from spec and explanations here.)

I'm not sure if there is any point to doing this. In fact, for the interactive case only, there is no need to ever store Client Profiles for peers. Comparing against previous expiration dates doesn't really give you anything.

[olabini]

OK, I'll answer and summarize from my perspective how I see this. @claucece has already said some of this, in the large blocks of text. I'll try to be succinct:

• The main reason (and I forgot about this earlier) is to prevent version rollback attacks. This is only pertinent once v5 exists - once that happens, without expiry, someone could take a Client Profile with version 4 only, and put that into the DAKE, and potentially trigger other vulnurabilities. Version rollback is a significant problem, and something we want to protect against IN DEPTH (see all the SSL/TLS version rollback problems that are components of other attacks).
• A Creation Date would not fill the same purpose, since, as you say, there is no guarantee that others will see it. An attacker can stop publication of the new Client Profile OR just stop it from being used in the Client Profile. The expiry means that there's strict limit on the time for when a signature is valid. You could theoretically do this with Creation Dates too, by saying the limit is exactly two weeks after the creation date. But that's the same thing as putting in an Expiry, and having Creation Dates doesn't give us anything by itself.
• The lifetime of the public key is exactly the same as the lifetime of the Client Profile. If you have no valid Client Profile available for a specific public key, that public key should be treated as invalid. We should probably add something to the spec about this. But yeah, the example of the GPG key is very similar. The public key itself doesn't have a expiry. Instead, there are other, associated packages that contain expiry information, and those packages are signed with the public key. That's how you can change the Expiry information for a GPG public key. This Client Profile method is very very similar.

Hope that clarifies things.

[cobratbq]

I think things are clear now. Thanks for the explanations. I'll need to progress with the implementation now and see if I run into more questions. :-)

[claucece]

That is great! Thanks very much @cobratbq for bringing these questions. I'll keep this open until the ADR around the Client Profile is updated :)