Subject: [apps-discuss] APPSDIR review of draft-ietf-mile-rfc6046-bis-03

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Dec 2011 20:14:17 +0100

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-mile-rfc6046-bis-03
Title: Transport of Real-time Inter-network Defense (RID) Messages
Reviewer: Julian Reschke
Review Date: 2011-12-11
IETF Last Call Date: not last-called yet
IESG Telechat Date: -

Summary: This draft is almost ready for publication as as a Proposed 
Standard and should be revised before publication

NOTE: I have *not* reviewed any security-related aspects.

Major Issues:

-

Minor Issues:

As pointed out in Section 3, this protocol really (ab)uses HTTP as a 
simple transport, and uses only a tiny subset of HTTP. This is properly 
explained, and the decision to use a custom port number makes sense.

What I'm missing here are a few things that would probably make it 
easier to understand what's actually required:

1) Does a RID endpoint need to implement all REQUIRED HTTP/1.1 features? 
For instance, does it need to understand Expect: 100-continue, and does 
it have to support GET and HEAD on "/"? Are there requirements for 
request URIs other than "/"?

2) What's the Internet Media Type to be used with RID payloads? Is it 
defined? If no, why not? Is it required to be used?

3) How do retries work when a request fails? Is the use of POST here 
idempotent so that the request can be repeated?

4) How does matching between request and callback work?

5) It might be a good idea to add a complete example of an exchange that 
uses the callback pattern.

Also, in Section 4:

    For transport confidentiality, identification, and authentication,
    TLS with mutual authentication MUST be used to secure the HTTP
    connection as in [RFC2818].  The session MUST use non-NULL
    ciphersuites for authentication, integrity, and confidentiality;
    sessions MAY be renegotiated within these constraints.  Although TLS
    implementations typically support the older SSL protocol, a RID peer
    MUST NOT request, offer, or use any version of SSL, or any version of
    TLS prior to 1.1 [RFC4346], due to known security vulnerabilities in
    prior versions of the protocol; see Appendix E of [RFC5246] for more.

This is a bit confusing because RFC5246 obsoletes RFC4346; there's 
probably a good reason for what it says here, but it might be good to 
explain what it is.

Nits:

    RID systems SHOULD NOT use TCP port 443 (the standard port for HTTP
    over TLS/SSL) for RID messages; this avoids posting RID messages to
    web servers that may not handle RID messages correctly.

Actually, it does not, because a web server may run on the RID port 
(4590) as well. If there's a security concern with the protocol with 
respect to generic web servers, it should be pointed out (and 
potentially fixed).

Abstract:

    (...).  This document updates the previous [RFC6046] to
    change the intended status to Proposed Standard, and to reference the
    updated RID specification.

This is procedural and should be moved to the Introduction (this will 
also fix the issue of having a reference in the Abstract).

    among members in a RID consortium.  This document specifies the
    transport of RID messages within HTTP [RFC2616] Request and Response
    messages transported over TLS [RFC5246] (herein, HTTP/TLS).  Note

Missing "." after [RFC2616].

1.2. Normative and Informative sections

    Section 3, Section 4, and Section 5 of this document are normative;
    the remainder of the document is informative.

I don't think is is needed here.

References:

draft-moriarty-mile-rfc6045-bis-02: [2011-08-27 ID-Exists Replaced] (not 
active)
RFC4346: [PROPOSED STANDARD] obsoleted by RFC5246; maybe this one is 
informative?

Best regards, Julian

---

From: "t.petch" <[email-masked]>
Date: Sun, 11 Dec 2011 20:37:18 +0100

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>
Cc: "The IESG" <[email-masked]>
Sent: Sunday, December 11, 2011 8:14 PM

> probably a good reason for what it says here, but it might be good to

Julian

It makes sense because RFC4346 is the formal definition of TLS1.1,
loopholes and all, whereas RFC5246 defines TLS1.2.  I think it
difficult to add any explanation without this becoming a TLS 101.

Tom Petch

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Brian Trammell <[email-masked]>
Date: Mon, 12 Dec 2011 17:59:27 +0100

Hi, Julian,

Thank you for the detailed review; answers to questions which can be simply addressed in the document will be incorporated into the next revision. 

I'm copying comments on specific points for discussion to mile and apps-area, inline.

Best regards,

Brian

On Dec 11, 2011, at 8:14 PM, Julian Reschke wrote:

> What I'm missing here are a few things that would probably make it easier to understand what's actually required:
> 
> 1) Does a RID endpoint need to implement all REQUIRED HTTP/1.1 features? For instance, does it need to understand Expect: 100-continue, and does it have to support GET and HEAD on "/"? Are there requirements for request URIs other than "/"?

As (1) the probable implementation path in most cases is to build a RID implementation atop an existing web server and (2) there is probably more to lose than to gain in attempting to define a coherent subset of the REQUIRED features, I would tend to think that all HTTP/1.1 REQUIRED features are REQUIRED for RID transport over HTTP/1.1. This goes for proper handling of potentially cached content and "proxy-friendliness", as well as handling of 100 Continue... (Is there a list of REQUIRED features in 1.1? seems like this would be a useful thing to have in a BCP56-bis...)

On specific points:

I presume that any access to non / URIs should return 404, since those resources in essence do not exist on the server; this should be noted.

The question as to what to do in case of GET / and HEAD / should be addressed, and I'm not sure what the right thing to do here is. Logically, this should be the same as what happens as POST with an empty body, which is also presently undefined. Allowing a text/html reply explaining that this is a RID system and what that is might be the most "user-friendly" solution (for people who aren't actually users of the system) but having the semantics and the media type of the reply depend on the method seems a little wrong, too. I presume a 405 Method Not Allowed violates a MUST in 2616? In any case, it would probably be difficult to implement based on many/most existing web servers.

> Actually, it does not, because a web server may run on the RID port (4590) as well. If there's a security concern with the protocol with respect to generic web servers, it should be pointed out (and potentially fixed).

There's no security problem (at least, accidental connection to the wrong server should be prevented by proper verification of certificates). The intention here is simply that a RID System be easily distinguishable from a "normal" web server.