Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

[Nico Williams <[e-mail]>]

On Tue, May 17, 2016 at 12:25:10PM -0400, Jeffrey Altman wrote:
> On 5/17/2016 11:49 AM, Nathaniel McCallum wrote:
> > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
> > -02
> > 
> > I'd like to propose adoption of this draft:
> > 
> > 1. It is in the scope of the WG. This is an extension to the discovery
> > methods already defined in RFC 4120.
> > 
> > 2. It is beneficial. It provides both speed improvments and additional
> > functionality (discovery of MS-KKDCP proxies).
> > 
> > 3. It is small. It avoids defining new: DNS names, DNS semantics, URIs,
> > or transport semantics. It simply combines the existing tools in a
> > fairly obvious way.
> > 
> > Thoughts?
> > 
> 
> Having read the draft I am totally unclear how it is implemented.
> 
>   _kerberos.REALM
> 
> is not a valid DNS URI record name.  To translate the URI

RFC7553 is Informational.  Clearly it's the most authoritative when
describing the URI RR type's RDATA and their semantics.  But as for the
RRset names, I think it's mistaken, and anyways, it's Informational
(though it once aimed for Proposed Standard; we might want to find out
why it ended up being Informational).

>   https://host[:port][path]
> 
> to an URI record requires
> 
>  _kerberos._https.host
>
> [...]

Problems with this:

a) if we're going to be pedantic, _https is not the sort of protocol
   intended to go there (protocols running over IP are, so _tcp, _udp,
   _sctp, ...);

b) plus we have *two* HTTP-based protocols, so how would we indicate
   which protocol to use?

c) every additional transport for the KDC exchanges adds a (serial, as
   implemented) DNS lookup for the clients -- this is a performance
   disaster.

(c) is fatal.  We really need _kerberos.<REALM's domainname>. as the
QName and, therefore, the RRset name.  One question, one answer set.

And if we're going to use URI, then we'll need a 'krbtgt' URI scheme by
which to express the four protocols we have (raw over TCP, raw over UDP,
HTTP MSFT-style, and HTTP Heimdal-style:

  krbtgt:<host>[:<port>]#proto=tcp
  krbtgt:<host>[:<port>]#proto=udp
  krbtgt:http[s]://<host>[:port][/path]#style=POST
  krbtgt:http[s]://<host>[:port][/path]#style=GET

Or any variant of that that you might like, such as:

  krbtgttcp:<host>[:<port>]
  krbtgtudp:<host>[:<port>]
  krbtgtpost:http[s]://<host>[:port][/path]
  krbtgtget:http[s]://<host>[:port][/path]

> Can you make a case for something that DNS URI records provides that DNS
> SRV records do not?

Yes.  See above.

> The introduction of DNS URI records will only mean that in practice that
> Kerberos client libraries will need to issue the DNS URI queries in
> addition to the existing DNS SRV records.

Yes, but they should try URI queries first so as to create an incentive
to publish those (because that will be faster, because it will be just
one query instead of three or four).

Nico
--