From: <david.black@emc.com>
To: <sipcore@ietf.org>
Date: Fri, 3 Dec 2010 15:27:00 -0500
Thread-Topic: OPS-DIR review of draft-ietf-sipcore-sec-flows-06
Thread-Index: AcuTKDK1i/d95a1XQqSssN6UvLh23QAACSnw
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D5B61CEA@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sipcore] FW: OPS-DIR review of draft-ietf-sipcore-sec-flows-06
Precedence: list

From: Black, David=20
Sent: Friday, December 03, 2010 3:25 PM
To: Cullen Jennings; kumiko@cs.columbia.edu; rjsparks@estacado.net; brian@e=
stacado.net; 'ops-dir@ietf.org'
Cc: Black, David; Adam Roach; Paul Kyzivat
Subject: OPS-DIR review of draft-ietf-sipcore-sec-flows-06

I have performed an Operations Directorate review of draft-ietf-sipcore-sec=
-flows-06

Operations directorate reviews are solicited primarily to help the area dir=
ectors improve their efficiency, particularly when preparing for IESG telec=
hats, and allowing them to focus on documents requiring their attention and=
 spend less time on the trouble-free ones.  Improving the documents is impo=
rtant, but clearly a secondary purpose.  A third purpose is to broaden the =
OpsDir reviewers' exposure to work going on in other parts of the IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG to r=
aise issue with a document. The reviews may, however, convince individual I=
ESG members to raise concern over a particular document requiring further d=
iscussion. The reviews, particularly those conducted in last call and earli=
er, may also help the document editors improve their documents.

--------------

Summary: This draft is basically ready for publication, but has nits that s=
hould be fixed before publication.

This draft is aimed at improving the productivity of SIP over TLS interoper=
ability events and the interoperability of SIP over TLS implementations.  A=
s such, it's a positive contribution to network operations and management, =
as improved interoperability reduces operational issues that would otherwis=
e arise.

I found a few nits and have a few suggestions:

The CA certificate uses a 1024-bit RSA key, whereas the host and user certi=
ficates use 2048-bit RSA keys.  This results in using a 1024-bit RSA key to=
 vouch for the validity of 2048-bit RSA keys.  While acceptable for interop=
erability testing, this is not good operational security practice - I would=
 suggest asking a PKIX expert (e.g., Steve Kent) for appropriate language t=
o warn about this.

At the end of Section 2.2, the Section citation from RFC 5280 is wrong.  Se=
ctions 6.1 and 6.2 should be cited, instead of just Section 6.1.4.  Also, t=
he CRL checking in Section 6.3 of RFC 5280 should be added as a reference c=
ited in the last paragraph of the security considerations section.

Somewhere, probably in Section 5, a warning should be added that the certif=
icate path validation algorithm is a complex algorithm for which *all* the =
details matter - there are numerous ways in which failing to precisely impl=
ement the algorithm as specified in Section 6 of RFC 5280 can create a secu=
rity flaw, a simple example of which is the failure to check the expiration=
 date that is already mentioned in Section 5.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778=
6
david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754
----------------------------------------------------