Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-04.txt

From: [email-masked]
Date: Mon, 19 Dec 2011 14:37:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Managed Incident Lightweight Exchange Working Group of the IETF.

	Title           : Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS
	Author(s)       : Brian Trammell
	Filename        : draft-ietf-mile-rfc6046-bis-04.txt
	Pages           : 8
	Date            : 2011-12-19

   The Incident Object Description Exchange Format (IODEF) defines a
   common XML format for document exchange, and Realtime Internetwork
   Defense (RID) defines extensions to IODEF intended for the
   cooperative handling of security incidents within consortia of
   network operators and enterprises.  This document specifies a
   transport protocol for RID based upon the passing of RID messages
   over HTTP/TLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mile-rfc6046-bis-04.txt

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Dec 2011 23:41:13 +0100

Greetings, all,

rfc6046-bis-04 is now available, and (I believe) addresses all comments to date, including those in the AD and appsarea reviews. 

Seeing no further discussion on the two open points, I've decided in this version to follow SM's "lightweight" suggestion for normative section language, and the last comment in the TLS version thread (MUST 1.1, SHOULD 1.2); please comment if you have a strong objection to either of these.

Best regards,

Brian (as author of 6046-bis)

Begin forwarded message:

> From: [email-masked]
> Date: December 19, 2011 11:37:04 PM GMT+01:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mile] I-D Action: draft-ietf-mile-rfc6046-bis-04.txt
> 
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: <[email-masked]>
Date: Mon, 19 Dec 2011 18:31:04 -0500

Hello Brian,

I think this may have been written slightly too quickly:

   RID systems MUST use TLS version 1.1 [RFC5246] or higher, and SHOULD
   use TLS version 1.2 or higher, with mutual authentication for
   transport confidentiality, identification, and authentication, as in
   [RFC2818].  

I read that as strongly recommending (SHOULD) use of 1.1 and 1.2 at the
same time, and I don't see a mandatory-to-implement requirement.  Also,
[RFC5246] is TLS 1.2.  I suggest the following (two sentences for clarity): 

   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for transport confidentiality, identification, and
   authentication, as in [RFC2818].  RID systems MUST support TLS
   version 1.1 and SHOULD support TLS version 1.2 [RFC5246].

The remaining text in that paragraph is fine:

   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, due to known security vulnerabilities in prior versions
   of the protocol; see Appendix E of [RFC5246] for more.

As for preference for TLS 1.2 over TLS 1.1, RFC 5246 already specifies that
preference as a SHOULD (client_version in ClientHello message, and required
server response), so that preference does not need to be repeated here.   

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Trammell
> Sent: Monday, December 19, 2011 5:41 PM
> To: [email-masked]
> Subject: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6046-bis-04.txt
> 
> Greetings, all,
> 
> Seeing no further discussion on the two open points, I've decided in this version to follow SM's
> "lightweight" suggestion for normative section language, and the last comment in the TLS version
> thread (MUST 1.1, SHOULD 1.2); please comment if you have a strong objection to either of these.
> 
> Best regards,
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
> item of the Managed Incident Lightweight Exchange Working Group of the IETF.
> >

---

From: Brian Trammell <[email-masked]>
Date: Tue, 20 Dec 2011 07:45:42 +0100

Hi, David, all,

Thanks; yes, the new language is clearer, and better captures the intent of what I was trying to say. Will add to an -05 revision.

Best regards,

Brian (author hat)

---

From: Brian Trammell <[email-masked]>
Date: Tue, 20 Dec 2011 07:48:04 +0100

Hi, David, all,

Except... referencing 4346 like this would lead to a downref, since it's obsoleted by 5246. Isn't the right thing to do here to use 5246 as the reference for 1.1 as well?

Cheers,

Brian (author hat)

---

From: <[email-masked]>
Date: Tue, 20 Dec 2011 09:25:50 -0500

Someone lurking (it does help if you post directly) on the list agreed with the current assessment and stated:

http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf

for confirmation that the record protocol in TLS 1.1 and 1.2 does indeed do a better job than in TLS 1.0 (assuming we avoid short MACs).

AND:

The problem with mandating TLS 1.2 is that it is not yet widely supported in clients or servers. One might hope that, with the recent BEAST attack on TLS 1.0, there would now be a push towards adopting TLS 1.1 and TLS 1.2. But this does not seem to be the case; instead, vendors seem instead to be adding ad hoc countermeasures to their existing TLS 1.0 implementations.

So if you want to see rapid adoption of MILE, you probably don't want to mandate TLS 1.2 only; on the other hand, it's definitely an improvement on TLS 1.0. Probably requiring (TLS 1.1 OR TLS 1.2) is a reasonable compromise - TLS 1.2 is better than TLS 1.1 mostly because it offers better algorithm agility, but they do offer roughly equal levels of security (when configured in the same way).

Thus I broadly agree with the analysis provided by David Black in your e-mail below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 19, 2011 6:31 PM
To: [email-masked]; [email-masked]
Subject: Re: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6046-bis-04.txt

Hello Brian,

Thanks,
--David

---

From: <[email-masked]>
Date: Tue, 20 Dec 2011 09:49:18 -0500

> 1.0 (assuming we avoid short MACs).

Actually, RID doesn't even need to avoid short MACs, because that attack is inapplicable to RID, even if short MACs are used as specified in RFC 6066.  The attack involves an relatively new feature of TLS that allows truncation of the integrity HMAC output to 80 bits (the truncated_hmac extension in RFC 6066).  The PDF referenced above states that the attack is inapplicable when:

                      message length + MAC tag length > cipher block size - 8 (all in bits).

For AES, the cipher block size is 128 bits.  Plug in 80 bits for the shortest MAC tag length, and the attack is inapplicable when:

                      message length > 40 bits, i.e., 5 bytes (yes, *5* !).

I believe the shortest RID message is an HTTP 202 Accepted response, which is longer than 5 bytes, and by comparison to that, the XML used for RID transport of actual incidents is positively verbose ;-).

Nonetheless, the TLS WG should look at this attack.  I also don't see any compelling reason to use short MACs with RID.

Thanks,
--David

> From: Moriarty, Kathleen
> Sent: Tuesday, December 20, 2011 9:26 AM
> To: Black, David; [email-masked]; [email-masked]
> Subject: RE: [mile] Fwd: I-D Action: draft-ietf-mile-rfc6046-bis-04.txt
> 
> The problem with mandating TLS 1.2 is that it is not yet widely supported in clients or servers. One
> might hope that, with the recent BEAST attack on TLS 1.0, there would now be a push towards adopting
> TLS 1.1 and TLS 1.2. But this does not seem to be the case; instead, vendors seem instead to be adding
> ad hoc countermeasures to their existing TLS 1.0 implementations.
> 
> So if you want to see rapid adoption of MILE, you probably don't want to mandate TLS 1.2 only; on the
> other hand, it's definitely an improvement on TLS 1.0. Probably requiring (TLS 1.1 OR TLS 1.2) is a
> reasonable compromise - TLS 1.2 is better than TLS 1.1 mostly because it offers better algorithm
> agility, but they do offer roughly equal levels of security (when configured in the same way).
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 27 Dec 2011 16:31:28 -0500

Brian,

I'd not worry about the DOWNREF.  As long as you and the shepherd remind 
me to include it in the LC text, it'll be fine.  I doubt anybody is 
really going to object.  Note that if RFC 4346 was obsoleted and moved 
to historic then I suspect people would object, but RFC 4346 is just 
obsoleted.

I'll wait for -05 before issuing the LC.

spt

On 12/20/11 1:48 AM, Brian Trammell wrote:
>> On Dec 20, 2011, at 12:31 AM,<[email-masked]>  <[email-masked]>  wrote:
>>
>>> Hello Brian,
>>>