IRIS: The Internet Registry Information Service (IRIS) Core Protocol
draft-ietf-crisp-iris-core-07

[Ballot discuss]
draft-ietf-crisp-iris-core-06.txt

10: What document specifies the security that must be provided architecturally for IRIS, i.e., what must each transport implement?

draft-ietf-crisp-iris-dreg-06.txt
What security properties apply to the defined elements? .e., what is the relationship between the tags specified  in 3.2.1 and the security properties a server might insist on?

draft-ietf-crisp-iris-beep-06.txt
6.1: Is the TLS server name extension desired?  See Section 3.1 of RFC 3546.

12: Make support of AES (RFC 3268) a "SHOULD".

[Ballot comment]
draft-ietf-crisp-iris-core-06.txt
  Should a (normative) ref be added to RFC3629 because of sect 8?

$ idnits-v1.27    S:            iris:referentType="dreg:registrationAuthority"
                    ^
  Line 2079 contains control character TAB in position 15.
  -->    S:            authority="com" registryType="dreg1"
                    ^
  Line 2080 contains control character TAB in position 15.
  -->    S:            entityClass="local" entityName="VRSN"
                    ^
  Line 2081 contains control character TAB in position 15.
  -->    S:            hosting="false" />
                    ^
  Line 2100 contains control character TAB in position 15.
  -->    S:           
                    ^
  Line 2107 contains control character TAB in position 15.
  -->    S:           
                    ^

[Ballot discuss]
draft-ietf-crisp-iris-core-06.txt

  2nd para in section 3.3.3 says:

    For instance, the entity name "10.0.1.0" might refer to separate
    entities in the "name-server" and "network" classes. The entity
    "10.0.1.0" in the "name-server" class may refer to the name server
    host that is also multi-homed by address 192.178.0.1 and known in DNS
    as "ns.example.com", whereas the entity "10.0.1.0" in the "network"
  class may refer to the network 10.0.1/24.

  is using IP addresses as examples that are not in the range (192.0.2.0/24)
  that has been reserved for such example addresses (RFC3330)

  Same issue/concern on page 43.

2. draft-ietf-crisp-iris-dreg-06.txt

  Is using IP addresses and DNS names that do not conform to the ones
  we have set aside for examples

[Ballot discuss]
draft-ietf-crisp-iris-core-06.txt

10: What document specifies the security that must be provided architecturally for IRIS, i.e., what must each transport implement?

Is a referral simply a transport optimization?  Or are there security semantics?  I caution that proxy-based protocols have run into serious authorization questions in the past.

draft-ietf-crisp-iris-dreg-06.txt
What security properties apply to the defined elements? .e., what is the relationship between the tags specified  in 3.2.1 and the security properties a server might insist on?

draft-ietf-crisp-iris-beep-06.txt
6.1: Is the TLS server name extension desired?  See Section 3.1 of RFC 3546.

12: Make support of AES (RFC 3268) a "SHOULD".

Review from Spencer Dawkins, Gen-ART:

Summary - these drafts are close to baked for Proposed Standard.

Nits, all of which are Auth48:

(iris-core) - 1st paragraph of 1.2 - "a URI, more specifically a URN"
is a little pedantic ("a URN"), but at the very least, URN should be
expanded at first use.

(iris-core) - 1.3 layer figure doesn't expand "beep", iris-lwz, etc.

(general) - the "formal XML syntax" sections of these documents go for
pages - maybe tens of pages - with no explanation. Appendix A of
iris-dreg is a lot more readable, with only a little more text that
points out what to look for, section by section. As they stand, the
formal XML syntax sections are a lot more useful to automated syntax
checkers than to humans.

(iris-core) - 7.2 - "there is nothing stopping them" is idiomatic and
problematic for ESL. If there's a recommendation (application protocol
label string == scheme name), it should be a lot clearer than this.

(iris-core) - 10 - the "SHOULD NOT be used" seems to be directed at a
registry, but the client is the one who would misuse authentication
credentials for mechanisms vulnerable to replay attacks.

(iris-core) Appendix C - is really nice, but tends to use "lookup" as
a verb. It should be "look up", when it's a verb, should it not?

(iris-beep) - 1 - the third paragraph sounds like a political speech.
It could be a LOT clearer. And "straight use of TCP" in the fourth
paragraph isn't clear - you mean "IRIS directly over TCP", right?

(iris-beep) - 4 - Certificates don't actually cryptographically
verify, right? (They are inanimate!) something like "must be
cryptographically verified"?

(iris-dreg) - 3.2.1 - "And their specified cardinality allows their
absence" is stilted and confusing, and "if they are present without
content" is ambiguous (I think you're talking about element types, but
boolean attributes is closer in the sentence).

[Ballot discuss]
draft-ietf-crisp-iris-core-06:

  Here is my interpretation of the 2nd paragraph in section 3.4:

    A server send the  to the client, and the  MAY
    contain a  child element, which MUST contain one or more
    elements. Each  element MUST contain an 'id' attribute.
    Further, two particular kinds of  MUST include a 'bagRef'
    attribute.

  Since the client is supposed to treat the  as opaque, the
  requirements above ought to clearly fall to the server that generates
  the .  The client should not refuse to pass along a  that
  does not meet these requirements.  The text states the requirements
  on the , but the responsibilities for generation and checking
  are not discussed in relation the three parties involved in the
  handling of .  The three parties are the server that generates
  the , the client that replays the , and the server that
  receives (and presumable processes) the .

  draft-ietf-crisp-iris-dreg-06:

  The security considerations are not sufficient. 
 
    - Section 3.2.1 includes discussion of denying access to registry
      content because policy does not allow it to be given under the
      current level of access.  So, I was expecting some discussion
      in the security considerations about the determination of the
      level of access.

    - Section 5.2 includes a pointer to IRIS-BEEP as the default
      server authentication method.  So, I expected some discussion
      of the properties required in alternate authentication
      mechanisms.  At least say that plaintext passwords MUST NOT
      be used.

  draft-ietf-crisp-iris-beep-06:

  In section 6.2, the server presents to the client a certificate, and
  this certificate MUST contain the authority in either the subjectDN
  or the subjectAltName extension of type dNSName.  If this authority
  appears in the subject distinguished name, what attributes are used?
  I suspect that domaninComponent is the best fit, but that does not
  match the way that TLS is normally used today.  Further, RFC 3280
  does not permit the use of wildcards in subject or subjectAltName.

[Ballot comment]
draft-ietf-crisp-iris-core-06:
 
  I would like to see the RFC 2119 reference much earlier in the
  document, preferably before the first MUST.

  draft-ietf-crisp-iris-beep-06:

  In section 6.2: s/X509 [10] certificate/X.509 certificate [10]/

[Ballot discuss]
draft-ietf-crisp-iris-core-06:

  Here is my interpretation of the 2nd paragraph in section 3.4:

    A server send the  to the client, and the  MAY
    contain a  child element, which MUST contain one or more
    elements. Each  element MUST contain an 'id' attribute.
    Further, two particular kinds of  MUST include a 'bagRef'
    attribute.

  Since the client is supposed to treat the  as opaque, the
  requirements above ought to clearly fall to the server that generates
  the .  The client should not refuse to pass along a  that
  does not meet these requirements.  The text states the requirements
  on the , but the responsibilities for generation and checking
  are not discussed in relation the three parties involved in the
  handling of .  The three parties are the server that generates
  the , the client that replays the , and the server that
  receives (and presumable processes) the .

  draft-ietf-crisp-iris-dreg-06:

  The security considerations are not sufficient. 
 
    - Section 3.2.1 includes discussion of denying access to registry
      content because policy does not allow it to be given under the
      current level of access.  So, I was expecting some discussion
      in the security considerations about the determination of the
      level of access.

    - Section 5.2 includes a pointer to IRIS-BEEP as the default
      server authentication method.  So, I expected some discussion
      of the properties required in alternate authentication
      mechanisms.  At least say that plaintext passwords MUST NOT
      be used.

  draft-ietf-crisp-iris-beep-06:

  In section 6.2, the server presents to the client a certificate, and
  this certificate MUST contain the authority in either the subjectDN
  or the subjectAltName extension of type dNSName.  If this authority
  appears in the subject distinguished name, what attributes are used?
  I suspect that domaninComponent is the best fit, but that does not
  match the way that TLS is normally used today.  Further, RFC 3280
  does not permit the use of wildcards in subject or subjectAltName.