Subject: Re: [Gen-art] OPS-DIR review of draft-ietf-sipcore-sec-flows-06

From: <[email-masked]>
Date: Wed, 8 Dec 2010 17:00:31 -0500

Hi Brian,

I think this is a plan, and in particular, if you do this:

> I have generated a new version of the cryptographic content with a test CA that uses 2048 bit RSA so
> all of the certs are consistent.

Then there will be no need to explain differences in certificate key sizes because there won't be any ;-).  Hence with a new 2048 bit CA cert in the revised draft, I concur that:

> However, in practice, I'm not sure that there is any real need to include text about what
> the CAs should do regarding the key sizes of the certs they are signing, because they have their own
> practices and are unlikely to heed this informational RFC.

All of your other proposed actions are fine with me, so go ahead and upload a new version of the draft with the proposed changes.

Thanks,
--David

> -----Original Message-----
> From: Brian Hibbard [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 3:42 PM
> To: Gonzalo Camarillo; Black, David
> Cc: Cullen Jennings; Kumiko Ono; Sparks Robert; Adam Roach
> Subject: Re: OPS-DIR review of draft-ietf-sipcore-sec-flows-06
> 
> Hi,
> 
> Thank you for your input, David.
> 
> If everyone is in agreement, here's how I plan to proceed:
> 
> I have generated a new version of the cryptographic content with a test CA that uses 2048 bit RSA so
> all of the certs are consistent.   I'm ready to include that in version 08, unless there are
> objections.  However, in practice, I'm not sure that there is any real need to include text about what
> the CAs should do regarding the key sizes of the certs they are signing, because they have their own
> practices and are unlikely to heed this informational RFC.  In previous conversations on the WG list,
> we established that that means by which  the certs are created, managed, etc., was something we wanted
> to avoid altogether, except that we cannot ignore it entirely if we want to facilitate interop
> testing.
> 
> I will change the Section citation in Section 2.2 as you suggest to refer to Sections 6.1 and 6.2 of
> RFC 5280 and not just to Section 6.1.4.  Actually, I'm not sure why it was only 6.1.4 to begin with.
> 
>  I will change the reference to CRL validation in Security Considerations to both Section 3.3 and
> Section 6.3 of RFC 5280, instead of just Section 3.3.
> 
> David, if you're OK with it, I would like to use your warning text with some minor modification as a
> new paragraph at the end of  Section 5:
> 
> "Please note that the certificate path validation algorithm described in Section 6 of RFC 5280 is a
> complex algorithm for which all of the details matter. There are numerous ways in which failing to
> precisely implement the algorithm as specified in Section 6 of RFC 5280 can create a security flaw, a
> simple example of which is the failure to check the expiration date that is already mentioned above.
> It is important for developers to ensure that this validation is performed and the results are
> verified by their applications or any libraries that they use."
> 
> Thanks, all,
> Brian
> 
> 
> On Dec 3, 2010, at 2:25 PM, <[email-masked]> <[email-masked]> wrote:
> 
> > I have performed an Operations Directorate review of draft-ietf-sipcore-sec-flows-06
> >
> > Operations directorate reviews are solicited primarily to help the area directors improve their
> efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents
> requiring their attention and spend less time on the trouble-free ones.  Improving the documents is
> important, 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 raise issue with a
> document. The reviews may, however, convince individual IESG members to raise concern over a
> particular document requiring further discussion. The reviews, particularly those conducted in last
> call and earlier, may also help the document editors improve their documents.
> >
> > --------------
> >
> > Summary: This draft is basically ready for publication, but has nits that should be fixed before
> publication.
> >
> > This draft is aimed at improving the productivity of SIP over TLS interoperability events and the
> interoperability of SIP over TLS implementations.  As such, it's a positive contribution to network
> operations and management, as improved interoperability reduces operational issues that would
> otherwise 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 certificates 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 interoperability testing, this is not good operational security practice - I would
> suggest asking a PKIX expert (e.g., Steve Kent) for appropriate language to warn about this.
> >
> > At the end of Section 2.2, the Section citation from RFC 5280 is wrong.  Sections 6.1 and 6.2 should
> be cited, instead of just Section 6.1.4.  Also, the CRL checking in Section 6.3 of RFC 5280 should be
> added as a reference cited in the last paragraph of the security considerations section.
> >
> > Somewhere, probably in Section 5, a warning should be added that the certificate path validation
> algorithm is a complex algorithm for which *all* the details matter - there are numerous ways in which
> failing to precisely implement the algorithm as specified in Section 6 of RFC 5280 can create a
> security 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  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
>