Subject: [mile] WGLC on draft-ietf-mile-rfc6046-bis-01 to 5 December 2011

From: <[email-masked]>
Date: Mon, 21 Nov 2011 09:01:15 -0500

Hello,

I'd like to start a two-week working group last call (WGLC) on the RFC6046-bis document (draft-ietf-mile-rfc6046-bis-01).

Please make your comments on the document to the [email-masked] list by 5 December 2011. The more reviews, the better, so please take time to read the document if you've not done so yet.

Many thanks, and best regards,

Kathleen (as chair of the MILE WG)

---

From: <[email-masked]>
Date: Wed, 23 Nov 2011 10:10:08 -0500

Hello Brian,

This draft looks good, which was expected, as it's mostly unchanged from RFC 6046.
I have a few comments.

(1) Section 3:

   Consistent with BCP 56, RID systems will listen for
   TCP connections on port 4590.  Every RID system participating in a
   consortium MUST listen for HTTP/TLS connections on the assigned port.

Something should be said about use of the standard port 443.  I think use of that port should
be discouraged or outright prohibited in order to avoid posting of RID messages to ordinary
web servers that may not handle them correctly or with sufficient security.  The simplest
approach would be to add:

	RID systems MUST NOT use TCP port 443 (the standard port for HTTP over TLS/SSL) for
	RID messages.

Alternatively:

	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.

(2) Also Section 3:

   When performing RID callback, a responding system MUST
   connect to the network- and transport-layer addresses from which the
   original request was sent; there is no mechanism in RID for
   redirected callback.

I read "transport-layer addresses" as implying that the callback should connect to the TCP
port that was used to send the original RID message.  That seems wrong, because the TCP
connection on which the initial RID message is sent shouldn't be using TCP port 4590 as
the source port, and the callback should be going to port 4590.  I'd also suggest rewriting
this text to explicitly say what addresses are reused from the original request.

(3) Section 4:

   Although TLS
   implementations typically support the older SSL protocol, a RID peer
   MUST NOT request, offer, or use SSL 2.0, due to known security
   vulnerabilities in this protocol; see Appendix E of [RFC5246] for
   more.

This is sufficient, but given how recently RID was originally specified (2010), would it
be reasonable to require TLS 1.1 (2006) or a more recent version?  Requiring at least
TLS 1.1 removes the vulnerability caused by use of an implicit IV for CBC-mode ciphers
in prior versions of TLS and SSL.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Brian Trammell <[email-masked]>
Date: Wed, 23 Nov 2011 17:43:40 +0100

Hi, David,

Thanks for the comments; have accepted them without further comment into the working copy of the -02 revision of the draft.

Best regards,

Brian (as author of 6046-bis)