Re: Changes after IETF last call for 2487bis

[Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Paul Hoffman / IMC <phoffman@xxxxxxx>:

> There were two significant commments that came out of the IETF last call.
> 
> The first was a disagreement from Keith Moore (with agreement from 
> Ned Freed) about the addition of the text that described 
> interoperating with earlier versions of SSL. In retrospect, I agree 
> that the text that was added didn't help an implementor create an 
> interoperable system and in some ways made it harder. Thus, I have 
> removed that paragraph from the document. Of course, this does not 
                                            ^^^^^^^^^^^^^^^^^^^^^^^^
> prevent client and server implementations from recognizing multiple 
  ^^^^^^^^^^^^^^
> versions of SSL/TLS during the SSL negotiation.

Wrong.  It does not prevent *servers* from recognizing multiple
versions of SSL/TLS -- they can easily be more tolerant than required
by the specification.  However, it does prevent *clients* from
recognizing earlier protocol versions: They'd have to use backwards
compatible Client Hello messages; but this works only if they can
expect even TLS-only servers to be able to handle such backwards
compatibility.

The current specification is fuzzy enough with respect to version
differences that most implementors don't take the "TLS" thing too
literally (RFC 2487 uses "SSL" and "TLS" as quasi-synonyms and claims
that "TLS is in wide use with the HTTP protocol", which surely was not
true for TLS 1.0 back in January 1999), so backwards compatible Client
Hello messages are no problem in practice.  But now that TLS 1.0 has
been fielded for some time, there's a growing risk that implementors
might believe that when a new RFC says "TLS", it means strictly "TLS".
Maybe even RFC 2487 strictly meant "TLS" and just its Introduction was
bogus, but anyway: TLS-only servers currently have to support
backwards compatible Client Hello messages to be useable as publicly
referenced MXs.

No current STARTTLS server implementation is known that cannot handle
backwards compatible Client Hello messages.  While this was not an
explicit requirement of RFC 2487, it was and still is a requirement of
real life.  (And no matter what the new RFC says, many clients *will*
continue to use backwards compatible Client Hello messages because
these quite simply are less likely to cause interoperability problems
than pure TLS 1.0 Client Hello messages.  It's nice to obey an RFC by
the letter, but in this case I'd leave that to aspiring martyrs.)


-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036