Re: [kitten] Finding Kerberos Realm Descriptors in secure DNS

[Nico Williams <[e-mail]>]

On Tue, Sep 15, 2015 at 09:41:12AM +0200, Rick van Rein wrote:
> > Text strings used to be handy for realm names in DNS when associated
> > SRV records were plausibly optional.  These days, the REALM *should*
> > be a DNS name.
> 
> If that's not MUST then I don't think it's a safe assumption to make.

If you want to use DNS then you must be using DOMAIN-style realm names.
That's a fair requirement to make.

> > Therefore, a simpler design would be:
> >
> >     ; Realm mapping per-host reduces lookup latency
> >     ;
> >     _kerberos.host.name.example.com. IN PTR EXAMPLE.COM.
> 
> The value of PTR is a <domain-name> rather than a binary
> <character-string>, which makes it case-insensitive and I wouldn't be
> surprised if some name server mangled the case of PTR records to
> all-lowercase.

DNS is case-insensitive for QNames, and preserves their case in the
answer section, but not in any RDATAs in the response.

> Also, the trailing dot is not the only form that may be used; there
> can be relative names.

Relative to what?  The QName?  Wouldn't that be a form of compression?
DNS already knows how to compress domainnames in PTR RDATAs, (there
won't be so many answers and additional RRs that compression will be
meaningful, so relative realm names could be potentially useful, but
probably not enough to be something we should drop Viktor's proposal
for).

> And, you are using PTR in forward DNS, which may upset people.

"Meh".  I don't think it will be a problem.

> Finally, the PTR record already has its meaning, and that is not the
> one we have in mind.  The new RRtype can be hard and clear about its
> meaning for Kerberos, and avoid security questions relating to the use
> of certain records.

STD 13 doesn't restrict PTR as you think.  It doesn't even limit the
number of PTR RRs in an answer to one (though all getnameinfo()/similar
implementations always expect only one answer and use only the first).

> I've initially proposed overloading TXT and that gave strong responses

Yes, that was predictable :)

> to instead register a new RRtype, and nobody on DNSEXT is questioning
> that change.  I therefore propose to not follow your idea.  It made me
> smile though, because it is an interesting find.

Lack of objection doesn't mean they reviewed and approved.  And KITTEN
WG's consensus is still needed, and we're free to have objections that
DNSEXT didn't.

Nico
--