Support for zero round trip secure messaging

[tplooker]

In other popular secure messaging protocols such as signal the ability to send a secure message from the first exchange is a critical feature, this is often referred to in other protocols such as TLS as a zero round trip.

Take the simple example of Alice and Bob in the context of a protocol like signal. Alice has her identity public key (along with some other key material available to her in the signal ecosystem) and Bob, who wants to send her a message can discover this, secure and send her a message for the first time even when Alice is offline.

Even though some of the use-cases in DIDComm messaging will not be based on a single identity public key as to enable contextual separation of communication, I maintain we can still simplify the DID exchange protocol into two steps, whilst maintaining the same features around security.

Note my below example will only detail the simple two party use-case for now, however the architecture holds true even in the event of group messaging.

Discovery/Invitation

When two parties want to establish communication, one party must be willing to provide a mechanism for the other party to use, to start the communication. This phase can be achieved by some form of an invitation, one that can be generated for a particular interaction or one that is re-used for many parties to establish messaging with a single DID.

In all cases, I believe the invitation should simply just be a DID e.g.

did:example:12345

That is to say the above did may have been freshly generated for a pairwise interaction or is a did that is attached and discoverable through some other means.

First Message

When the sending party is in possession of an invitation (a.k.a did), they can elect to create a new did or use an existing one to construct their first encrypted message to the receiving party. The content of this message does not need to be anything related to did exchange, instead it can be the first message of any higher level protocol e.g basic message or credential exchange.

The bi-product of this approach yields the same as did-exchange e.g two parties have exchanged did's and have established a means to communicate securely in future, however it significantly reduces complexity and enables content exchange on the first message.

Below is a crude digram of the "connection establishment".

[tplooker]

Interested in your thoughts @telegramsam @dhh1128 @awoie @kdenhartog

[awoie]

@tplooker that is basically how our uport 1.0 protocol worked (with encryption enabled). the user scanned a qr code that contained a DID + higher protocol message (e.g., credentials request) + key agreement key (was not included in the did doc). the sending party in that case is the user that sent the credentials exchange response using the approach you described. the user's did was in the response. i am supporting this proposal as i don't see any security implications and it makes the protocol simpler.

[dhh1128]

I don't think this is crazy. There might be use cases for it. However, I think the analysis needs deeper thought. I don't agree that it is equally secure, and I don't believe it is suitable for general use.

The invitation has to be delivered in a secure manner, but there is no such guarantee here. Furthermore, shifting the burden of securely delivering the invitation onto the transport (e.g., HTTPS) loses the the transport independence of DIDComm and undermines the ability of either party to interpose arbitrary relays that change the transport. If delivery of the invitation is insecure, then any observer knows the DID of half of the relationship. This is less secure than DID exchange.

A relationship that uses a public DID on one side and a pairwise DID on the other is inherently more fragile, because the holder of the public DID is sharing keys across N relationships instead of across 1 relationship. If the key is compromised, N relationships are impacted. It is a bigger hacking target. And there are now N conversations where the encryption keys for that public DID are used, instead of just 1.

We had extensive conversations about DID exchange being susceptible to a MITM attack, and concluded that the remediation would be to challenge your new connection to prove identity with credentials. Unless the response here includes a VC-based proof, the same MITM issue arises, which means that the interaction generates progress on a protocol, but with an unknown party on the other side. And for the response to include a VC-based proof, the invitation must include a nonce (proof request), or the response could embody a replay attack.

[OR13]

This proposal sounds good to me.

Related:

• https://blog.cloudflare.com/introducing-0-rtt/
• https://www.securemessagingapps.com/

I think we need to be clearer about the messages and the encryption used, so that it's clear that this works over insecure channels... as signal does.

[swcurran]

We've just substantially revised the invitation process in the Aries WG for DIDComm to a pair of Out of Band protocols which includes only the invitation process and that combines with an evolved DID Exchange protocol. There are a couple of PRs pending for DID Exchange to complete the DID Exchange revisions.

The drivers for the evolution that I don't think are covered by what Tobias proposes above.

• Versioning of protocols. We changed from a protocol-version-specific invitation to one that allows the inviter to list the set of protocols supported. This eliminates the lock-step upgrade of interacting parties. I would add that in Aries we have lots of experience with multiple independently developed agents in the wild and the need to avoid lock-step upgrades is the biggest issue we have.
• Id on the invitation for context. The inviter at least will want to know the context of the connection establishment, so they know what to do next in the interaction. The purpose of the invitation is rarely (ever?) to just connect, but rather to connect and to do something after. An ID from the invitation could be useful to provide that context. Even the response to a general purpose invitation will need context in some use cases.
• Reuse of connections. When a user goes to a site and is greeted with a QR code that they have used before, they want the option to respond with a connection they already have, and not create a new one. Unless everyone has just one DID, this is necessary.
• Confirmation of DID Exchange. We added a confirmation message to DID Exchange ("complete") because of difficulties in coordinating when a connection was complete and could be used. Our first try (the "connections" protocol) had challenges for developers and in practice because it just provided the guidance of "send something after to confirm the connection".
• Connection-less interactions. A second out of band protocol enables support of a one-time interaction with an out of band request and a secure response.

I would also add that I believe we have to support the option for each party to create a DID for the purpose of a connection with another party. This is not possible in the proposed process, and so options must be available for parties to express they need additional messages to establish the connection. When a connection is reused, there is no need for extra messages.

Finally, in the DID exchange process, it is acknowledged that when a DID is known, the process can start at the "request" message (initial message from the invitee to inviter) and no invitation is needed. That is the equivalent of Tobias' "just send the DID". But again, that does risk a protocol version mismatch that must be negotiated.

[TelegramSam]

I think we can solve swapping to a new DID and reuse under a 0rtt model if we need to. Protocol negotiation is made slightly easier if we can run discovery very quickly. ID for context is super useful, but I think also solvable. My biggest concern is that the changes needed to support this will degrade the desired properties of DIDComm in unacceptable ways. I think the next step is to determine and evaluate which pieces of information will be visible to an observer.

[TelegramSam]

To clarify: I believe @tplooker intends that peer dids can be used as the invitation DID (maybe did:key + endpoint info in initial-values?) not just a public DID.

[tplooker]

@TelegramSam correct if you were using a did that were not registered on a ledger, or await this to be resolvable (i.e like in ion). The invitation would just be did:example:12345;initial-values=<bs64>.

[tplooker]

@swcurran, see below for answers to your points

Versioning of protocols I believe all of this can be accomplished through information in the did document, this acts as the the source of determining protocol version.

Id on the invitation for context If you wanted contextual awareness when it came to identifying who responded to what invite, if the did you created was just for that invite, then does the did not give you the same uniqueness as the invitation id?

Reuse of connections If parties are identified through did's I don't see how this is a problem you either receive an invite or a message from a party you know (e.g you recognise the did), hence you then respond with a did they are likely to know based on prior interactions.

Confirmation of DID Exchange You could have a similar mechanism with this approach if you as the sender of the first message would like to know if the receiving party got it.

Connection-less interactions I believe this approach really closes the gaps between how interactions occur between dids that are said to have connections and interactions that are more ephemeral in nature.

[tplooker]

@awoie precisely I think there are lots of valid flows like that, in essence that is how we achieved the vc-authn-oidc stuff.

[tplooker]

@dhh1128

I don't think this is crazy. There might be use cases for it. However, I think the analysis needs deeper thought. I don't agree that it is equally secure, and I don't believe it is suitable for general use.

Fair enough I think it is a good discussion topic for the next call.

I understand your scepticism but it depends what is passed in the invitation, if it is just a DID I don't find this particularly sensitive. DID's are just identifiers and they are only correlated to the extent you use them in ways that can be correlated.

A relationship that uses a public DID on one side and a pairwise DID on the other is inherently more fragile, because the holder of the public DID is sharing keys across N relationships instead of across 1 relationship. If the key is compromised, N relationships are impacted. It is a bigger hacking target. And there are now N conversations where the encryption keys for that public DID are used, instead of just 1.

There are vectors of compromise to consider and it depends on how this compromise occurs.

• If your talking about say brute forcing the (key encryption key) by observing many ciphers across the wire, I think the indirection that DIDs provide and the ability to rotate your key agreement keys mitigates this, plus algorithms like ECDH-1PU adds in a ephemeral key + domain separation via single step KDF which makes this harder again.
• If your talking about a hack in your KMS, then doesn't matter if you had seperate keys for different relationships because they are all compromised anyway.

[dhh1128]

The DID Exchange protocol is conceptually similar to Diffie Hellman, whereby secrets are exchanged by two parties, possibly in the presence of a hostile observer, and the result is a secure session.

Skipping DID Exchange is akin to coming up with an abbreviated form of DH. That may be possible, but we would be VERY foolish to assume we get the same security properties without careful analysis. None of the analysis on this thread so far meets the bar, IMO.

There are vectors of compromise to consider and it depends on how this compromise occurs.

Part of my concern is about compromise. But part of my concern is about simply giving away properties that have nothing to do with compromise of a channel (privacy as opposed to confidentiality; relationship-building; key management-per-relationship behaviors, etc).

f your talking about say brute forcing the (key encryption key) by observing many ciphers across the wire, I think the indirection that DIDs provide and the ability to rotate your key agreement keys mitigates this,

I don't think so. If Amazon uses a public DID with hundreds of millions of customers per day, that's a lot of encrypted samples to analyze, even if they rotate their keys every day.

If your talking about a hack in your KMS, then doesn't matter if you had seperate keys for different relationships because they are all compromised anyway.

You're assuming all keys are stored in a single KMS. I'm not. Anybody who has multiple devices (e.g., servers in Amazon's data center) and who is following best practice of not copying private keys around will not compromise all their keys if one KMS is hacked.

[tplooker]

The DID Exchange protocol is conceptually similar to Diffie Hellman, whereby secrets are exchanged by two parties, possibly in the presence of a hostile observer, and the result is a secure session.

I dont agree, Diffie Hellman is a lower level cryptographic primitive, one we are doing currently on every encryption of every message in DIDComm. I do not agree skipping DID exchange is in anyway skipping Diffie Helman.

I don't think so. If Amazon uses a public DID with hundreds of millions of customers per day, that's a lot of encrypted samples to analyze, even if they rotate their keys every day.

Again I dont agree and I believe the proof lies in the fact that TLS connections (when using secure and or modern crypto) which use long term certs and public keys (typically for session establishment) as do secure messaging protocols like signal do not suffer this issue.

You're assuming all keys are stored in a single KMS. I'm not. Anybody who has multiple devices (e.g., servers in Amazon's data center) and who is following best practice of not copying private keys around will not compromise all their keys if one KMS is hacked.

If you want a single device i.e a phone to be able to represent you in all N of your relationships then it must have access to the appropriate key material for those relationships. Hence you will store all of this key material (either N keys for N relationships or 1 key for N relationships) in the same KMS giving rise to the same attack surface.

[tplooker]

To be clear using the same static public keys in interactions over time can lead to some vulnerabilities and is why signal designed a double ratchet algorithm that gives rise to the properties of post compromise security and perfect forward secrecy, we can take a similar approach to this which eliminates this problem without did exchange

[tplooker]

IMO the approach I have suggested which is to establishing a means in which to securely communicate via messaging is very similar to the approach taken by signal, if instead of using ECDH-1PU we used X3DH as the algorithm for sending of the first message, then transitioned to a double ratchet algorithm for the encryption and decryption of subsequent messages, similar security properties would be achieved, ones I think that have proven sufficiently secure in industry.

[dhh1128]

I do not agree skipping DID exchange is in anyway skipping Diffie Helman.

I didn't say we were skipping DH. I said we're skipping something that accomplishes something similar to DH. I know that we're doing DH internally, but we're doing it with ephemeral keys, so it's not accomplishing the long-term DH effects, only the short-term ones.

if instead of using ECDH-1PU we used X3DH as the algorithm for sending of the first message, then transitioned to a double ratchet algorithm for the encryption and decryption of subsequent messages, similar security properties would be achieved, ones I think that have proven sufficiently secure in industry.

When we have double ratchet, then you can compare what we're doing to Signal. Until then, it's a false parallel. Your proposal didn't include plugging these gaps, so it's an incomplete and unsafe proposal by itself, until upgraded.

Again I dont agree and I believe the proof lies in the fact that TLS connections (when using secure and or modern crypto) which use long term certs and public keys (typically for session establishment) as do secure messaging protocols like signal do not suffer this issue.

TLS negotiates a new session key every time you connect. We're not doing that. The effect of DID keys is a long-term session. All the DH on ephemeral stuff doesn't change that.

[tplooker]

Ok, I guess I should re-phrase to say I don't see the conceptual similarity of DID exchange in reference to Diffie Helman, IMO they are concerned with very different things. Diffie helman is a cryptographic operation that requires you to have the public key of another party and you derive a shared secret using that and your private key. DID exchange is an application level protocol for essentially communicating public keys.

When we have double ratchet, then you can compare what we're doing to Signal. Until then, it's a false parallel. Your proposal didn't include plugging these gaps, so it's an incomplete and unsafe proposal by itself, until upgraded.

Fair enough, however even without the double ratchet, I do not believe DID exchange has any greater security, there may be a body of privacy considerations that need to be addressed, but the security properties I see as being no different.

Your point about using long term public keys in a single did for communication with multiple individuals is not a pattern that is enforced by the approach I have suggested, nor is it one that is outlawed in a model where did exchange is used. That is to say I can create only one did and do did exchange with other parties using that single did and the same security vulnerability you pointed out is present.

[TelegramSam]

Discussed in WG Call 2020-03-30. @tplooker is going to create additional materials discussing the security properties of each message in the flow, and @dhh1128 is going to do the same for DID Exchange.

[dhh1128]

Here is the diagram I produced (click for bigger, editable version). In short, you are guaranteed to have a secure pipe and to not have leaked DIDs, keys, and endpoints to an eavesdropper. You are not guaranteed to know who's on the other side.

[tplooker]

Thanks for this @dhh1128, I have followed your pattern to produce the following.

Zero round trip secure messaging

[dhh1128]

Thank you. This is excellent. Some questions.

1. Do you propose that the workflow always begin with Alice allocating A.did@A:B, or do you also allow A.did@Any (a public DID that isn't allocated with each invitation)?

2. Would you agree that when Alice sends msg 1, she doesn't actually know that she's made the invitation available to Bob -- only that she's sent an invitation and she hopes Bob will receive it?

3. You have removed any mention of signing from msg 1 as compared to the DID Exchange diagram. So how can Bob or Malfoy ever establish that the invite is from Alice, even if it comes with a ledgerized DID?

4. Would you agree that your comments about Bob or Malfoy possibly being able to establish that a DID came from Alice are also true in the DID Exchange protocol? That is, your descriptive verbiage on the right in blue is different than mine but the available context is identical?

5. I think both of us made a mistake in the gray text under msg 2: "this endpoint might make it obvious that the recipient is Alice (or it might not)" is inaccurate, I think. The auth-crypted message is encrypted for Alice's specific key, so even though the endpoint might not make it obvious that Alice is the recipient, the combination of endpoint+key is clearly Alice. Do you agree? This would be true of both protocols.

6. In the gray text under msg 1, you highlight an information leakage that violates the confidentiality guarantee in security's traditional "CIA" definition. If I understand you correctly, you are conceding this leakage but claiming it has no important security consequences, only privacy consequences? Do you agree that this allows an attacker to focus future hacking attempts on a single DID and endpoint if he wants to break into this relationship, instead of of having all possible DIDs and all possible endpoints as hacking targets? Do you agree that by knowing the endpoint, the attacker can observe the timing and size of messages between Alice and Bob, and can mount denial of service attacks that he is sure will impact Alice?

7. Do you believe Signal's protocol has exactly the same security properties as the interaction you are proposing -- or does it have meaningful differences?

[swcurran]

Thanks for presenting the information in this way.

Aside: In the proposed Out of Band protocol just formalized in Aries Working Group, an invitation is not signed. Either that is incorrect in Daniel's drawing (and point 3 in the last post) or this is a new proposal. @dhh1128 are you wanting to add that to the OOB protocol?

It seems to me the differences from DID Exchange to 0rtt boil down to:

1. The permanent DID/DIDDoc for Alice's relationship with "Bob" is put into plaintext. This is a non-issue for public DIDs, but is a change if Alice is using a peer DID.

   • this can be addressed by rotating the key once the relationship is established, but isn't that the same overhead as the response message in the DID Exchange model?
     • Is the argument this is better because a rotation (or even a DID change) can be done as the JWM equivalent of a decorator - e.g. that it can be done as part of the next protocol message from Alice vs. a special purpose message?
   • As an aside, if messages to Alice are going to be routed through a mediator/agency, it's the endpoint mediator DID/key that has to change to prevent detection of messages going to Alice. And, it's quite possible, the mediator's DID/key is public and well-know, allowing messages to Alice to be "lost in the crowd".

2. The OutofBand/DID-Exchange approach provides an explicit Id for the invitation to provide context for the inviter (Alice), as well as some optional data elements (label, purpose) for the invitee ("Bob" or an interceptor).

3. The lack of an explicit Ack from the inviter leaves the mutual state of the connection unknown for both participants. Perhaps that's OK given another protocol has started, but leaving connections in that state has been bothersome in our current implementations.

4. Responsibility for initiating the post connection step has shifted from the inviter to the invitee.

   • in designing DID exchange, we expected the inviter would generally "make the next move" (not required, but common). With the 0rtt approach it is ALWAYS the invitee that makes the first move.
   • How does the inviter know what to do? Will it be typical that the invitee send a message that is simple "Hi, what do you want to do now?" (what we have called "action-menu" in Aries), thus eliminating the 0rtt benefit?

Note that in both cases, when the invitation is a "re-invitation" (e.g. the two parties already have a connection), there is a DID Exchange process short-cut where the invitee responds using an existing connection -- meaning the 0rtt optimization is minimized. Full DID-Exchange is ONLY used on the first exchange, not on subsequent interactions. Further, subsequent non-invitation-triggered interactions can occur with no (re)establishment of a connection -- just one party sending a protocol message to the other. Does this impact the importance of 0rtt vs. say, TLS?

[tplooker]

@dhh1128 see below for some thoughts on your points.

1. Prior to the invitation being sent / made discoverable, the only prerequisite that exists is that a DID exists with sufficient information in it that a party in receipt of the DID can prepare an encrypted message and send it back to the did subject. Whether the DID is created for a particular individual a.k.a just for Bob (e.g A.did@A:B) or it is one that was created months ago and has been used by multiple parties (A.did@any) it should not matter.

2. Correct, I think depending on how the discovery is done or invitation is sent, it is potential that neither party would know for sure who the other party is they are "connecting" with.

3. It depends on the context in which the did is discovered. But in general if you are alluding to the need in some contexts for the inviter to do did auth in order to prevent a potential vector for spam, then I agree.

4. Yeap correct I would say they are identical.

5. The reason I would tease out a distinction here in not being absolute on that particular statement, is the information might uniquely identify someone, but there is no guarantee that the combination of unique information identifies Alice or even that the information represents a person.

6. I don't agree with your assessment entirely, but they are good observations to make. I think we need to be more detailed about how a theoretical attack like this were to occur, i.e where is malfoy positioned in this scenario at a network level? How does he know that A.did@A:B is even alice and or how does he know that B.did@B:A is Bob? DIDs are just identifiers at the end of the day, they could identify a human called alice just as much as they could identify anything.

If the message I send to Alice's endpoint is transport secured your attacker must first be a MITM here, or are you assuming communication with the endpoint is insecure? Are you saying that in your architecture you will rely on the endpoints to ingest messages remain private in order to maintain any level of quality of service? That to me appears to be at odds with how most of the internet functions today and even in the event that a messaging broker (cloud agent) I was using was compromised (i.e becomes known), I could just update my did document to use a new service provider (the beauty of DIDs :))?

7. I believe there is a bit of equivalence and the opportunity for there to be more, but the learnings in how they have designed a solution that has yielded what many regard as one of the most secure messaging protocols in the world while making it highly useable is why I think we should be looking closely at it.

Below is a little blurb on some of the current differences.

In signal rather than the first message being something like ECDH-1PU or box, like in DIDComm v1, which is a double diffie-helman between Alice and Bobs keys plus an ephemeral one generated by the party sending the first encrypted message. X3DH adds in a 3rd diffie-helman (and an optional 4th) to prevent against things like a KCI (key compromise impersonation) attack. See here for more details. To achieve X3DH the changes cryptographically are minor. The main consideration is where the additional keys should be hosted, for example either the signed pre keys would need to feature in the did document (a solution I think is impractical due to the lifetime of the keys) or there would need to be a service endpoint in the did document that would allow a party to download a signed pre-key. The other major difference is the key agreement X3DH is only really used in the first message to setup the ratchets between the two parties, from there ephemeral keys are generated per message and an identifier in the header of each message is included to tell the receiving party what state their ratchet must be in, in order to decrypt the message. This video is a great tutorial on how the protocol works.

[kdenhartog]

After looking at these two, I noticed a pattern between these two. Step 1 is essentially the same which is what provides all confidentiality guarantees (or at least where they would be compromised). Essential what Tobias' proposal does is remove steps 2 and 3 and jumps straight to the second 2 in Daniel's proposal.

This got me thinking, could we define a "rotate-did" protocol which is essentially steps 2 (first 2) and 3 in Daniel's write up? If we did that the question would be should it be optional or required. If it's required we end up with Daniel's writeup (did-exchange), but if it's optional we end up with Tobias' writeup. I think if we move to tobias' proposal then we should define the "rotate-did" part of the protocol, make it clear how it would be included, and recommend it as "SHOULD" for persistent connections (this allows for ephemeral mode to not need to use it).

[TelegramSam]

Kyle, I had a similar thought: 0-RTT is optimized for the situation where you will not be rotating the invitation information. DID Exchange is optimized for the situation where you will be rotating the invitation information.

Another important distinction is that the 0-RTT approach advocates moving ALL relationship maintenance into the 'headers' of the JWM encryption envelope, and out of the content layer. DID Exchange passes relationship maintenance in the content layer. (Relationship maintenance includes DID Doc type updates: key rotations, endpoint updates, DID rotations etc.)

[llorllale]

Interesting thread. And also a thing worthwhile to consider, thanks Tobias.

I keep seeing a mistaken assumption w.r.t. didexchange - that a public DID containing an implicit invitation is the DID that will end up used by the inviter for that connection. Eg. this comment here (towards the end) equates the privacy implications of publishing an implicit invitation in a public DID with the first message in Tobias' proposal. This is incorrect, as in didexchange the inviter MAY switch to a different DID in the response message. -1 for the new proposal in this regard.

Following from the previous point, Tobias claims that sending the inviter's long term identifier in plain text is not "particularly sensitive" and "they are only correlated to the extent you use them in ways that can be correlated". I believe both (somewhat unclear?) statements can apply to didexchange, but the new proposal starts off by explicitely leaking this identifier. This move gives the needle an extra push in the direction of "undesired correlation", necessitating extra protection mechanisms. I'd like to see a deeper study of the impact of this move, but without that this gets a -1 from me.

Ideas like updating the did doc after connection establishment imply extra steps that defeat the purpose of this proposal.

There is some discussion of securing the invitation's delivery by taking advantage of the underlying transport. DIDComm is intended to be agnostic to the transport, thereby allowing easier analysis of the security properties and at the same time enabling the use of arbitrary relays and mediators as mentioned in https://github.com/decentralized-identity/didcomm-messaging/issues/38#issuecomment-604989704. Having security properties intrinsic to DIDComm makes it composable, which is nice. Not having that then we'd have to write up some BCPs and spec out some profiles, etc. Not nice.

[llorllale]

From what I've seen, one key aspect of the signal protocol is the reliance on a trusted server hosting cryptographic material that individual agents publish. This is different than the peer-to-peer model that DIDComm is trying to realize.

Please correct me if I'm wrong on my assertion re: signal protocol servers.

[TelegramSam]

I've attempted to serialize this issue thread into a doc for the purposes of being clear and readable. It is my intention to update that doc as we raise and resolve issues with the proposal. Please use the comment feature to discuss important points

https://hackmd.io/c5PG10XBRnaVaYvwKl0Jig?both

[TelegramSam]

Close in WG Meeting 2020-11-02