Subject: Re: [kitten] Draft Action: draft-vanrein-dnstxt-krb1-01

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Dec 2014 17:14:53 -0500 (EST)

On Mon, 17 Nov 2014, Rick van Rein wrote:

> Hello,
>
> Thanks all for your feedback on the DNS TXT proposal for Kerberos realm names.  I’ve used it for
> http://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-01
>
> CHANGES FROM 00 TO 01:
> * Introduced KREALM RRtype to replace overloading of the TXT RRtype
> * Switched from an ASCII grammar to an ASN.1 grammar for KREALM RDATA
> * Switched from case-independent ASCII values to full UTF8String values
> * Proposed base64 representation in master files for KREALM RDATA
>
> I switched to an ASN.1 format that is easier to process by Kerberos, as well as to give structure.
> Entry in master zone files would be as base64, which is clearly non-optimal, but parsing text isn’t either.
> I don’t know what’s best here, I suppose it’s a matter of taste.
>
> As before, feedback is welcome :) and I will also forward it to DNS lists this time.

I did a fairly quick read and did not spend a whole lot of time trying to
process everything.

My "big-picture" takeaways:

The utility of the concept of a "Home Record" (and related) is not clear
to me.  It seems the document could be shorter if it didn't bother with a
distinction, and I'm not sure what would be lost if it did.  This is not
to say "you should remove them", but if you want to keep them, please help
the reader understand why they are there :)

The general structure seems like a reasonable chunk to bite off at once,
handling a bit more than just realm names, and providing a reasonable
mechanism for future extension.

It does read more like a DNS document than a Kerberos one, so I wonder if
that should be the primary forum for discussion, with consultations to
kitten as needed.

I don't really see anything to mitigate the previous criticisms regarding
the use of the zone apex as a fallback (regarding the potential lack of a
relationship between the zone cut and Kerberos administrative boundaries).

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Tue, 16 Dec 2014 11:08:07 +0100

Hi Benjamin,

> I did a fairly quick read and did not spend a whole lot of time trying to

Thanks, and sorry for the late reply.  It’s that time of year that everything must be finished.

> the reader understand why they are there :)

OK.  Since I’m following the suggestion to define general tag=value setups,
and subsequently proposed an IANA register for tags, I felt a need to
separate these two classes of records.

The idea is a security matter; and should perhaps be explained better.

A record for EXAMPLE.COM situated at example.com has more right
to speak about the realm than a record for EXAMPLE.COM situated
under example.org.  The first is a “home” record, the second would be
a mere reference.  In the second case, when an application needs info
from a "home tag”, it would first resolve example.org to point to the
EXAMPLE.COM realm, then lookup the home record under example.com
and from there harvest the additional tag value.

The general idea being that a “home record” is DNSSEC-signed to be
authoritative for the realm, which is not true for a mere reference.

Does that help?

I am not actually using this distinction in the document, so it is purely for
the sake of the general registry and possible future expansion that it
enables.  I do not believe that it is valid to remove the home record
distinction without also removing the registry of tags.

Whether putting up a registry is useful for future expansion, or merely
added administrative minutia is open for dicussion as far as I’m concerned.
There is definately something to gain from sticking to a fixed set of tags:
simpler syntax, simpler parsing and simpler processing.

> mechanism for future extension.

Glad you like that.  Have I convinced you that future tags might be
specific for references, and/or specific for home records?

> that should be the primary forum for discussion, with consultations to

Agreed.  I still have to post it on DNS OPS.  We’ll see what turns out to
be the most logical place for acceptance.  At some point there may be a
question to Kitten of the order “is this of any use?"

> relationship between the zone cut and Kerberos administrative boundaries).

Please recall that this criticism ended in “I should perhaps read the document”.

But there’s no ideal solution AFAIK — there are only suboptimal alternatives.
Either you actively search upwards, and risk hitting on your parent (both
overloading and trusting it) or you choose to interpret the Start Of Authority
record as a DNS-published boundary to never cross.  In light of DNSSEC
practice which assigns more operational authority to zones, especially
concerning security, I have chosen the last one.

Total avoidance of the search upward would be possible as a null solution;
in that case, you’d end up adding a KREALM record to each and every
A and AAAA record in DNS.  That has its own problems of scale, though,
especially in a DNSSEC-signed world.  The null solution is O(N), searching
up the DNS chain is O(log N), what I am proposing is O(1).

Cheers,
 -Rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Dec 2014 15:03:34 -0500 (EST)

> Thanks, and sorry for the late reply.  It’s that time of year that everything must be finished.

Understood.

> authoritative for the realm, which is not true for a mere reference.

That does help, yes.

> specific for references, and/or specific for home records?

I don't think you have quite convinced me, but neither do I remain
unconvinced.  I would need to think about it for longer than I can right
now (and it's unclear that the issue is important enough for me to spend
that time in the near future).

-Ben