Proposal #1 B Confidentiality Sam Smith

[SmithSamuelM]

This for questions and continued discussion about the continuation of proposal #1 which is expanded to include a confidentiality overlay in addition to an authenticity overlay.

Here is link to the slides

Some topics from the slides

• Why use overlays for the TSP
  • Wither destinations in messages using authenticity overlay

-The properties of a strong confidentiality overlay

• End-Viewability (at-end-only) as dual of End-Verifiability

  • How these can be overlaid together

• Trust-Bases

  • Given an interaction can have messages with identifiers from different trust bases does it make sense to support different types of trust bases. Does this not lead to lowest common denominator weak trust.

  • Appraisable trust bases

[Willem-de-kok]

In the presentation at the slide 'ToIP Design Goals' you express that the ToIP goals are authenticity, confidentiality and privacy and you say: 'Thus the design goal is to achieve these three properties in the order listed.'

1. Do you mean that the design goal of the TSP is to achieve these three properties in the order listed?

Furthermore, you say that authenticity and confidentiality are a cold war, whereas privacy is a hot war. Does this imply that the privacy matter (i.e. will the expectations of each party with respect to the usage of shared information be honored by the other parties?) should be taken into account in the TSP? Or do privacy matters belong to in ToIP layer 3?

[SmithSamuelM]

In my opinion, the three properties, authenticity, confidentiality, and privacy inhabit a trade-space. I have posited the PAC theorem (trilemma) that states one can have any two of the three (privacy, authenticity, confidentialty) at the highest level but not all three. One must make a trade-off. The ordering of the ToIP design goals reflects that trade-off in order of importance we should start with high authenticity, then high confidentiality and then as high as possible privacy given we don't trade off the other two. That does not mean that when constructing a message that the order of layering of authenticity, confidentiality, and privacy mechanism or components should follow that same order. This I believe is a source of much confusion and one of the reasons I created the slides on overlay spirals to illustrate that distinction.

There are also two fundamentally different but complementary definitions of privacy. The ToIP definition is about the recipient respecting the data privacy concerns of the sender with respect to the content disclosed to the receiver. This may be achieved independently of how private the communications channel was that resulted in the receiver getting a disclosure of said content. For example a well-known concept called chain-link confidentiality (first published in a law review paper in 2012) details how one can protect the data privacy concerns of the sender via contractual confidentiality law. ACDCs use the well-known Riccardian contract formalism to support chain-link-confidential through what we call contractually protected disclosure. This type of privacy protection feels like layer 3 or 4.

On the other hand, my analogy of privacy to a hot war refers to something else entirely, the exploitable correlatabilty of identifiers used to convey information over a communications channel. In the sense of the PAC theorem, where privacy is about correlatability of identifiers the trade space can be pretty harsh especially in a theoretical sense, but when privacy is qualified as exploitable correlatability (with respect to a given attacker) we have a much gentler trade-off. The responsibility for protecting the privacy of the sender's identifer (as exploitable correlatability of the sender's identifier) in a communication is primarily on the sender (but once the receiver has it, it must respect the data privacy rights of the sender wrt the further use of that identifier). The responsibility for protecting the privacy of the receiver's identifier (as exploitable correlatability of the receiver's identifier) may be shared by both the sender and receiver.
Somewhere in the full spiral of out of band setup, in band setup the receiver indicates to the sender how to address, route, and convey the communication so that it will be actually received by the receiver. So the sender must respect the receivers requirements when expressed. In many cases the receiver makes no such requirements (full public reciever) so there is no responsbility on the sender to protect the privacy of the receiver's identifier(s) used for addressing, routing, and conveying the information. The sender just needs to protect its own identifiers and content. Off course the sender might not be able to protect itself unless the receiver cooperates by supporting the conveyance of information in a way that protects the sender.

These are all subjective considerations until we examine what practically can be done given existing tooling. My goal is to explicate rigorously what can be done and the trade-offs and then select the best approach or approaches given those trade-offs.

Circling back:
The reason authenticity and confidentiality are analogous to a cold war is that we have existing tooling that enables cost-effective cryptographic strength authenticity (as in end-verifiable attributabillty to an AID) via digital signatures and cost-effective cryptographic strength confidentiality (as in secure end only viewability by an AID) via asymmetric en-de-cryption. This strength is such that attack is computational infeasible against the crypto and the only weakness is in the strength of the key managemet of the associated key pairs. So there need be no casualties in this cold war. The only looming vulnerabilty is that a secret weapon might be developed (aka a quantum computer) which would break the existing crypto. But given that we now have quantum safe, signatures and asymmetric encryption, as long as the key management system is sufficiently agile and post-quantum proof (like KERI), it will remain a cold war because one just switches to the quantum safe crypto once someone as built a quantum computer capable of breaking the existing crypto.

The reason privacy (as exploitable correlatability of identifiers) is a hot war is that casualties are unavoidable, its minimizing the casualities and the resources so as to not lose the war and the tactics and techniques and resources and incentives to expend those resources for correlation are a function of the attacker, hence the qualification, exploitability.

Suppose I want to build a communications channel that is not exploitable via correlation of the identifiers. Because the communications must be routed between to end-points the routing identifiers are an attack surface for correlation. The routing tables are an attack surface. Likewise every intermediary is an attack surface for correlation. The receiver itself is an attack surface for correlation independent of the channel. The sender itself is an attack surface for correlation independent of the channel. The channel defines the boundary between in band and out of band. So if I allow any correlation mechanism from actors with virtually unlimited resources to correlate both in-band and out-of-band there is no solution to the privacy problem. I can always play the equivalent of a trump card that says, here is a way to correlate and so your protocol is broken in terms of privacy.

Another analogy, suppose I am designing a tank and I am trying to select the thickness of the armor for that tank. I can't actually design a practical tank until and unless I scope the types of attacks that the tank must be able to withstand. If I state that one of the attacks is a nuclear bomb, then I have an impossible trade-off because a tank by definition is a type of mobile artillery and armor thick enough to protect against a nuclear bomb would be too heavy to move.

So we have to pareto optimize privacy in a hot war. We can protect against many types of attacks with the limited resources we have. So in resource constrained decision problems we have to make trade-offs and we need to understand the trade-space well if we want to make optimized trade-offs. I have seen little if any quantitiative discussion so far on the actual trade-space. Yet some are ready to jump to conclusions of what the "tanks armor thickness" should be.
Its premature.

[Willem-de-kok]

Thank you for your in-depth reply!

I think it indeed is useful to make a clear statement, for the whole community to be clear, that:
"The ordering of the ToIP design goals w.r.t. authenticity, confidentiality, and privacy is different from the order of layering these three."
To me it is clear now, however I found it hard to grasp from the spiral, because it seemed from every spiral color that one always starts with authenticity, then confidentiality, and then privacy.

Pointing out the different definitions of privacy is helpful. And I would agree that it makes sense to consider whether we should include 'exploitable identifier correlatability' in layer 2. I like that it is your goal is to explicate rigorously what can be done and the trade-offs and then select the best approach or approaches given those trade-offs. @dhh1128 would discussion #26 be good place to write this consideration down?

one just switches to the quantum safe crypto once someone as built a quantum computer capable of breaking the existing crypto. I guess one would, for important messages, switch as early as possible, because the crypto can, of course, also be broken afterwards if encrypted messages/data are stored.

Your explanation of why exploitable identifier correlatability is a hot war makes totally sense. The role of routing thus is a quite important part of privacy and it should be taken into consideration whether it should be in the TSP and when making a trade-off between different protocols. I see you also mentioned the role tunneling could have in routing in Discussion #18. Could it be useful to have a new discussion topic fully considering the role of routing and the trade-offs therein? Or should we somehow also mention it in discussion #26 @dhh1128?

[SmithSamuelM]

@Willem-de-kok

. I guess one would, for important messages, switch as early as possible, because the crypto can, of course, also be broken afterwards if encrypted messages/data are stored.

Cryptographic strength symmetric crypto is already post-quantum safe so X25519 is already good. So the main use case for asymmetric crypto is to transmit the content with secure end-only viewability. Once the end has it, that end can store it by re-encrypting using symmetric encryption thereby making the storage post-quantum safe. So really don't have to switch now.

The reason asymmetric crypto is not post-quantum safe is not the encryption per se, but because the public encryption key can be inverted to get the private decryption key directly without breaking the actual encryption.

So symmetric encryption to one's self and asymmetric when moving to someone else who then symmetrically re-encrypts to themselves. Symmetric encryption between two parties means that there is a shared secret so each party must trust the other party that they have not shared the shared secret with an attacker. The security of any party in a shared secret exchange is no greater than the security of the weakest party to that exchange. A receiver has no control over the security of the sender so a receiver is better protected if they only accept asymmetrically encrypted packets from the sender. Then no shared secrets.

[SmithSamuelM]

@Willem-de-kok I only had time to make one spiral diagram. But I did put clearly on the slide that the entry and exit point to the spiral is setup dependent Which means some setups might enter differently thereby producing a different ordering. And if you follow the spirals they don't stop at every axis everytime so that also changes the ordering

[Willem-de-kok]

You are right, there is a lot of information, but there is the risk of me interpreting it in multiple (potentially incorrect) ways.

Could you clarify the spiral diagram a bit more:

• Could you clarify whether the spiral could rotate anti-clockwise? (Which is equal to rotating clockwise while surpassing two or three steps every time)
• What is your definition of availability?
• How does availability relate to authenticity, confidentiality and privacy?

[SmithSamuelM]

@Willem-de-kok

Could you clarify whether the spiral could rotate anti-clockwise? (Which is equal to rotating clockwise while surpassing two or three steps every time)

Yes they are equivalent. You can skip any set of axes in any loop around the spiral.

What is your definition of availability?

I believe I am using the usual IT security definition, information should be consistently and readily accessible for authorized parties

How does availability relate to authenticity, confidentiality and privacy?

Availability can be neutral, increase, or decrease authenticy, confidentiality and privacy. Its not a forced trade. We can therefore leverage availability mechanisms to add additional authenticity, confidentiality, and privacy stops (or not).

One common availability mechanism is to provide an always-on continuously network connected service endpoint as a store and forward host for an end device that is not always on or continuously connected to the network. Similarly a higher availability mechanism could be a redundant pool of replicants hosts that are more fault tolerant (i.e. higher availability in the presence of faults) than a single store and forward host. Another availability mechansim could be a load balancer or load balanced firewall. The latter filters traffic whereas the former may not filter.

For a given sprial path, an availabilty mechanism, ( host or pool ) contitutes an itr ( intermediary) in the diagram that sits between the two end devices labeled src (source) at one end and dst (destination) at the other end.

If the intermediary is untrusted then it may only have a stop at availabilty but not authenticity, confidentiality, or privacy (ACP).

If the intermediary is trusted then it may contribute positively to ACP.

For example, a VPN, as intermediary can wrap a given message with another layer of confidentiality which may make any plain text identifiers in the original message, private wrt to third parties. In KERI, a witness pool, receipts (endorses) events with a threshold structure which can be used to significantly increase the strength of the authenticity.

A malicious intermediary may provide multiple loci of attack for privacy via the surveillance of identifiers. A malicious intermediary may engage in a deletion or partial deletion attack on the message in transit.

Furthermore, the setup of a trusted intermediary may add some more out-of-band and/or in-band stops. This means that with intermediaries, the spiral path may have multiple out-of-band excursions.

The point of the diagram is explicity consider all setups OOB and IB in addition to any IB TX (in-band transmission) mechanisms embedded in the packet of all stops along the path to order to better understand the total security properties as well the trade-offs wrt PAC. Only then can we make informed comparisons between protocols.

[Willem-de-kok]

I find this response extremely useful. Your explanation is really helpful in achieving the goal of why you made the spiral diagram, namely you helped me (and probably others) to better understand the total security properties as well the trade-offs wrt PAC. Thank you!