[apps-discuss] APPSDIR review of draft-ietf-mile-rfc6046-bis-03
Julian Reschke <julian.reschke@gmx.de> Sun, 11 December 2011 19:14 UTC
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1E121F8479 for <apps-discuss@ietfa.amsl.com>; Sun, 11 Dec 2011 11:14:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.768
X-Spam-Level:
X-Spam-Status: No, score=-104.768 tagged_above=-999 required=5 tests=[AWL=-2.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjhLtunt3Eof for <apps-discuss@ietfa.amsl.com>; Sun, 11 Dec 2011 11:14:23 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5415221F8477 for <apps-discuss@ietf.org>; Sun, 11 Dec 2011 11:14:23 -0800 (PST)
Received: (qmail invoked by alias); 11 Dec 2011 19:14:21 -0000
Received: from p5DCC85B1.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.133.177] by mail.gmx.net (mp054) with SMTP; 11 Dec 2011 20:14:21 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18MlxouEHIMn0NpAN2aetHFwdDdrFMvHtHx1u34xK eMaSPeXPIplRln
Message-ID: <4EE50109.2030201@gmx.de>
Date: Sun, 11 Dec 2011 20:14:17 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: draft-ietf-mile-rfc6046-bis@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: The IESG <iesg@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-ietf-mile-rfc6046-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Dec 2011 19:14:24 -0000
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
- Re: [apps-discuss] APPSDIR review of draft-ietf-m… Brian Trammell
- [apps-discuss] APPSDIR review of draft-ietf-mile-… Julian Reschke
- Re: [apps-discuss] APPSDIR review of draft-ietf-m… t.petch