Subject: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-rfc7483bis-04: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 16 Feb 2021 16:50:40 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-rfc7483bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Should the errata against RFC 7483 in state "reported" be verified or
otherwise processed before this document gets approved?

My understanding (based on the draft name and shepherd writeup) is that
this document is intended to Obsolete: RFC 7483.  If so, that should be
indicated in the header, abstract, and introduction, as (in my
understanding) the Gen-ART reviewer pointed out.

Thank you for keeping the diff from RFC 7483 minimal -- that made things
very easy to read!  (FWIW, I do consider converting all the links to
the "https" scheme worth the churn; thank you for that as well.)

Some of the examples have gone stale, though (or were inaccurate from
the start), particularly with respect to the cryptographic digests and
algorithms used for DNSSEC.  I do not think that we can in good
conscience publish, in 2021, an Internet Standard that shows RSA/MD5
signatures as an example!  (Specifics in the editorial
section-by-section remarks.)

Also, for Section 1.1, RFC 8174 has an updated BCP 14 boilerplate text to
use.

It's probably worth making a pass through the examples to check for
cases where the handle "XXXX" is being used for distinct entities within
a single example (as that's not really self-consistent).

It may be worth noting in the security considerations that, while these
RDAP responses allow for retrieval of DNSSEC (key) related information,
(AFAICT) the RRSIG DS from the parent zone is not conveyed alongisde it.
This means that the DNSSEC keys retrieved by RDAP are disconnected from
their containing PKI, and as such are not generally expected to be
trusted without additional information.  In particular, just the HTTPS
channel protecting the RDAP connection is not expected to be authorized
to certify the validity of the DNSSEC keys.

The rest of my remarks are basically editorial or nit level, and I don't
expect specific responses to them.

Section 3

   Contact information is defined using jCards as described in
   [RFC7095].  The "fn" member is required and MUST NOT be null
   according to [RFC6350], where an empty "fn" member MAY be used when
   the contact name does not exist or is redacted.

(editorial) The way the last sentence is written suggests that [use of
empty "fn" when the name does not exist or is redacted] is a behavior
specified in RFC 6350, but based on text searches in RFC 6350 I suspect
that this statement is actually a clarification new to this document
about how the jCard format is being used.

Section 4.1

Going from 7483 to this document we now say that "rdapConformance" MUST
appear in the topmost JSON object of a response (vs "appears only" in
it).  Is the intent to forbid "rdapConformance" from appearing anywhere
else in addition to the topmost JSON object?  If so, the current text
seems insufficient to me.

Section 4.2

   The following is an example of the link structure:

       {
         "value" : "https://example.com/context_uri",
         "rel" : "self",
         "href" : "https://example.com/target_uri",

I am prone to confusing myself about RFC 8288 links, but it surprised me
that "href" differed from "value" for a relation of type "self".

   The JSON name/values of "rel", "href", "hreflang", "title", "media",
   and "type" correspond to values found in Section 3 of [RFC8288].  The
   "value" JSON value is the context URI as described by [RFC8288].  The
   "value", "rel" and "href" JSON values MUST be specified.  [...]

Looking just at the diff from RFC 7483 makes it seem that we gain a
MUST-level requirement for the "rel" value to be specified, which would
not normally be allowed in a transition to Internet Standard.  However,
it seems that RFC 8288 itself requires the presence of "rel", so this is
not in practice a new requirement, and thus safe.

Section 4.5

I think it's vCard that has a LANGUAGE property; in jCard that would be
the "language" key.

Section 5.1

[I did not attempt to validate that the jCards contained in any of the
examples conform to RFC 7095.]

   and names of organizations and individuals.  Many of the types of
   information that can be represented with jCard have no use in RDAP,
   such as birthdays, anniversaries, and gender.

(nit) I suggest s/no use/little or no use/, just on my instinct of
avoiding absolutes when not needed.  ("Only a Sith deals in absolutes",
right?)

   The following is an elided example of an entity with embedded
   entities.

(nit) I'd suggest "abbreviated" or "condensed" instead of "elided",
which as written would seem to imply that the entire example is omitted.
This applies to more than one instance, but I will only mention it once.

Section 5.3

      -  idnTable -- the name of the Internationalized Domain Name (IDN)
         table of codepoints, such as one listed with the IANA (see IDN
         tables [IANA_IDNTABLES]).

(nit) the definite article "the" in "the [IDN] table of codepoints"
implies that the context should indicate which one we are referring to
(perhaps the one used in the variant names?), but I am failing to tell
from context which table is being indicated.

           "keyTag": 12345,
           "algorithm": 3,
           "digestType": 1,
           "digest": "49FD46E6C4B45C55D4AC"

Could we maybe use SHA-256 for the example instead of the
no-longer-safe-for-general-use SHA-1 (so, digest type 2 instead of 1,
and corresponding digest length)?  [Hmm, the existing SHA-1 example is
20 hex digits, which is only 80 bits, not the full 160-bit SHA-1
output...]
Likewise for the signature algorithm (algorithm 3 is DSA/SHA-1, and
there are lots of stronger alternatives listed at
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml)

            "flags": 257,
            "protocol": 3,
            "algorithm": 1,
            "publicKey": "AQPJ////4Q==",

Similarly, the key data here indicates the algorithm 1, or RSA/MD5 which
is deprecated.  (The public key is also a laughably small 40-bit
modulus when decoded.  A nice strong Ed25519 key, algorithm 15, would
not expand the example unreasonably in my opinion.)

         "eventAction" : "expiration",
         "eventDate" : "2016-12-31T23:59:59Z",
         "eventActor" : "[email-masked]"

(side note) Perhaps an expiration in the future is more useful as an
example, though it is clearly not wrong to list the expiration event
even when it is in the past.

Section 5.5

   The following is an example of a JSON object representing an autnum.

   {
     "objectClassName" : "autnum",
     "handle" : "XXXX-RIR",
     "startAutnum" : 10,
     "endAutnum" : 15,

IIUC AS numbers 10 through 15 are assigned by ARIN, including AS 11 that
is assigned to Harvard University (last updated 2019-08-12) and appears
to be in current use.  Perhaps the reserved ASN 0 would make for a safer
example?

     [...]
     "links" :
     [
       {
         "value" : "https://example.net/autnum/xxxx",
         "rel" : "self",
         "href" : "https://example.net/autnum/xxxx",
         "type" : "application/rdap+json"

Hmm, my reading of 7482bis suggests that the bit after /autnum/ should
be an actual AS number, not a handle.  But it doesn't seem to give much
guidance on how to represent a block of AS numbers as opposed to a
single one within a block...

   *  type -- a string containing an RIR-specific classification of the
      autnum

(nit) is this the RIR's classification of the number itself, or the
allocation/registration?

Section 10

I think that sometimes we see "-bis" documents that just say "IANA has
updated the registrations made by RFCXXXX to refer to this document",
but I don't particularly mind repeating the registration information in
the now-primary reference document.

Section 10.1

      Published specification: RFC 7483

Presumably we want this updated to the rfc-to-be?

Section 10.2.4

      Description: The entity object instance represents a third party
      through which the registration was conducted (i.e. not the
      registry or registrar).

(nit/side-note) I am pretty sure the RFC Editor is going to add the
comma back after "i.e." (but expect that leaving it for them to do will
cause the right thing to happen).  Perhaps we should ask IANA and the
RFC Editor to get on the same page...

Section 13.1

   The default text encoding for JSON responses in RDAP is UTF-8
   [RFC3629], and all servers and clients MUST support UTF-8.

(I note that UTF-8 preference is one of the things that changed from RFC
7159 to RFC 8259, so this may be redundant now.  I didn't think about it
very hard and don't expect anyone else to, as there's no harm in leaving
it alone.)

Section A.1

   The following is an elided example of a registrant with information
   changed to reflect that of a third party.

   {
     ...
     "entities" :
     [
       {
         "objectClassName" : "entity",
         "handle" : "XXXX",
         ...
         "roles" : [ "registrant", "administrative" ],
         "status" : [ "proxy", "private", "obscured" ]

(editorial) it might be nice to show a little more, so that we can
contrast "Joe User" with "Anonymizing Proxy Service" (or whatever).

Section A.1

             ["email",
               { "type":"work" },
               "text", "[email-masked]"

I wonder if the 'example' TLD might be more apropos for this case (e.g.,
[email-masked]).  (The link might be altered
similarly as well.)

Section D

   DNSSEC provides data integrity for DNS through the digital signing of
   resource records.  [...]

It also provides source authenticity, which is equally important.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Feb 2021 16:51:52 +0000

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[email-masked]>
> Sent: Tuesday, February 16, 2021 7:51 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Jasdip Singh <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Benjamin Kaduk's No Objection on draft-ietf-regext-
> rfc7483bis-04: (with COMMENT)
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)

[SAH] [snip]

[SAH] I verified them and took care of the necessary fixed in 7483bis. Someone who has permissions to do so needs to update the Datatracker.

> understanding) the Gen-ART reviewer pointed out.

[SAH] Yes, will fix.

> very easy to read!  (FWIW, I do consider converting all the links to the "https"
> scheme worth the churn; thank you for that as well.)
> 
> Some of the examples have gone stale, though (or were inaccurate from the
> start), particularly with respect to the cryptographic digests and algorithms
> used for DNSSEC.  I do not think that we can in good conscience publish, in
> 2021, an Internet Standard that shows RSA/MD5 signatures as an example!
> (Specifics in the editorial section-by-section remarks.)

[SAH] I'll look at those below.

> Also, for Section 1.1, RFC 8174 has an updated BCP 14 boilerplate text to use.

[SAH] Will fix.

> It's probably worth making a pass through the examples to check for cases
> where the handle "XXXX" is being used for distinct entities within a single
> example (as that's not really self-consistent).

[SAH] I *think* I got all that straight when WG reviewers made the same comment some time ago.

> It may be worth noting in the security considerations that, while these RDAP
> responses allow for retrieval of DNSSEC (key) related information,
> their containing PKI, and as such are not generally expected to be trusted
> without additional information.  In particular, just the HTTPS channel
> protecting the RDAP connection is not expected to be authorized to certify
> the validity of the DNSSEC keys.

[SAH] This is true, and it may be useful to add some additional text to make it clear. I'll see what I can do.

> The rest of my remarks are basically editorial or nit level, and I don't expect
> specific responses to them.
> 
> Section 3
> 
> (editorial) The way the last sentence is written suggests that [use of empty
> "fn" when the name does not exist or is redacted] is a behavior specified in
> RFC 6350, but based on text searches in RFC 6350 I suspect that this
> statement is actually a clarification new to this document about how the
> jCard format is being used.

[SAH] I'm going to adopt the fix suggested by Roman.

> Section 4.1
> 
> Going from 7483 to this document we now say that "rdapConformance"
> MUST appear in the topmost JSON object of a response (vs "appears only" in
> it).  Is the intent to forbid "rdapConformance" from appearing anywhere else
> in addition to the topmost JSON object?  If so, the current text seems
> insufficient to me.

[SAH] Correct, it shouldn't appear anywhere else. "MUST appear in the topmost JSON object " is a requirement for both presence and location. "appears only" seems to leave some wiggle room in whether it needs to be present. Can you suggest a re-wording if it's not clear?

>          "value" : "https://secure-
> web.cisco.com/1La4d1rUpkdc92phDKa17sS991fnDuBO3-
> WlVJA0xMmd_qEBBMSmmELpoLRKNGUY-
> imAXRq9_AvdWQjlzWt3luV4LFt9WxmMVg2mZGwUVWWomY2hbsjwIgvnJh
> _20H8RJpsOqAxMFgG5D1BvBCuDa1EbDK3AoI3gWm88UiAWhMRm-
> 4MZ5k8k8yj3CK1Aa0XktWyKGVeudlOYWfzklhIgtAVm95YyDba8426iSBJGe5Ip
> 7bKEcZtk66HHMDVtZhWAi/https%3A%2F%2Fexample.com%2Fcontext_uri",
>          "rel" : "self",
>          "href" : "https://secure-web.cisco.com/1-
> D4mH9SAtoE0W_T2b1RTQj6AyDwBgtdEBBe7JI5e-3C9uje37wTNu2-Q-
> IBrYmxigaIv2kOotFrlQQH7b2qdlzhDnKOQeNOg97C4BkoPxOQ52LQDnCfdCeZ
> yVxjyLp-
> NT9eKwfByij0oHQ9Dnqcdw1Xv_ge8nPrp0r460RDfYZxjUfqN3d3ZeE_yi8qKCF
> UKgM-
> lQqK1eAO0GZviQ9_dXCp8WtqL7w68zlmsTI6s_t4vMpNUIjyFJLzrkvRXxqgQ/ht
> tps%3A%2F%2Fexample.com%2Ftarget_uri",
> 
> I am prone to confusing myself about RFC 8288 links, but it surprised me that
> "href" differed from "value" for a relation of type "self".
> 
> Looking just at the diff from RFC 7483 makes it seem that we gain a MUST-
> level requirement for the "rel" value to be specified, which would not
> normally be allowed in a transition to Internet Standard.  However, it seems
> that RFC 8288 itself requires the presence of "rel", so this is not in practice a
> new requirement, and thus safe.

[SAH] That's my interpretation as well.

> Section 4.5
> 
> I think it's vCard that has a LANGUAGE property; in jCard that would be the
> "language" key.

[SAH] Agreed, that should be "vCard". Thanks for the catch.

> (nit) I suggest s/no use/little or no use/, just on my instinct of avoiding
> absolutes when not needed.  ("Only a Sith deals in absolutes",
> right?)

[SAH] OK, makes sense.

> (nit) I'd suggest "abbreviated" or "condensed" instead of "elided", which as
> written would seem to imply that the entire example is omitted.

[SAH] I think I'll leave this one as-is. Elided does mean "To eliminate or leave out", which is what's going on here.

> (perhaps the one used in the variant names?), but I am failing to tell from
> context which table is being indicated.

[SAH] I see your point. How about this: "The name of the Internationalized Domain Name (IDN) table that has been registered in the IANA Repository of IDN Practices [IANA_IDNTABLES]."?

> Could we maybe use SHA-256 for the example instead of the no-longer-safe-
> for-general-use SHA-1 (so, digest type 2 instead of 1, and corresponding
> digest length)?  [Hmm, the existing SHA-1 example is
> 20 hex digits, which is only 80 bits, not the full 160-bit SHA-1 output...]
> Likewise for the signature algorithm (algorithm 3 is DSA/SHA-1, and there are
> lots of stronger alternatives listed at
> https://secure-
> web.cisco.com/1I8Di5U8y3NTUQw9mWzM4wGSzTlafm8s8sYb-
> SwOMAkssj9r5pszzi1Zs5Ygzl0D1Sxx91nPpgnsoDjiB2VXMAoYIZZ82y2Mz1s3W
> CPr3vOuK0Np5p1XQajn3FkaGC5QH4shVzJOhnXe06ta3H9wOgSA571FTY-
> MXVDpk1O7iymHeaMwMphD3nOyxr1yZ1GTgu01Na1ljPIpXHTmfyaBabu8fn3
> axVeaEj7PFao8o6jTCClRIQwElbE6MmesdpaRd/https%3A%2F%2Fwww.iana.o
> rg%2Fassignments%2Fdns-sec-alg-numbers%2Fdns-sec-alg-numbers.xhtml)
> 
>             "flags": 257,
>             "protocol": 3,
>             "algorithm": 1,
> Similarly, the key data here indicates the algorithm 1, or RSA/MD5 which is
> deprecated.  (The public key is also a laughably small 40-bit modulus when
> decoded.  A nice strong Ed25519 key, algorithm 15, would not expand the
> example unreasonably in my opinion.)

[SAH] I'll see if can find a more modern example.

> (side note) Perhaps an expiration in the future is more useful as an example,
> though it is clearly not wrong to list the expiration event even when it is in
> the past.

[SAH] I'd prefer to leave this one alone since it's just an example inherited from 7483.

> IIUC AS numbers 10 through 15 are assigned by ARIN, including AS 11 that is
> assigned to Harvard University (last updated 2019-08-12) and appears to be in
> current use.  Perhaps the reserved ASN 0 would make for a safer example?

[SAH] Perhaps. I'll check with my ARIN colleagues.

> Hmm, my reading of 7482bis suggests that the bit after /autnum/ should be
> an actual AS number, not a handle.  But it doesn't seem to give much
> guidance on how to represent a block of AS numbers as opposed to a single
> one within a block...

[SAH] The "xxxx" used here is just an attempt to mask an autnum, but if that seems to confusingly look like it's a handle I can use a different mask, perhaps "yyyy"?

> (nit) is this the RIR's classification of the number itself, or the

[SAH] I'll check with my ARIN colleagues.

> updated the registrations made by RFCXXXX to refer to this document", but I
> don't particularly mind repeating the registration information in the now-
> primary reference document.
> 
> Section 10.1
> 

[SAH] Correct.

> (nit/side-note) I am pretty sure the RFC Editor is going to add the comma
> back after "i.e." (but expect that leaving it for them to do will cause the right
> thing to happen).  Perhaps we should ask IANA and the RFC Editor to get on
> the same page...
> 
> Section 13.1
> 
> 7159 to RFC 8259, so this may be redundant now.  I didn't think about it very
> hard and don't expect anyone else to, as there's no harm in leaving it alone.)
> 
> Section A.1
> 
> (editorial) it might be nice to show a little more, so that we can contrast "Joe
> User" with "Anonymizing Proxy Service" (or whatever).
> 
> Section A.1
> 
>              ["email",
>                { "type":"work" },

[SAH] I'm inclined to leave the examples alone, but I can add "source authenticity".

Scott

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Feb 2021 15:39:40 -0800

Hi Scott,

> [SAH] I verified them and took care of the necessary fixed in 7483bis. Someone who has permissions to do so needs to update the Datatracker.

Indeed, that was mostly directed at Barry :)

> [SAH] I *think* I got all that straight when WG reviewers made the same comment some time ago.

I was pretty sure that I had seen at least one go by when I made this note
... perhaps Figure 23, that uses XXXX as the handle for Joe User's entity
and also for the containing domain?  Figure 24 has a lot of "XXXX"s as
well, looking now (but not getting any further than there).

> [SAH] This is true, and it may be useful to add some additional text to make it clear. I'll see what I can do.

Thanks.

> [SAH] I'm going to adopt the fix suggested by Roman.

That looks good; I guess I missed Roman's note when I was submitting my own ballot.

> [SAH] Correct, it shouldn't appear anywhere else. "MUST appear in the topmost JSON object " is a requirement for both presence and location. "appears only" seems to leave some wiggle room in whethe…

I think we'd have to make a separate requirement in order for it to be
clear, a la "MUST appear in the topmost JSON object of a response and MUST
NOT appear anywhere else".

> > "href" differed from "value" for a relation of type "self".

(Not sure if this one was skipped intentionally or not...I have pretty low
confidence that there's an issue, to be clear.)

> [SAH] I see your point. How about this: "The name of the Internationalized Domain Name (IDN) table that has been registered in the IANA Repository of IDN Practices [IANA_IDNTABLES]."?

I think that still leaves me uncertain how the table relates to the domain
object and the variant names thereof.

> [SAH] The "xxxx" used here is just an attempt to mask an autnum, but if that seems to confusingly look like it's a handle I can use a different mask, perhaps "yyyy"?

If we're giving explicit values for "startAutnum" and "endAutnum", I would
have thought that we could just pick a distinguished value from that range
and use it instead of a placeholder.  (But see also my remark about not
knowing how to represent a range in an autnum URL...)

> [SAH] I'm inclined to leave the examples alone, but I can add "source authenticity".

Okay, that's your prerogative.

Thanks,

Ben

---

From: Jasdip Singh <[email-masked]>
Date: Fri, 19 Feb 2021 02:12:22 +0000

Hello Scott,

Please find below my input on couple of points.

Jasdip

    

[JS] As per RFC 5398 ( https://tools.ietf.org/html/rfc5398 ), IANA's AS numbers registry ( https://www.iana.org/assignments/as-numbers/as-numbers.xhtml ) reserves couple of ASN ranges for documentation purposes: 64496-64511 and 65536-65551. We could use them instead in our examples.

[JS] Though this field is not required as per the NRO RDAP profile for RIRs ( section 5.5 in https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt ), I believe it is intended to indicate the registration hierarchy for those AS numbers as per that RIR's registration model. The "type" field also exists in section 5.4 for the IP Network objects. If we clarify this field further, would be good to do so consistently in both the places.