[erlang-questions] TLS Distribution Certificate Strategy

[Fred Dushin]

> On Apr 20, 2018, at 9:57 AM, Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:
> 
> Hello list!
> 
> I am working on the task to get Erlang Distribution over TLS to be easy to
> use and flexible. :-/

Lucky you!

> 
> 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.

How does the connecting (client) node tell the server its own name (say, in the non-TLS use case).  Is this part of the disterl protocol?  I would think it has to be, and not some magic conjured by the underlying TCP or TLS protocol.

(Sorry, I don't currently have time to dig into the code and research this myself)

> 
> 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 we are talking about the disterl protocol, I would keep it to node names, and keep host names out of it.  There is no guarantee that two nodes would be running on the same host (Riak devrels!), where each has different security requirements.  (to your flexibility point)  I also think host names are impossible to manage, no less manage securely, whereas presumably node names are under some semblance of control by the application, and therefore hopefully the application operator.  Host names might be managed by other teams in distant lands.

> 
> 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.

"there seems to be agreement"

Well, not universally.  I can get on my soap box and say why hostname validation is a hoax, if you like :)

> 
> 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.

^^ common in most TLS deployments, but only for server certs, i.e., when clients authenticate servers.  I think authenticating clients via DNs or SubjectAltNames is somewhat non-standard, but useful.  I would NOT use a hostname in that case, however (to the same point above).

I would say that if you trust the client, via whatever ordinary PKIX certificate chain validation at your disposal, the additional requirement of matching the CN with the node name could be an onerous burden, when the node name is already published over the disterl protocol, and is therefore shipped over an authenticated/trustorthy channel.  What sort of attack would you be thwarting, by adding that requirement?


> * 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.

yes, 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?

I believe there is just a URI type for SubjectAltName

https://tools.ietf.org/html/rfc5280#section-4.2.1.6

> 
> 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?

I think a reference architecture, that includes TLS-enabling epmd, and the disterl communication paths between nodes, would be good. I mean, I have a sense of what that is, but it is likely incomplete and has holes.  So having a document that states or illustrates use cases would be helpful.  Is there a platform for collaboration on this?

> And what is appropriate for Cloud services?

I think cloud services are going to be a special case of enterprise (when cloud == IAAS).  I don't think we are talking about PAAS, are we?  (I wish!)  As such, I think most PKI deployments will resemble the kind of thing you see (or should see) in a enterprise deployment, though perhaps at a slightly larger scale, depending on the growth trajectory of the folks paying the cloud bill.

> 
> Anyone with an opinion and insight, please speak up!
> 
> Best Regards
> -- 
> 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions