Re: TLS API discussion

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

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.


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).

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.")

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?

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.)

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.

So ... how do YOU think applications should use TLS sessions?  Or use
peer authentication?  What control do they need over handshaking?

- Dave