Re: TLS API discussion

David Brownell wrote:
> 
> If portability is a primary concern, I've got a rather portable
> Java API to present!  :-)

  Yea,  so do we.  Love to see what you got there Dave!  :)
> 
> Before an API (in some language) is settled on, it strikes me there
> ought to be some agreements on exactly what features should be
> exposed, and how.  If those can't be agreed on, then there may be
> no real virtue in trying to focus on some specific C/C++/Java/...
> interface set.

  Absolutely right.
> 
> Sessions and associated data (active cipher suite, peer cert chain,
> creation time, etc) seem like no-brainers ... but then, how are
> applications supposed to associate data with those sessions?  It'll
> be important to let apps be involved in session creation/destruction,
> both by providing policies (must/mustn't create a new session here,
> invalidate now, invalidate after N hours not in use, etc) and
> notifications (just created/destroyed this session etc).

  IMHO, and interface facility better services these needs.  Also
more flexible and easier to impliment.
> 
> Handshaking seems to me to be a lot easier.  Even there, one finds
> issues.  It's easy to say "enable only these cipher suites", or
> "handshake now" (and tell me when it's finished).  But surely some
> folk will claim it's important for clients to prioritize suites,
> or for servers to choose amongst clients' prioritized suites, at the
> application level ... and such policy flexibility is annoying to get
> well tested.  (Similarly, "re-key after every N Megabytes.")

  Same comment as above.
> 
> Stuff like peer authentication is curiously tricky too.  Where is the
> agreed standard for X509v3 certificate APIs?  That's unrelated to SSL,
> but one sort of needs an API there to use SSL well.  How do applications
> say whether they accept the cert chain proferred during handshaking?
> How does the TLS layer get access to the N different private keys
> (and associated cert chains) it may need to authenticate itself?  How
> do clients choose which of the M appropriate cert chains to send?

  Again, same as above but with a twist.  The interface can easily
provide
for these considerations and additional considerations as they present 
themselves.  Chenging a standard for some of these type of requirnments
seems a bit lengthy a process to me.
> 
> Plus, oddly enough, there are languages where TLS sockets "need" to
> work differently from other sockets.  Hmm.  Even C++ can't do what
> Java does, since there's no 100% standard "Socket" class which is
> used by everyone.  So, there are clearly going to be some areas where
> the API functionality needs to differ between different languages.
> 
> The discussion I've seen so far on this list seems focussed on low
> level issues ... what about policies for how the data exposed by TLS
> gets used?  For example, isn't the whole point of TLS-izing SMTP to
> create a "trusted" mail network, used to ensure that senders, forwarding
> agents, and recipients are who they say they are?  Thus being able to
> do stuff like exclude forgers and abusers (SPAM SPAM SPAM)??  (I'm not
> forgetting privacy-in-transit, but remember that forwarding agents get
> the plaintext anyway.)

  Good point.
> 
> We need to be thinking more broadly about how the capabilities of TLS
> get used by applications ... and then ensure they get exposed in the
> TLS APIs.  We can of course try to expose every protocol feature in
> a "basic" API, but that quickly get unwieldy.

  I have been saying this sience the conception of TLS itself.  Sigh...
> 
> So ... how do YOU think applications should use TLS sessions?  Or use
> peer authentication?  What control do they need over handshaking?

  I don't necessarly see any need for any limitations on how TLS should
use sessions necessarly.  Controls are, of course going to very
depending
on implimentation needs.
> 
> - Dave

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. 
Phone :913-294-2375 (v- office)
E-Mail [email protected]