You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #15, the MP-SPDZ Version is changed to v0.2.8 which introduces TLS-secured communication between MP-SPDZ Clients (=ephemeral) and the MP-SPDZ Process.
The way the PR adds this is really rudimentary and insecure (e.g. the option InsecureSkipVerify is set to bypass certificate validation).
We will need to think about some points regarding the TLS connection:
Who will create certificates (and re-created them when expired)?
Types of connections
Ephemeral <-> MP-SPDZ Process (for transmitting secret shares/results)
Cross-Cloud MP-SPDZ instances (for computation)
Will we continue using self-signed certificates or have a way to provide certifactes signed by CAs?
Can we provide certificate using e.g. K8s Secrets instead of baking them into the base-image (do some parts of our infrastructure like Istio/Knative already provide some functionality for this here?)
The text was updated successfully, but these errors were encountered:
As discussed on Discord, the way to go is to make TLS channels optional in upstream MP-SPDZ and have authenticated channels implemented via Istio mechanisms.
In #15, the MP-SPDZ Version is changed to
v0.2.8
which introduces TLS-secured communication between MP-SPDZ Clients (=ephemeral) and the MP-SPDZ Process.The way the PR adds this is really rudimentary and insecure (e.g. the option
InsecureSkipVerify
is set to bypass certificate validation).We will need to think about some points regarding the TLS connection:
Types of connections
The text was updated successfully, but these errors were encountered: