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

[Nico Williams <[e-mail]>]

On Tue, May 17, 2016 at 11:49:23AM -0400, 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?

 - If we use the URI RR type (and maybe even if we don't), we'll need a
   krbtgt URI scheme, as we have four different options to express,
   including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST,
   HTTP w/ GET.

 - We should find out why RFC7553 ended up being Informational.  There
   may be some important lessons in that.

 - Perhaps we should have our own RR type.  In principle it's easy to
   add them, but:

 - You've mentioned that many DNS hosters don't have UIs or support for
   URI RRs.  This needs more research.  If adding support for new RR
   types is impossible because of this, then the DNS community at the
   IETF should be asked to address this, and we might need to use TXT
   RRs instead.

   Using TXT RRs is frowned upon, and we'd never get an RFC on the
   Standards track using them today, but if the DNS community confirms
   that adding new RR types is much harder than previously thought, then
   TXT RRs will have to become the DNS extension mechanism to use
   instead of new RR types.

   Ideally we could get the DNS hosters to support arbitrary RR types.
   Yes, there is also a UI issue (see below), but it's manageable.

 - If new RR types are the answer, then the DNS community needs to do
   something about UIs.  For example, there could be an XML schema
   defining RR types' RDATA contents and UI elements.  Then implementors
   could automatically translate those to code to implement UIs for new
   RR types.

 - Can you research whether the DNS community at the IETF has addressed
   these issues before?

   If they have not, then we'll have to bring this up to them.

   If they have, what was the outcome?  Have conditions in the market
   changed?  Should the IETF review these issues again?

 - Can you ask some DNS hosters to inveigh as to whether they would be
   willing to add arbitrary new RR types?  (Presumably with a UI that
   requires the user to paste base64-/hex-encoded RDATA.)

   I think this research will be very valuable in reviewing this
   document, and perhaps using alternative designs (e.g., defining a new
   RR type, or using TXT, or updating RFC7553 and perhaps promoting it
   to Proposed Standard).

 - You might want to seek several ADs' input on this early.  The DNS
   issues here seem very real, and dealing with them may require help
   from the ADs.  The WG chairs might help with this.

Nico
--