control: support transport layer security for intra-AS connectivity

[marcfrei]

To guarantee privacy, integrity, and authenticity of the DRKey-related RPCs, TLS should be enabled for the intra-AS control-plane APIs of the control service.

[oncilla]

Instead of integrating this functionally in the control service, you could also expose the control service functionality behind a reverse proxy (e.g. caddy) that can deal with AuthN/AuthZ. Then you also get TLS certificate management for free

[JordiSubira]

Definitely possible to offload some part of the PKI related staff to the reverse proxy. At the end, we need/want some form of client authorization for the different request types, i.e. we need at some point to map the client identifier (whatever we use, currently it's its address) to the request they can issue. Even if we add the reverse proxy, we need to embed this logic either in the proxy, or convey some information from the reverse proxy to the CS which will use the proxy as some "identification service". We can try to write some deployment proposals for this.

[marcfrei]

Re TLS certificate management we also have to decide whether we want to rely on the Web-PKI or whether we would leverage the TRCs for this purpose too, right?

[JordiSubira]

Yes, indeed. We should decide on what PKI to use, something which is AS specific could work as well, relying that there's some type of Domain Controller and some sort of certificate distribution per host.