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

From: "Martin, Robert A." <[email-masked]>
Date: Sun, 4 Dec 2011 10:36:33 -0500

Hello Brian,

With these updates I think this is now a very solid document.  I look 
forward to this Transportation of RID messages capability becoming 
available for those trying to share incident management information 
between their enterprises.

Regards,

Bob

On 11/23/11 11:43 AM, Brian Trammell wrote:
> 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)
>
> On Nov 23, 2011, at 4:10 PM,<[email-masked]>  wrote:
>
>> 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
>> ----------------------------------------------------
>
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
> .
>

---

From: Chris Inacio <[email-masked]>
Date: Mon, 12 Dec 2011 23:17:53 -0500

I would really like the title to be changed to 

"Transport of Real-time Inter-network Defense (RID) Messages over HTTPS"

unless we intend for HTTPS to be the exclusive transport of RID.

Chris

On Nov 21, 2011, at 9:01 AM, <[email-masked]> <[email-masked]> wrote:

> 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: Mon, 12 Dec 2011 23:47:05 -0500

Hello Chris,

HTTPS is not intended to be the exclusive transport of RID.  I am fine with the document name change, any opinions/objections?

Thank you,
Kathleen (as WG chair)

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]] 
Sent: Monday, December 12, 2011 11:18 PM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] WGLC on draft-ietf-mile-rfc6046-bis-01 to 5 December 2011

Chris

---

From: Brian Trammell <[email-masked]>
Date: Tue, 13 Dec 2011 05:56:30 +0100

Hi, Kathleen, Chris,

Sounds good to me.

Brian (author hat)

---

From: "Martin, Robert A." <[email-masked]>
Date: Tue, 13 Dec 2011 00:29:23 -0500

Works for me.

Bob

On 12/12/11 11:56 PM, Brian Trammell wrote:
> Hi, Kathleen, Chris,
>
> Sounds good to me.
>
> Brian (author hat)
>
> On Dec 13, 2011, at 5:47 AM,<[email-masked]>  <[email-masked]>  wrote:
>
>> Hello Chris,
>>
>> On Nov 21, 2011, at 9:01 AM,<[email-masked]>  <[email-masked]>  wrote:
>>
>>> Hello,
>>>

---

From: <[email-masked]>
Date: Tue, 13 Dec 2011 07:51:18 -0500

Hi Tony,

EV CERTS are mentioned in RID.  Take a look at RFC6045-bis and let me know if the mention in that document satisfies the question.

Thank you,
Kathleen

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2011 7:48 AM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] WGLC on draft-ietf-mile-rfc6046-bis-01 to 5 December 2011

Hi Kathleen,

As a liaison to the CA/Browser Forum, one obvious question
that seems begged here is why EVcerts or their ETSI TS102042
equivalent are not mentioned as a desirable https trust mechanism?

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 13 Dec 2011 08:17:46 -0500

Hi Kathleen,

As a liaison to the CA/B Forum and ETSI ESI, one
question begged by the draft is the lack of any mention
of either the EVcert spec or its ETSI equivalent, TS102042,
as enhanced trust mechanisms.  Is there an explicit rationale?

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 13 Dec 2011 08:28:54 -0500

Was looking in the wrong document.  I think it's covered
in sec. 8.3 mention.  Ideally, it would be a plus to provide
references.

[EVcert] = http://www.cabforum.org/documents.html

Both the CA/B's and ETSI's specs get revised frequently.
The above URL covers both with an extensible pointer.

But this is no reason to delay finalization.

--tony