[OpenID4VP] response encrypted

[peppelinux]

Is there a security analysis done in our context? It seams to me that this is a security requirement but I think that it requires further investigations, unless you already have some documentation. In this case, share it please.

Originally posted by @fmarino-ipzs in #31 (comment)

[peppelinux]

good catch, a security analysis is required on the encrypted vp_token response, why it is a requirement and how it could not be a requirement

[Sakurann]

The argument for encryption I have heard in the context of an ISO profile of OpenID4VP for mdocs (23220-4) is "TLS is not sufficient because what if TLS ends at the peripheral of the verifier's system and response is pass unencrypted between multiple components within the verifier's system before it reaches target application that wants to consume mdoc/data". Which IMO is about verifier's internal system...

[NetBender]

While a proper security analysis still needs to be performed, I can add that the motivations provided within the “Why the response is encrypted?” note are not correct.
SSL split it not an attack, but a technique designed in 2003 for circumventing a security requirement established in SSL 3.0 - a protocol that was deprecated in 2015 - in order to permit the transmission of plaintext payloads. In order for this security flaw to be implemented, the server administrator must bind the webserver to a modified version of the OpenSSL library that enables it. Given that, the technique described in the article is inapplicable to TLS without the Wallet Provider complicity, as both the Wallet Instance and the Verifier should agree on the use of a cipher suite that does not guarantee confidentiality.

Additionally, the note asserts that the SSL split could:

1. “be enabled by malicious app installed locally by users that intercepts the network traffic”

This is only possible if the device contains a malicious app running with root privileges that can access private memory regions of other apps.

2. (be performed) “in network environments where a next-generation firewalls or other security devices may reduce the privacy of the Users”

As mentioned by @Sakurann, there exists a technique known as "TLS termination". It involves the use of a termination proxy which pretends to be the target webserver and manages any TLS-related operations. By doing so, the proxy deciphers the transmission's content and forwards it either in plaintext or by negotiating an internal TLS session with the actual webserver's intended target. In the first scenario, precautions must be taken because any malicious actor within the network segment could sniff the transmitted data and obtain sensitive information, such as the unencrypted response.

CC @giadas @fmarino-ipzs

[peppelinux]

@NetBender can you provide a pull request with the correct text to be added/changed in that note about the security considerations?

It would be amazing having you in the formal contributors of this specs

[peppelinux]

Closed by #72