Re: [kitten] New URI Discovery Draft

[Petr Spacek <[e-mail]>]

On 26.9.2016 17:55, Matt Rogers wrote:
> On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote:
>> On 24.9.2016 00:25, Nathaniel McCallum wrote:
>>>
>>> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-
>>> disc
>>> overy/
>>>
>>> I've submitted a new version of the draft. This version matches the
>>> code that is now merged into MIT Kerberos.
>>>
>>> We need to move forward. If that is as an individual submission,
>>> then
>>> so be it. But we really can't wait any longer. So unless I hear
>>> some
>>> noise to the contrary ASAP, I plan to go this route.
>>
>> Hello,
>>
>> in general it makes sense. The new URI format opened an encoding-
>> Pandora-box
>> so it needs more work to make it fully specified. Here are nits I
>> found in the
>> 03 version of the draft:
>>
> 
> Hi Petr, thanks for reviewing! 
> 
>> 1]
>>>
>>> 4.  Required URI Format
>>>    krb5srv:[flags]:transport:residual
>> Nitpick: I do not really like naming "transport:residual". Something
>> like
>> "transport-type:transport-options" would be more descriptive.
>>
> 
> "transport-options" may make it seem that it's an optional field or
> carries something other than a hostname or URI for the client to
> contact. How about "transport-type:transport-target"?

Sounds good.


>> 2] Is this a good idea?
>>>
>>>    Flags are not considered critical, therefore flags that are not
>>> used
>>>    or unknown to the implementation SHOULD be ignored.
>> Just wondering out loud, not insisting on it:
>> If we say there is no criticality, it will be impossible to add later
>> on.
>>
>> What about using capitalization to indicate criticality of a flag?
>> Records
>> with critical but unsupported flags should be skipped as if there
>> were not
>> present in DNS. Records with non-critical unsupported flags should be
>> used as
>> usual.
>>
>> Or maybe we can limit valid flags to lowercase ASCII letters for now
>> so there
>> is a room for extension in future?
> 
> I think avoiding having case-sensitive fields is the most appropriate
> thing to do for DNS data, our exception here being the path part of a
> KKDCP URL, which we can leave as defined by MS-KKDCP (see below)
> 
> If we want to later add criticality to a flag then it could be a flag
> prepended by a '!' or some such character rather than using the case.

Fine with me. The main point is that if we do not define criticality or at
least reserved character now it will be impossible to enforce it on older
clients. Maybe we can reserve "!" character now and say that character
immediately following "!" must be ignored by clients implementing this version
of the draft?


>> 3] In any case, there is disagreement between
>>>
>>> 4.2.  Flags
>>>    This field contains a sequence of zero or more case-insensitive
>> vs.
>>>
>>> 9.1.  Kerberos Server Discovery Flags
>>> 9.1.1.  Registration Template
>>>    Value:  A single unique ASCII character that identifies the
>>> entry,
>>
>> "A single unique ASCII character" is case-sensitive by definition.
>> This
>> conflicts with case-insensitivity defined in 4.2.
>>
>>
>> 3] The draft is not clear on whether transport field is case-
>> sensitive or not.
>>>
>>> 4.3.  Transport
>>> 9.2.  Kerberos Server Discovery Transport Types
>>
> 
> I'll clear this up.
> 
>>
>> 4] Residual formats are not sufficiently specified:
>>>
>>> 4.4.  Residual
>>> 9.2.  Kerberos Server Discovery Transport Types
>>> 9.2.2.  Initial Registry Contents
>>>
>>>    o Value: "udp"
>>>    o Description: User Datagram Protocol
>>>    o Residual Format: "host[:port]"
>>>    o Case Sensitive: None
>>>    o Default KDC Port: 88
>>>    o Default Admin Service Port: 749
>>>    o Default Password Service Port: 464
>>>    o Reference: [RFC0768]
>>
>> There is no definition of "host" and there is none in RFC 768.
>> Can it be IP(v?) address?
>> Can it be DNS name?
>> How this field should be encoded into the URI?
>>
>>>
>>>    o Value: "tcp"
>>>    o Description: Transport Control Protocol
>>>    o Residual Format: "host[:port]"
>>>    o Case Sensitive: None
>>>    o Default KDC Port: 88
>>>    o Default Admin Service Port: 749
>>>    o Default Password Service Port: 464
>>>    o Reference: [RFC0793]
>>
>> Again there is no definition of "host".
>> Can it be IP(v?) address?
>> Can it be DNS name?
>> How this field should be encoded into the URI?
> 
> Good point, I'll clear this up as well.
> 
>>
>>>
>>>    o Value: "kkdcp"
>>>    o Description: Kerberos Key Distribution Center Proxy Protocol
>>>    o Residual Format: https://host[:port][/path]
>>
>> This is technically URI inside URI, am I right?
>> How is it encoded? Should usual %-encoding be used here?
>>>
>>> 10.1.  URI Format Examples
>> suggest that %-encoding is not used. I would like to see this clearly
>> specified and explained why not.
>>
>> At this point I would rather say "use URL as specified by [MS-KKDCP]" 
>> instead
>> of specifying "https://host[:port][/path]".
> 
> I agree with this, especially since MS-KKDCP defines the URI with
> RFC3986 encoding rules. I think then the registration template can also
> leave out the case-sensitivity definition as the path is defined as
> case-sensitive with RFC3986.
> 
>>
>> Also, to make this bullet-proof, I would mention that "/KdcProxy"
>> must be
>> explicitly specified in the URI record and is not implicitly assumed
>> by clients.
>>
> 
> Sure, that makes sense. 
> 
> Thanks again,
I'm happy to review it again.

-- 
Petr^2 Spacek