Replacing master/slave terminology

[Jeffrey Altman]

On 6/10/2020 5:26 PM, Nate Coraor (nate at bx.psu.edu) wrote:
> On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <ghudson at mit.edu> wrote:
> 
>> MIT krb5 switched to using "replica" for non-primary KDCs as of release
>> 1.17.  This was an easy change technically, as the old term was only
>> used in a user-visible way in documentation and in the name of one
>> profile relation.  The pull request for that change was here:
>> https://github.com/krb5/krb5/pull/851
> 
> 
> Hi Greg,
> 
> This is fantastic and encouraging news, thanks! I'm not sure how I missed
> this. If I can find the time I'll see if it'd be as simple for Heimdal, or
> perhaps someone from the Heimdal side will chime in. In specific, iprop
> uses "slave" even more prominently than kprop did, I believe.

For Heimdal, the term "slave" is part of the both the iprop process name
and command line switches for the iprop_master.  Changing these could
adversely impact end user deployments that are not expecting their
configuration scripts and packaging to break.

>> Replacing the term "master" is a larger technical challenge.  We use
>> that term in a DNS SRV record label (_master_kdc), and migrating that
>> would come with a cost in network traffic and latency.  Aside from the
>> kprop architecture, we also use the term "master key" to describe the
>> key used to encrypt long-term keys in the KDC database.
>>

Changing the name in DNS SRV records is really untenable.  The impact on
end user organizations would be significant.  The support for master_kdc
lookups and configuration parsing could not be removed because doing so
would result in interop failures.  Likewise end user organizations would
be required to publish both the new record and the old.

> Technical considerations are certainly factors. I wonder if it'd be
> reasonable to allow clients to specify a preference when performing the SRV
> record lookup?

Not really.  It doesn't change anything other than adding a new
configuration option that must reference the "master_kdc" service name
in its documentation.

As a real world example, in 2011 the IETF deprecated the use of AFSDB
records in favor of SRV records for AFS services.  This was an official
standardization action that took more than a year to complete.  It has
been nearly a decade and by my most recent inventory nearly 2/3 of AFS
cells are still configured with AFSDB records and only 40% have SRV
records.  Approximately five percent support both.  As a result it has
been impossible to even consider removing the support for AFSDB records
and the additional delays that result from trying one and falling back
to the other.

> I have rationalized to myself that the term "master" is the less
>> problematic of the two terms, as it is used in a lot of different
>> contexts (such as physical master keys, martial arts masters, master
>> plumbers, and master recordings of records).  But I don't know if that
>> rationalization is adequate; from recent discussion I know that git's
>> use of "master" for the initial default branch name has become a point
>> of contention.
>> 
> I largely agree here, it's less problematic. I do think it'd be preferable
> to refer to the "master" server as e.g. "primary", but master key seems
> fine as it has an established unencumbered meaning.

The term "master" applies to the database not the server.   The question
is whether or not the answer to a query is definitive.  All of the KDCs
can serve data from the "master" database.   The client needs to know
that it should retry against another server when it can determine that
the database isn't a "master" as a noun; its "master" as an adjective.
Where the use of "master" indicates being an expert, principal or
instructor.

Heimdal's documentation should be rewritten to remove the master-slave
relationship.  If and when there is ever a volunteer to perform that
work along with all of the other changes that Heimdal's documentation
requires I will happily merge the pull request.

Jeffrey Altman



-------------- 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/20200610/4692e9ab/attachment-0001.bin