MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20451.8082.829270.276362@iinet.net.au>
Date: Thu, 21 Jun 2012 23:20:18 +1000
From: Max Matveev <makc@gmx.co.uk>
To: Dave Brolley <brolley@redhat.com>
Cc: pcp@oss.sgi.com, Performance Tools <perftools-list@redhat.com>
Subject: Re: [pcp] SSL/TLS and IPv6 for PCP via NSS/NSPR
In-Reply-To: <4FE1FE5B.6020302@redhat.com>
References: <4FE1FE5B.6020302@redhat.com>

On Wed, 20 Jun 2012 12:46:19 -0400, Dave Brolley wrote:

 brolley> The use of NSS/NSPR on its own does not provide SSL/TLS
 brolley> connections. The client and server must both agree to and
 brolley> expect the use of a secure connection. The idea would be to
 brolley> have an insecure connection made as normal and then to
 brolley> provide some sort of protocol by which the client and/or
 brolley> server can request an upgrade to a secure connection (think
 brolley> STARTTLS). In this way existing pmcd clients and agents can
 brolley> still connect to pmcd without change and future clients and
 brolley> agents can still use insecure connections if they choose.

Couple of things to note:

1. What is the 'killer app' for secure connection? I know Frank and
   Mark had talked in the past about the need to "authenticate"
   clients to be able to provide finer granied access control.

   If this is the real driver behind this work then I think some sort
   of strawman to how how it can work end-to-end, i.e. how can pmcd
   verify that it knows the client would go a very long way in proving
   that the abstraction actually makes sense.

   Otherwise it's just 'everything must be encrypted' mantra which
   doesn't really make sense when talking about performance
   monitoring - think of Schroedinger's cat.

2. In PCP world pmcd can send unsolicited PDU to the client. This kind
   of communication does not map well on STARTTLS-like paradigm unless
   you're planing to delay STARTTLS phase until after connection
   handshake is done.

3. Who's going to decide what it's time to 'starttls'? Usually it's
   the 'client' decision but client needs to know that server is
   capable of this. How is it going to be communicated to the client?

 brolley> A second issue is that many components use sockets, files
 brolley> and pipes seamlessly and that file descriptors representing
 brolley> all of these are passed to some functions. As a result,
 brolley> these functions must use the abstracted data types and I
 brolley> have had to extend the POSIX-NSS/NSPR abstraction to normal
 brolley> file and pipe I/O in many cases. I have, so far, left as
 brolley> much code as I can unabstracted, however, for the sake of
 brolley> consistency, it may make sense to convert all I/O (at least
 brolley> within the pmcd) to use the abstraction layer.

I thought that Nathan has already gone and done the necessary changes
to separate functions which deal with real sockets from functions
which deal with 'other stuff' like file descriptors as part of Windows
port.

max