Dave CROCKER wrote:
A hallway conversation with Russ added an item that simply had not
occurred to me:
There might be multiple implementations that rely on on undocumented
modifications of the spec. This means that an additional, interoperable
implementation cannot be made purely from the specification.
IMHO this is the most important aspect about "document maturity":
That the document is sufficiently clear and the protocol useful
_exactly_ as specified, so that whenever two independent
implementations fail to interoperate that the one that must be
considered broken and requires fixing is with a high probability
the one that deviates from the specification, rather than
require changes to the spec and all compliant implementations.
There are a number of popular protocols that are heavily used,
but when it comes to interoperability, the devil is in the details
and the details are a huge mess.
TLS is an example of plenty "defective" implementations.
(e.g. protocol version numbers in various places, presence of TLS Hello
extensions or (Hello) compression algorithms, (lack of) sending alerts,
effect of warning level alerts on the handshake, requirement for
certificate_authorities in CertificateRequest handshake message,
requirement for in-order and _complete_ certificate chains, variable
size padding, fragmentation of handshake messages, "server-gated crypto",
sensitivity to certain certificate attributes, misappropriation
of the ASN.1 type T61String, creation and distribution of commercial
RootCA cert for TLS PKI that clearly violates rfc2459+rfc3280+rfc5280,
to name a few)
The result of the mess is that most browsers these days have given
up entirely the concept of SSL/TLS interoperability and use a heuristic
of reconnect fallbacks _at_the_application_level_, i.e. try a protocol
feature, run into one of those interop problems, abort, and the
calling app is supposed to retry with a less optimistic set of
features.
And there are folks who believe that every TLS-enabled application
should have to implement reconnect fallback heuristics to cope
with the SSL/TLS interop mess of the installed base rather than
sticking with a conservative subset of TLS that _is_ fairly
interoperable (extension-less TLSv1.0 or even extension-less SSLv3).
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf