Re: I-D ACTION:draft-hoffman-rfc2487bis-02.txt

On Mon, Sep 13, 1999 at 09:47:53AM -0400, Paul Hoffman / IMC wrote:

[section 3]
>                     [...] If no one *could* handle a text QUIT at that 
> point, Bodo's MUST NOT seems sensible. It would mean that, if a client 
> wanted to say "whoops", the only way would be to drop the connection, but 
> that is probably better than confusing the TLS stack with unexpected garbage.

Exactly.  While the current specification may be not much of a problem
for some implementations (those who read from the network into
application-internal buffers and then forward the data to the TLS
library, if appropriate; or those running on OSes where, unlike with
the standard socket interface, you can un-read data read from a
network connection), it is utterly inconvenient for all those
implementations where such extra buffering is avoided and the TLS
implementation is given a socket identifier to work on.

I could handle such situations with 50 % of the TLS applications I'm
currently working on (except that I have no plans to implement an SMTP
server on the platforms where it would work), but even there I would
not really want to put details on how a valid client hello can look
like into the application -- that's the TLS library's job, and anyway
it's just a coincidence that none of the current client hello formats
starts with a byte that looks like a printing ASCII character.

Also it's unlikely that the client wants to say "whoops" after having
sent STARTTLS.  It's more likely that the server says whoops after
reading the client hello (e.g. DSA-only client, RSA-only server);
or the client after receiving the server hello (e.g. the server's key
size exceeds a limit of its TLS implementation), and then it is too
late.


[section 7]
>> Maybe we can agree on something like "... whether an acceptable degree
>> of authentication or privacy was achieved"?  [...]

> I'm fine with this wording.

Good.


[backward compatibility]
> OK, I'm unclear what you're asking for here. What words would you want 
> added to the spec to handle or not handle SSL 2.x and 3.0?

Nothing to handle actual SSL connections, but the specification should 
say roughly the following:

  -  Clients implementing RFC 2487bis MUST use a TLS version number in
     their client hello messages, and not the SSL 2 or SSL 3.0 version 
     numbers, even when using backward compatible client hello formats.

  -  Clients MAY use the SSL 2 client hello message format to achieve
     backward compatibility with servers that support SSL 2 or
     SSL 3.0, but not TLS (as described in appendix E.1 of RFC 2246);
     connections with such servers are out of the scope of RFC 2487bis.

  -  Clients MAY use the SSL 3.0 client hello message format (i.e. use
     version number 0x03 0x00 in the record header) to achieve
     compatibility with servers that support SSL 3.0, but not TLS:
     connections with such servers are out of the scope of RFC 2487bis.

  -  Servers MUST accept client hello messages in the SSL version 2 and
     SSL 3.0 format if these request a TLS connection.
     They MAY accept SSL connections, but such connections are out of
     the scope of RFC 2487bis.

This allows clients to be friendly to existing SSL-only servers
without having them run into problems when talking to TLS-only
servers.