On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote:
> > Most applications want a simple API that hides all the complexities of
> > TLS. If OpenSSL had done that, then it would be easy to see how enabling
> > 1.2 won't cause problems for those apps which said "you take care of it".
>
> As someone with a long history of building, influencing, and using libraries
> and their API's, this is not easy.
Binary compatibility is difficult, and requires maintaining legacy
versions of interfaces with cross-platform symbol versioning and
related magic that transcends the release engineering cycles
available to OpenSSL at this time.
That said, source compatibility is a fairly reasonable requirement.
By and large for applications doing simple things, OpenSSL remains
source compatible all the way from 0.9.5a to "master" (soon to be
1.1.0). Postfix, which uses OpenSSL in a rather more sophisticated
way, has relatively minor adaptations to deal with source compatibility
changes from the 0.9.7 time-frame to the present (we've dropped
support for older OpenSSL versions that was present in earlier
Postfix releases, otherwise that would be 0.9.5 to the present).
Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems
for Postfix, it largely continued to work as-is. IIRC the padding
extension was needed in 1.0.1g to deal with interoperability with
some IronPort systems that had issues with large client HELLO
messages solved by padding. The much larger list of ciphersuites
also caused pain with some rather dated Microsoft Exchange 2003
servers that were still in use. But on the whole the transition
just worked, as it should have.
So recompiling a package against an OpenSSL that supports TLS 1.3,
and fixing occasional issues with now opaque data structures hidden
behind new accessors, should be sufficient for a largely unchanged
application to use TLS 1.3 with no explicit code changes to do so.
> I still want a pony.
I expect to report that Postfix works as-is when OpenSSL is released
with TLS 1.3. This is not an unreasonable expectation.
If TLS 1.3 does not interoperate with opportunistic TLS clients
when servers are configured with pre-existing self-signed SHA-1
certificates, then IMHO the specification is broken.
If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and
OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a
CA-issued certificate signed with SHA-1, then OpenSSL is broken,
for it should then have worked around the specification brain-damage
by selecting TLS 1.2 (presumably the client still supports that).
I am perplexed that folks desperately want that server with that
SHA-1 cert to not be able to use TLS 1.3. Surely, the decision to
not trust that cert (if certs are being checked at all) belongs in
the client.
Provided that weak self-signatures are not proscribed, I am resigned
to "come what may" if nobody else thinks that proper segregation
of duties is important, and that putting up some needless roadblocks
to TLS 1.3 use is the price of "progress".
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
