rdns, past and future

[Jeffrey Altman]

On 5/26/2020 6:31 PM, Ken Dreyer wrote:
> On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman
> <jaltman at secure-endpoints.com> wrote:
>>
>>  2. Before the existence of DNS SRV records, CNAME records were the
>>     only method of offering a service on multiple hosts.  However,
>>     its a poor idea to share the same key across all of the hosts.
> 
> I'm curious about this. What makes it a poor idea?
> 
> It seems like a very convenient way to scale a service up and down
> dynamically quickly when you share a key among all instances.

Because if you hack into one of the hosts you now have the key for all
of the hosts.  The holder of the key can forge tickets for any user.
Since the key isn't unique the entire distributed service has to be
shutdown to address the vulnerability.  It is also much harder to trace
where the key was stolen from.

There are scalable approaches to deriving unique keys for Kubernetes but
they aren't pertinent to this thread.

>>     Again, disabling "rdns" by default will break an unknown number
>>     of application clients.
> 
> Sure. My point is that it breaks the other way for modern
> architectures where PTR records will never be under an application
> developer's control. With Kubernetes a service can appear to clients
> to move IPs very quickly. I'm not defending Kubernetes or anything
> here, I'm wildly speculating that maybe breaking with the past is a
> good idea as more applications and developers move in this direction.

My point is that Kubernetes is new, and new deployments can add the
appropriate keys to their default configurations as Red Hat already does
on Fedora and Enterprise Linux.

If you change the hard coded default, then the existing deployed
installations that are relying on that default will silently break.
Since the breakage is on the client side that is being altered without
knowledge of the service administrators, the administrators cannot fix it.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4080 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20200526/551ecb73/attachment-0001.bin