Subject: Re: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00

From: Greg Hudson <[email-masked]>
Date: Mon, 3 Apr 2017 12:32:55 -0400

On 03/30/2017 02:51 PM, Matt Rogers wrote:
>> * RFC 7553 is informational and this document is standards track, which
>>   is a down reference (see RFC 3967).  Also, RFC 7553 contains ambiguous
>>   guidance about URI records labels which some readers have interpreted
>>   as being incompatible with our use of labels.  I think at one point we
>>   received advice to reference the IANA registration of the URI record
>>   type instead of RFC; unfortunately I do not know the mechanics of that
>>   kind of reference.

> The IANA registration entry refers to RFC 7553:
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
> Perhaps it should just be an informative reference instead.

There is also a "completed template" in the IANA assignment:

https://www.iana.org/assignments/dns-parameters/URI/uri-completed-template

I hadn't read this before.  It says (in section E):

  The URI RR has service information encoded in its ownername.  In
  order to encode the service for a specific owner name one uses
  service parameters.  Valid service parameters used are either
  Enumservice Registrations registered by IANA, or prefixes used
  for the SRV resource record.

which seems like a slightly more restrictive statement than the one in
RFC 7553.  We may need some guidance from the chairs or ADs on the
mechanics of moving forward here.  Simply making the reference
informative doesn't seem sufficient, as the URI RR type is fundamental
to this standard.

(To be clear, I think what we're doing ought to be fine, and that it's
generally pointless to include a transport label in a URI record owner
name like one would in a SRV owner name.  The question is one of
conformance with the pre-existing standard, not practicality.)

>> * Similarly, MS-KKDCP is in the normative references section, and is not
>>   a standards-track IETF document.  It is only used as the reference in
>>   the initial contents of the transport registry, so perhaps it can just
>>   be an informative reference.
>>
> I'll make this an informative reference.

The MS-KKDCP reference is obvious controlling when using the kkdcp
transport.  Since this is just an initial transport registration, it may
be okay to use an informative reference.

>> * "REALM indicates the translation of the Kerberos realm to a DNS
>>    domain" seems to invoke some kind of translation procedure without a
>>    reference.  RFC 4120 doesn't really define any such translation
>>    procedure; it just says in section 6.1 that a realm might be in
>>    domain style with some specifics on what that means, and in section
>>    7.2.3.2 that "The realm MUST be a domain-style realm name".
>>
>>    (Section 6 has this same wording again.)
> 
> How about "..client MUST query the following URI DNS record, where
> REALM is a domain-style realm name."

I'm okay with that.

>> * The wording here seems too general.  I think we want to specifically
>>   say that URI records should be preferred over SRV records.

> How about: "Clients that support service discovery through both URI
> and SRV records SHOULD perform the URI discovery first. If no URI
> record is found, the client MAY then attempt SRV discovery."

Sure.

There is an argument for a MUST here.  DNS administrators will commonly
want to set up both URI and SRV records for a realm, and the behavior of
trying URI first may be important (e.g. if the URI record includes a
kkdcp entry).

>> * The reference here is "TBD".  Is there a plan?  Is the reference
>>   supposed to be to this RFC once a number is assigned?
>>
> 
> It should be changed to the assigned number, yes. It was suggested
> that instead of TBD we use [This Document], which I think is the
> convention for this kind of reference.

That seems okay.  There might also need to be an RFC editor guidance
section pointing out the need for a substitution there.  For instance,
in https://tools.ietf.org/html/draft-ietf-krb-wg-crypto-07 see the
"Notes to RFC Editor" section at the end.

> "The security implication of using DNS URI records is identical to
> that of using DNS for any Kerberos service or host mapping; without
> secure DNS the results can be forged.  The same precautions regarding
> the use of insecure DNS with Kerberos outlined in RFC 4120 should be
> followed."

RFC 4120 primarily talks about DNS in the context of prohibiting the use
of insecure DNS to map between service names, which is irrelevant to
this standard.

Since RFC 4120 assumes a hostile network environment (and so does RFC
3244), it is usually uninteresting whether an attacker subverts
communication via a DNS attack or a network attack.  However, we should
note in security considerations that the added security benefits of
MS-KKDCP (such as confidentiality of client and server principal names)
are eroded when using insecure DNS to discover the server URL.

---

From: Matt Rogers <[email-masked]>
Date: Mon, 10 Apr 2017 14:13:27 -0400

> conformance with the pre-existing standard, not practicality.)

I'll leave this as normative at the moment, but perhaps it warrants
some text to explain the difference between our use of the owner name
and the RFC 7553 guidelines.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Apr 2017 23:52:57 -0500

>   for the SRV resource record.

It's not entirely clear just how binding this is on consumers,
though I do think IANA consults this sort of thing sometimes.

> RFC 7553.  We may need some guidance from the chairs or ADs on the

Given how similar it is to the text in the RFC, I think we are
forced to conclude that the RFC takes precedence, possibly due to
last-minute changes.  (That is, that someone got sloppy at some
point.  But the RFC text is what has IETF consensus, and is thus
preferred.)  The relevant text was added in draft-faltstrom-uri-11,
FWIW.

We can call this issue out in the shepherd writeup for IESG
attention, too.  Making a final call is "above our pay grade" :)

> conformance with the pre-existing standard, not practicality.)

It is correct to leave the reference as normative; the downref can
be called out during IETF last call (though, IIRC, some recent-ish
changes in policy do not mandate it quite as strongly as it used to
be).

> be okay to use an informative reference.

I believe an informative reference is fine for this document, as
that spec is not needed in order to use the discovery protocol
itself.  (It's needed to use the results of discovery, but that's
out of scope.)

> trying URI first may be important (e.g. if the URI record includes a

Note that the MUST only applies for implementations that claim to
comply with <RFC-to-be>, so it is not as strong a requirement as it
might seem at first.

> "Notes to RFC Editor" section at the end.

Yes, "[this document]" is an accepted form.  I don't expect a
specific RFC Editor note is needed for this sort of usage.

-Ben