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

[Petr Spacek <[e-mail]>]

On 19.5.2016 18:47, Nathaniel McCallum wrote:
> 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:

Any new RR type will be in worse position than URI because of reasons you
stated below.


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

Oh yes, this is my plan for some time already but it always gets lower
priority than something else ... I would not wait for it :-)

More importantly, there was literally no usage & demand for the URI record up
to now. Adding new RR types to UI is trivial as soon as you have justification
for the management, so the demand could simply solve the UI problem for the
URI RR type.

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

We have a standard for Handling of Unknown DNS RR Types:
https://tools.ietf.org/html/rfc3597

It says that RDATA for unknown types should be typed in using hexadecimal
notation:
https://tools.ietf.org/html/rfc3597#section-5

Also, some servers/services simply lack UI (e.g. Windows Server 2003) but
allow adding the record using standard DNS UPDATE protocol RFC 2136, which is
also behavior mandated by RFC 3597.

Petr Spacek  @  Red Hat


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