security section updates

README.md

@@ -1,6 +1,6 @@
 # Transport Layer Security (TLS) Authentication with Verifiable Credential (VC)
 
-This is the working area for the individual Internet-Draft, "draft-vesco-vcauthtls".
+This is the working area for the Internet-Draft, "draft-vesco-vcauthtls".
 
 * [Editor's Copy](https://Cybersecurity-LINKS.github.io/draft-vesco-vcauthtls/#go.draft-vesco-vcauthtls.html)
 * [Datatracker Page](https://datatracker.ietf.org/doc/draft-vesco-vcauthtls)
@@ -14,7 +14,7 @@ See the
 [guidelines for contributions](https://github.com/Cybersecurity-LINKS/draft-vesco-vcauthtls/blob/main/CONTRIBUTING.md).
 
 Contributions can be made by creating pull requests.
-The GitHub interface supports creating pull requests using the Edit (✏) button.
+The GitHub interface supports creating pull requests using the Edit button.
 
 
 ## Command Line Usage
@@ -28,3 +28,11 @@ $ make
 Command line usage requires that you have the necessary software installed.  See
 [the instructions](https://github.com/martinthomson/i-d-template/blob/main/doc/SETUP.md).
 
+# Running Code
+The implementation of this technical specification is available on GitHub
+
+**OpenSSL** with proper modification to work with VCs and DIDs 
+https://github.com/Cybersecurity-LINKS/openssl
+
+**Provider** implementing the required SSI functions
+https://github.com/Cybersecurity-LINKS/openssl-ssi-provider

draft-vesco-vcauthtls.md

@@ -36,8 +36,10 @@ author:
     email: [email protected]
 
 normative:
-    RFC8446:
+    RFC5996:
+    RFC6071:
     RFC7250:
+    RFC8446:
 
 informative:
       DID:
@@ -410,7 +412,8 @@ DLT          Client                                              Server
 All the security considerations presented in {{RFC8446}} applies to this document as well.
 Further considerations can be made on the DID resolution process. Assuming that a DID resolution is performed in clear, a man-in-the-middle could impersonate the DLT node, forge a DID Document containing the authenticating endpoint's DID, associate it with a key pair that he owns, and then return it to the DID resolver. Thus, the attacker is able to compute a valid CertificateVerify message by possessing the long term private key. In practice, the man-in-the-middle attacker breaks in transit the immutability feature provided by the DLT, i.e. the RoT for the public keys.
 A possible solution to this attack is to esthablish a TLS channel towards the DLT node and authenticate only the latter to rely on the received data. The DLT node MUST be authenticated through an X.509 certificate. The session resumption and 0 round-trip time (0-RTT) features of TLS 1.3 can be used to reduce the overhead of establishing this TLS channel.
-In addition, since confidentiality is not a requirement for DID resolution, another solution is to configure the DLT node to sign the replies such that the DID resolver can verify the origin and the integrity of the data received.
+In addition, the communication with the DLT node can be protected with Internet Protocol Security
+(IPsec) {{RFC6071}} and Internet Key Exchange (IKE) {{RFC5996}} in endpoint-to-endpoint transport mode for even better performance in term of latency of DID resolution.
 
 
 # IANA Considerations
@@ -423,4 +426,4 @@ To be addressed
 # Acknowledgments
 {:numbered="false"}
 
-We would like to thank Nicola Tuveri for his very helpful suggestions in the preparation of the first version of this document.
+We would like to thank Nicola Tuveri for his very helpful suggestions during the preparation of the first version of this technical specification.