Transport of Real-time Inter-network Defense (RID) Messages
draft-moriarty-post-inch-rid-transport-03

[Ballot comment]
Section 1

  However, extensions such as
  Real-time Inter-network Defense (RID) [I-D.moriarty-post-inch-rid]

Do you have other extensions in mind? Would it be OK to say..
  However,
  Real-time Inter-network Defense (RID) [I-D.moriarty-post-inch-rid]

[Ballot discuss]
I have a problem with the generality of the assertion in the first
sentence of the Abstract.

  Documents intended to be shared among multiple constituencies must
  share a common format and transport mechanism.

It is not the case that two documents intended to be shared among
multiple constituencies have to have a common format or transport
mechanism. I think you have two distinct points:

- All members of a constituency that shares a document must have a
  common understanding of the document format.

- All members of a RID consortium require a common transport
  mechanism for sharing documents.

In fact, the Introduction is much less contentious, and you may just
want to borrow from there rather than create new text.

[Ballot comment]
Is the table referred to in this sentence from the 5th para in sectio 3 the same table as referred to in the 9th para:

  The following table lists the allowable RID message types in an HTTP
  Response for a given RID message type in the Request.

[Ballot comment]
Section 1

  However, extensions such as
  Real-time Inter-network Defense (RID) [I-D.moriarty-post-inch-rid]

Do you have other extensions in mind? Would it be OK to say..
  However,
  Real-time Inter-network Defense (RID) [I-D.moriarty-post-inch-rid]

[Ballot discuss]
I have a problem with the generality of the assertion in the first
sentence of the Abstract.

  Documents intended to be shared among multiple constituencies must
  share a common format and transport mechanism.

It is not the case that two documents intended to be shared among
multiple constituencies have to have a common format or transport
mechanism. I think you have to distinct points:

- All members of a constituency that shares a document must have a
  common understanding of the document format.

- All members of a RID consortium require a common transport
  mechanism for sharing documents.

In fact, the Introduction is much less contentious, and you may just
want to borrow from there rather than create new text.

[Ballot comment]
Section 1

  However, extensions such as
  Real-time Inter-network Defense (RID) [I-D.moriarty-post-inch-rid]

Do you have other extensions in mind? Would it be OK to say..
  However,
  Real-time Inter-network Defense (RID) [I-D.moriarty-post-inch-rid]

[Ballot discuss]
I have a problem with the generality of the assertion in the first
sentence of the Abstract.

  Documents intended to be shared among multiple constituencies must
  share a common format and transport mechanism.

It is not the case that two documents intended to be shared among
multiple constituencies have to have a common format or transport
mechanism. I think you have to distinct points:

- All members of a constituency that shares a document must have a
  common understanding of the document format.

- All members of a RID consortium require a common transport
  mechanism for sharing documents.

In fact, the Introduction is much less contentious, and you may just
want to borrow from there rather than create new text.

[Ballot comment]
Section 202, paragraph 8:
>    RID systems MUST support and SHOULD use HTTP/1.1 persistent
>    connections as described in [RFC2616] to minimize TCP connection
>    setup overhead.

  I'd be surprised if the load on a RID system was high enough or the
  timing constraints where tight enough such that persistent connections
  made a difference in practice.


Section 4., paragraph 2:
>    public key infrastructure (PKI) to manage identities dor RID systems

  Nit: s/dor/for/

[Ballot discuss]
Section 5., paragraph 1:
>    Consistent with BCP 56 [RFC3205], since RID over HTTP/TLS is a
>    substantially new service, and should be controlled at the consortium
>    member network's border differently than HTTP/TLS, it requires a new
>    port number.  IANA has assigned port [IANA NOTE: assign port number
>    here] to RID over HTTP/TLS.

  DISCUSS: These instructions are not sufficient. IANA needs to have a
  few more bits of information; see
  http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-06#section-8.1.
  Specifically, what service name is asked for?

[Ballot comment]
Section 3:

  Note that HTTP provides no mechanism for signaling to a server than a
  response body is improper. 

that a response body is improper?

[Ballot discuss]
Question:

When the response is "[Empty]" as specified in Section 3, and the server
wishes to employ a callback method of actually processing the request,
should the server make a callback with an empty contents or omit making
any callback whatsover?

[Ballot comment]
Section 3:

  Note that HTTP provides no mechanism for signaling to a server than a
  response body is improper. 

that a response body is improper?

[Ballot discuss]
1) Does this ID need a blurb about PFS?  TLS says:

  TLS users desiring Perfect Forward Secrecy should use DHE cipher
  suites.

So I'm curious if these users should desire it or not?  If so then, the cipher suites need to be documented.

(2) Security Consideration has the following text:

  For transport confidentiality, identification, and authentication,
  TLS with mutual authentication MUST be used to secure the HTTP
  connection as in [RFC2818].

I looked in RFC 2818 and it says the following about client identity checks:

  Typically, the server has no external knowledge of what the client's
  identity ought to be and so checks (other than that the client has a
  certificate chain rooted in an appropriate CA) are not possible. If a
  server has such knowledge (typically from some source external to
  HTTP or TLS) it SHOULD check the identity as described above.

Now, I'm confused.  Is this draft saying that mutual authentication is required and it's upping the requirements in RFC 2818?  Or is it not doing that and the security consideration is incorrect (i.e., it's not mutual authentication)?

If mutual certificate-based authentication is required then you also need to add some text to address the use of certificates.  Maybe add a new section to address it and move the one sentence out from the security considerations about the names.

(3) Need to say something about MUST NOT negotiate NULL suites for authentication, integrity, and confidentiality.

(4) Need to say something about whether renegotiation is supported.

(5) (I copied one of Tim's DISCUSSes from another document that points to TLS) The document requires use of  TLS, and mandates certificate-based authentication for both the client and server.  This provides a nice baseline with a reasonably consistent level of security. However, many people consider SSL and TLS to be interchangeable, and early versions of SSL do not provide an acceptable level of security.  I would like to see text along the following lines added to this specification:

  Implementations of TLS typically support multiple versions of the
  Transport Layer Security protocol as well as the older Secure
  Sockets Layer (SSL) protocol.  Because of known security
  vulnerabilities, TLSTM clients and servers MUST
  NOT request, offer, or use SSL 2.0.  See Appendix E.2 of [TLS]
  for further details.

The Security Considerations would be one possible location for this
text, but the exact placement is not an issue...

(6) Why isn't this a MUST:

  RID systems SHOULD additionally verify the fully qualified domain
  name (FQDN) of a connected RID system peer against the presented
  Subject identity.

(7) I support Peter's DISCUSS wrt to pointing to https://datatracker.ietf.org/doc/draft-saintandre-tls-server-id-check/ for the name checking text.

[Ballot discuss]
1) Does this ID need a blurb about PFS?  TLS says:

  TLS users desiring Perfect Forward Secrecy should use DHE cipher
  suites.

So I'm curious if these users should desire it or not?  If so then, the cipher suites need to be documented.

(2) Security Consideration has the following text:

  For transport confidentiality, identification, and authentication,
  TLS with mutual authentication MUST be used to secure the HTTP
  connection as in [RFC2818].

I looked in RFC 2818 and it says the following about client identity checks:

  Typically, the server has no external knowledge of what the client's
  identity ought to be and so checks (other than that the client has a
  certificate chain rooted in an appropriate CA) are not possible. If a
  server has such knowledge (typically from some source external to
  HTTP or TLS) it SHOULD check the identity as described above.

Now, I'm confused.  Is this draft saying that mutual authentication is required and it's upping the requirements in RFC 2818?  Or is it not doing that and the security consideration is incorrect (i.e., it's not mutual authentication)?

If mutual certificate-based authentication is required then you also need to add some text to address the use of certificates.  Maybe add a new section to address it and move the one sentence out from the security considerations about the names.

(3) Need to say something about MUST NOT negotiate NULL suites for authentication, integrity, and confidentiality.

(4) Need to say something about whether renegotiation is supported.

(5) (I copied one of Tim's DISCUSSes from another document that points to TLS) The document requires use of  TLS, and mandates certificate-based authentication for both the client and server.  This provides a nice baseline with a reasonably consistent level of security. However, many people consider SSL and TLS to be interchangeable, and early versions of SSL do not provide an acceptable level of security.  I would like to see text along the following lines added to this specification:

  Implementations of TLS typically support multiple versions of the
  Transport Layer Security protocol as well as the older Secure
  Sockets Layer (SSL) protocol.  Because of known security
  vulnerabilities, TLSTM clients and servers MUST
  NOT request, offer, or use SSL 2.0.  See Appendix E.2 of [TLS]
  for further details.

The Security Considerations would be one possible location for this
text, but the exact placement is not an issue...

(6) Why isn't this a MUST:

  RID systems SHOULD additionally verify the fully qualified domain
  name (FQDN) of a connected RID system peer against the presented
  Subject identity.

(7) I support Peter's DISCUSS wrt to pointing to https://datatracker.ietf.org/doc/draft-saintandre-tls-server-id-check/ for the name checking text.

[Ballot discuss]
1) Does this ID need a blurb about PFS?  TLS says:

  TLS users desiring Perfect Forward Secrecy should use DHE cipher
  suites.

So I'm curious if these users should desire it or not?  If so then, the cipher suites need to be documented.

(2) Security Consideration has the following text:

  For transport confidentiality, identification, and authentication,
  TLS with mutual authentication MUST be used to secure the HTTP
  connection as in [RFC2818].

I looked in RFC 2818 and it says the following about client identity checks:

  Typically, the server has no external knowledge of what the client's
  identity ought to be and so checks (other than that the client has a
  certificate chain rooted in an appropriate CA) are not possible. If a
  server has such knowledge (typically from some source external to
  HTTP or TLS) it SHOULD check the identity as described above.

Now, I'm confused.  Is this draft saying that mutual authentication is required and it's upping the requirements in RFC 2818?  Or is it not doing that and the security consideration is incorrect (i.e., it's not mutual authentication)?

If mutual certificate-based authentication is required then you also need to add some text to address the use of certificates.  Maybe add a new section to address it and move the one sentence out from the security considerations about the names.

(3) Need to say something about MUST NOT negotiate NULL suites for authentication, integrity, and confidentiality.

(4) Need to say something about whether renegotiation is supported.

(5) (I copied one of Tim's DISCUSSes from another document that points to TLS) The document requires use of  TLS, and mandates certificate-based
authentication for both the client and server.  This provides a nice baseline with a reasonably consistent level of security. However, many people consider SSL and TLS to be interchangeable, and early versions of SSL do not provide an acceptable level of security.  I would like to see text along the following lines added to this specification:

  Implementations of TLS typically support multiple versions of the
  Transport Layer Security protocol as well as the older Secure
  Sockets Layer (SSL) protocol.  Because of known security
  vulnerabilities, TLSTM clients and servers MUST
  NOT request, offer, or use SSL 2.0.  See Appendix E.2 of [TLS]
  for further details.

The Security Considerations would be one possible location for this
text, but the exact placement is not an issue...

(6) Why isn't this a MUST:

  RID systems SHOULD additionally verify the fully qualified domain
  name (FQDN) of a connected RID system peer against the presented
  Subject identity.

(7) I support Peter's DISCUSS wrt to pointing to https://datatracker.ietf.org/doc/draft-saintandre-tls-server-id-check/ for the name checking text.

[Ballot discuss]
The security considerations specify the following:

  RID systems SHOULD additionally verify the fully qualified domain
  name (FQDN) of a connected RID system peer against the presented
  Subject identity.  The fully qualified domain name used to identify a
  RID system may be stored either in a subjectAltName extension of type
  dNSName, or in the most specific Common Name field of the Subject
  identity of the RID system's X.509 certificate.  Internationalized
  FQDNs MUST be encoded using Punycode [RFC3492].  If both a Common
  Name and subjectAltName FQDN are present, the subjectAltName is to be
  given preference.

A few questions and comments:

1. Must a RID system be identified by an FQDN (instead of, say, an IP address)?

2. Why is identity checking a SHOULD instead of a MUST? Good security practices indicate that an entity MUST attempt to verify the identity of the peer (although naturally identity verification might fail).

3. Much more detailed rules for identity verification are provided in draft-saintandre-tls-server-id-check; perhaps it makes sense to simply profile that specification here?

IANA questions/comments:

QUESTIONS:

- Do you require a WELL KNOWN PORT NUMBER, or can you use a REGISTERED
PORT NUMBER?

- Do you want or need a registry for the Result/Response codes?

Upon approval of this document, IANA will make the following assignment
in the "PORT NUMBERS" registry at
http://www.iana.org/assignments/port-numbers

Keyword Decimal Description References
------- ------- ----------- ----------
rid TBD/tcp RID over HTTP/TLS [RFC-moriarty-post-inch-rid-transport-02]


We understand the above to be the only IANA Action for this document.