[TLS] Apologies

[Martin Rex <[e-mail]>]

Dear Marsh, Pasi, Eric, Joe, Nelson and several others,

I want to apologize to you

for having been a mean and offending a*****e at various times
during the discussion on this list over the last 6 weeks.

I really did not mean to slander on anyone's qualification as a
software engineer, and I really envy everyone working for a
smaller company than I do, for not having to wrangle with so
many software logisitics processes as I'm facing in my work.


I'm really only interested in the technology and want to provide
value to my customers based on the technology developed in this
forum, and since many of our customers are running pretty big
intranet installations or our software that is connected to
a lot of hardware controls (materials management, supply chain
management, logistics) with a plethoria of devices I have
never seen myself, I'm concerned about changes to this
technology that may have an impact on the installed base
of our customers.

I assume that those long-standing key contributors to the TLS WG
who were asked to join Project Mogul to help produce a solution
to this serious vulnerability in the TLS protocol had to sign an NDA,
and did not deliberately exclude the rest of us from the discussion.
I could imagine that they felt quite uneasy about this situation.

It is definitely not my intention to get in the way of providing
a solution, I only want to help getting off some rough edges
in the solution so that the likelyhood of casualties and severity
of the damage out in field will be small.

Some of the commercial providers have a lot of experience with
the presence of TLS extensions in the products they ship, because
they have been testing these capabilities over the course of
several years.  Evidently, it hasn't been easy for them either,
visible from the availabilty of re-connect fallbacks to extension-less
Hellos in pretty much all current apps that use TLS implementation
capable of TLS extensions.

For some of the mainstream consumers of this technology, and that
includes us, sending out TLS extensions is a first.  The third-party
OEM SSL library that we acquired 10 years ago has never before sent
out any TLS extensions, and none of our applications on top of
it therefore has any re-connect fallback provisions that could
be used if suddenly sending a TLS extension results in an interop
problem.

In difference to many other software vendors, we support our
software for around 12 years (2 years of that is development,
10 years usage) on a platform, which is what our customers demand
from us and for which they pay a non-negligible amount of maintenance
fees.  This time of active usage is often longer than the maintenance
provided by the vendor of the underlying platform.

It around 40 different hardware platforms and os-releases
(32-bit and 64-bit where available) and includes fairly
exotic platforms such as IBM OS/390 aka z/OS (an EBCDIC-platform,
where our oldest supported OS-release still in use at our customers
is OS/390 10.00), which was dropped out of vendor-support maybe 5 years ago.
More mainstream platforms may be RedHat 6.1, OSF/1 4.0, Solaris 2.6.

It's difficult to find an OEM who covers such a huge variety of platforms
and for such a long time, long exceeding the maintenance of the
OS vendors.

Simply switching from one supplier to another is not an option,
because the is much more to TLS than the wire-protocol.  There are
APIs, API-semantics, and most of all credentials and trust-anchor
management and UIs around that.  Dealing with the PKI-configuration
and policy parts of the software is much more difficult and
time-consuming that dealing with the TLS communication part.


I would really apprececiate if we could get back to work and
treat each other like professional engineers.


Sincerely,
-Martin Rex