[erlang-questions] TLS Distribution Certificate Strategy

[Raimo Niskanen]

Hello list!

I am working on the task to get Erlang Distribution over TLS to be easy to
use and flexible. :-/

So far I have tried to read up on the subject and messed up by misusing
server_name_indication in inet_tls_dist.erl...

The distribution protocol in itself has got two roles - the client and the
server role.  When node A connects to node B then A is the client
and B is the server.  All nodes are servers and any node can also be a
client.

When a node is client we can use the options [{verify,verify_peer},
{verify_fun,{VerifyFun,Data}}].  Then VerifyFun can verify that the
certificate is valid for the Node we connect to.  Remains to get the Node
variable into the VerifyFun arguments - getting to that.

When a node is server it is not possible to know which node that connects
until after the TLS connection is up and while the ditribution handshake is
performed.  The there is a step to check that the connecting node is on the
allowed list.  This step takes a list of allowed nodes that currently is a
net_kernel configuration parameter that can be modified by e.g
inet_tls_dist.  We can use that.

So this boils down to parsing the certificate for a node name or a list
thereof.  My goal is that there should be a plugin function that does
exactly that, that one can customize.

An additional question about that certificate parsing function is whether
it should return node name(s) or host name(s).  Should a certificate be per
node or per host or should both be possible?

If a node certificate should contain host name(s) there seems to be
agreement on that one could put this in the certificate's Subject field as
a DistinguishedName containing a CommonName being the host name, or in an
Extension subjectAltName containing a dNSName.

If a node certificate should contain node name(s) I only have some
half-good suggestions:
* Store a node name node@REDACTED as a host name node.example.org in
  either of the above ways, i.e replace the `@` with `.`.
* Store the node name as a CommonName as it is, either in DistinguishedName
  or in an Exension subjectAltName containing a directoryName that is
  another CommonName.
* Use the DomainComponent field in DistinguishedName, multiple times, and
  CommonName for the node name as in "/DC=com=DC=example/CN=node".  I think
  this maybe according to the standard's intent, but very odd.
* There are lots of esoteric fields to use in a certificate, for example
  the Extension subjectAltName EmailAddress that syntactically fits a node
  name, but would that not be misuse?

Related questions are: what kind of certificates can you get issued and do
you want to use regular web certificates for this purpose?  Should it be
possible to use Let's Encrypt certificates for nodes/hosts in a cluster
(you would need a node whitelist for this use case i guess)?  For a cluster
we can create tools that create local certificates, with any of the above
content, but how general should the distribution protocol validation be?

So what do people want?
And what is appropriate for Cloud services?

Anyone with an opinion and insight, please speak up!

Best Regards
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB