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

[Petr Spacek <[e-mail]>]

On 17.5.2016 22:43, Nathaniel McCallum wrote:
> On Tue, 2016-05-17 at 12:25 -0400, Jeffrey Altman wrote:
>> On 5/17/2016 11:49 AM, 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?
>>>
>>
>> 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
>>
>>   https://host[:port][path]
>>
>> to an URI record requires
>>
>>  _kerberos._https.host
>>
>> not
>>
>>  _kerberos.host
> 
> It doesn't actually require this. It just gives examples.

More importantly, SRV records did not have any way to specify protocol so
_proto label was only way to convey the information.

In contrary, URI can convey information about protocol/scheme and thus
artificial requirement for _proto label does not make sense.

Also, RFC 2782's Applicability Statement clearly states that SRV records
should be used only for applications which have own RFC describing its semantics.

Considering URI vs. SRV properties mentioned above and the requirement for
separate RFC, I think that Nathaniel's usage of URI records is justified and
legal.

Petr^2 Spacek

>> DNS URI records according to RFC 7553 work just like DNS SRV records
>> in
>> that they require both a service name and a protocol name.  Switching
>> to
>> URI records does not solve the problem of multiple DNS queries.
>>
>> To find a KDC that supports https, use the DNS SRV record
>>
>>   _kerberos._https.REALM
> 
> _https isn't a thing. You'd have to do something like: _http._tls._tcp.
> 
>> registering additional service types such as "kpasswd" can be done
>> but
>> the fact is implementations such as Heimdal already perform SRV
>> lookups for
>>
>>  _kpasswd,_tcp.REALM and _kpasswd._udp.REALM
> 
> At the cost of one DNS query per transport. Further, administrators
> have no control over the weights or priorties between transports. My
> draft provides this.
> 
>> Can you make a case for something that DNS URI records provides that
>> DNS
>> SRV records do not?
> 
> Yes. MS-KKDCP requires a path. SRV records cannot provide a path.
> 
>> 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.
> 
> We will need to add at least one more DNS query to support MS-KKDCP
> (two if we have to treat http and https as separate queries). This is
> unavoidable. While it is true that this will result in a 50% increase
> in DNS queries, using my URI scheme means that a simple administrator
> configuration can turn this 50% increase into a 50% decrease in queries
> over the existing implementations. This is a win.