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

[Nathaniel McCallum <[e-mail]>]

On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote:
> On Tue, May 17, 2016 at 11:49:23AM -0400, Nathaniel McCallum wrote:
> > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco
> > very
> > -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.

Agreed to a URI scheme.

However, HTTP w/ GET is undefined and only exists in one codebase. It
also has some real idempotency and space limitation drawbacks.

In contrast, MS-KKDCP (HTTP w/ POST) has a protocol definition and is
implemented by multiple vendors without the above drawbacks.

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

The authors of RFC 7553 told me that informational should be considered
normal for RR type definitions. The authoritative record is IANA and
should be referenced instead of the informational RFC.

>  - 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?

Yes. I'm working on this now. However, I'm less sure that UX designers
will be keen to back a "generic record" interface. I do think it will
be possible to get buy-in for URI records.

>  - 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).

I plan to ask some of the providers I know.

>  - 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.

+1