Re: [TLS] To API or not

[Bill Frantz <frantz at pwpconsult.com>]

I would like to add a voice in favor of considering abstract APIs in TLS. I
see abstract APIs as a series of statements like, "The API SHOULD provide a
way for the application to validate and approve the public key of the other
end."

Background: For many years the E language project <http://www.erights.org>,
has been considering moving from our home-brew protocol VatTP
<http://www.erights.org/elib/distrib/vattp/index.html> to TLS. The last
coherent thing I wrote discussing the issue was:

I think the attributes we want to preserve from the existing VatTP are:

   Perfect forward security - Symmetric encryption and MAC keys exist only
   for the duration of the connection. They can not be recovered after the
   endpoints have removed them from memory.

   Distributed public key authentication - The sturdy-refs held by a vat
   contain enough information to authentic the public key sent by the
   remote vat, so additional mechanisms should be avoided.

   The system uses only known-secure algorithms, modes, and protocols.


When I wrote <http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html>,
there was confusion in my mind between supporting SSL and using SSL. In our
case, we want to use SSL/TLS, and do not need to worry about any of the
many CipherSuites (for example TLS_NULL_WITH_NULL_NULL), which are not
applicable to our use. The CipherSuites (from RFC 4346 and RFC 3268) which
seem most applicable to VatTP are:

  TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA - This CipherSuite uses the same
  algorithms as the current VatTP. All are somewhat dated.

  TLS_DH_DSS_WITH_AES_128_CBC_SHA and TLS_DH_DSS_WITH_AES_256_CBC_SHA -
  These update 3DES to the spiffy new AES.

When two vats connect, they exchange public keys. The vats check the public
key they receive against the SHA1 hash in any sturdy refs to be used,
providing assurance that the remote vat is indeed the correct vat. This
procedure is quite different from the certificate authority procedure used
by standard SSL/TLS. It is not clear that all SSL/TLS libraries will have
the user-exits to support this form of authentication. It may be necessary
to adopt an new approach to provide distributed public key authentication.


It would help this process if an RFC gave an idea of what interfaces one
should expect from a library API.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier