Re: [TLS] matching identity, by default

[Marsh Ray <[e-mail]>]

Bodo Moeller wrote:
> On Dec 3, 2009, at 2:54 PM, Marsh Ray wrote:
>> Bodo Moeller wrote:
> 
>>> TLS has never meant to allow a new
>>> client or server application entity to enter the conversation when a
>>> renegotiation handshake takes place

Granted, they didn't expect it to be MitM-able.

>> I disagree. The person(s) who added renegotiation clearly wanted to
>> enable multiple "application entities" to run on the same port 443.
> 
> I don't think this is true, and certainly not clear -- for example, see:

Here's what I've been reading, which goes back earlier:

http://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

INTERNET-DRAFT                  SSL 3.0                November 18, 1996

"The client can also send a client hello in response to a hello request
or on its own initiative in order to renegotiate the security parameters
in an existing connection."

What exactly are these "security parameters" the authors are referring
to? Well the document doesn't define the term exactly, but uses it again
with more context:

"Sessions define a set of cryptographic security parameters, which can
be shared among multiple connections.  Sessions are used to avoid the
expensive negotiation of new security parameters for each connection."

"The cryptographic parameters of the session state are produced by the
SSL Handshake Protocol, which operates on top of the SSL Record Layer.
When a SSL client and server first start communicating, they agree on a
protocol version, select cryptographic algorithms, optionally
authenticate each other, and use public-key encryption techniques to
generate shared secrets."

It certainly sounds to me like the spec intended to allow anything that
was valid in an initial negotiation to be valid in a renegotiation.

Interestingly, variations on the word "renegotiate" only appear three
times. The Hello Request message does not use the term, instead it talks
about a new "negotiation". To me, this reinforces the idea that the
authors of the SSLv3 spec intended renegotiation to be fully equivalent
to a new handshake.

> Also, ever since the SSL 2.0 protocol specification, the documents have
> said that the client is one application entity ("the application entity
> that initiates a connection"), and the server is one application entity
> ("the application entity that responds to requests for connections from
> clients").  If you look at the SSL 3.0 specification, renegotiation
> takes place between "the" client and "the" server.  A scenario where one
> SSL-level client does multiplexing on behalf of multiple
> application-level clients, or one SSL-level server does multiplexing on
> behalf of multiple application-level servers, just wouldn't be covered
> by this.

The 3.0 spec uses the term "application entity" in two places"

"client               The application entity that initiates a connection
to a server."

"server               The server is the application entity that responds
to requests for connections from clients.  The server is passive,
waiting for requests from clients."

These definitions were inherited verbatim from the SSLv2 spec, so I
don't think much weight was placed on the term "application entity". In
any case, it just refers to the initial connection process which
esatablishes the roles of client and server.

But I believe one of the initial motivations of renegotiation was to
enable multiple CGI-type applications to run on the same server. These
could certainly have different authentication requirements, and
renegotiation was added (at least in part) to provide for dynamic
(re)authentication.

>> These may be communicated over the same pool of active socket
>> connections, as Nelson Bolyard of NSS (hier of the Netscape legacy
>> implementation, twice removed) has described.
> 
> Where has he described this?  (Sorry -- I've tried to find something
> using various keywords, but to no avail.)

Sorry, I think it may have been a private mail. Nelson, would you mind
posting that? I refer to it often. I have it in my box dated 10/16/2009
6:27 PM Message-ID: <[e-mail]>.

I'm sure he wouldn't mind me sharing this tidbit:

"It is also possible that, in response to a client hello request, the
client will send a client hello bearing a session ID that is not empty
and is NOT the session ID of the session presently in use on that
connection.  This can happen when the client has multiple connections
going in parallel between the same client identity session cache and the
same remote server."

Now I don't perfectly understand how Mozilla handles its "client
identity session cache" (I suspect no one does), but it sounds plausible
to me that renegotiation with resumption could, in theory, switch
between differing client certs over the same connection.

This might be fun to test, actually.

>> If someone wants to write a TLS
>> application layer protocol that way, there's no good reason for the spec
>> to prohibit it at this stage in the game.
> 
> As explained above, I don't think this would be within what the SSL/TLS
> base specification allows -- of course you can still decide do it
> anyway, as a custom modification to the standard protocol.

What wording in what spec prohibits it?

Everything I read is consistently "anything goes" in renegotiation, just
like an initial handshake. OpenSSL, for example, had to add new code in
order to disable renegotiation: there was previously zero special-case
handling for it.

> Well, I guess we could cater for that, by again saying "by default":

This does not appeal to me in a spec. It seems like it would be saying
"here's how you have to do it ... except if you don't want to, then just
do whatever".

> "A TLS renegotiation handshake is a new handshake, including new cipher
> suite negotiation, and new Certificate messages where applicable. 
> Accordingly, in the renegotiation handshake, clients and servers can use
> identifying information that is different from the identifying
> information used in the preceding handshake.  (For example, one use of
> renegotiation is for TLS servers to initiate client authentication by
> sending a CertificateRequest message only when demanded by the
> application layer, in response to specific application-layer requests. 
> The renegotiation handshake thus is expected to involve a client
> Certificate message when the preceding handshake did not.  Furthermore,
> cipher suite selection during renegotiation will have to obey any
> restrictions imposed by CertificateRequest.certificate_types, and thus
> may require a different server Certificate message.)
> 
> However, even when a TLS renegotiation handshake takes place,
> application data <NEW>normally</NEW> continues to be handled by the same
> application entity as before.  TLS implementations <NEW>by default</NEW>
> MUST NOT use a change of Certificate information to indicate that
> subsequent application data will be in the responsibility of a different
> client or server application entity.  That is, if a new or changed
> Certificate message appears in a renegotiation handshake and is
> successfully verified, it is understood that this is a change in
> identification information only and not a change in identity. 
> <NEW>Still any party relying on peer authentication remains responsible
> for verifying authentication information even on renegotiation
> handshakes.</NEW>
> 
> <NEW>Some application protocols might have to use the TLS protocol in a
> nonstandard setting where a single connection is used with renegotiation
> to multiplex for multiple application entities.  The design of such
> application protocols requires special care to ensure that application
> data cannot be processed or sent in an inappropriate context, taking
> into account that the TLS protocol generally allows application data to
> be interleaved with renegotiation handshakes, and that the record layer
> cannot generally be expected to preserve application message boundaries,
> and may send application data at lower priority than other content
> types.  Thus, such application protocols will have to specify their
> special requirements on TLS implementations.  TLS implementations to be
> used for such applications may require additional API facilities.</NEW>"

This is outside the scope of the wire protocol and on new territory
attempting to specifying the library API. Not saying that's necessarily
bad, but more than likely it will simply be ignored.

What I think would be far more useful is a practical treatment of the
best practices and possible pitfalls for implementing and using typical
library APIs. Some of this is in Appendix D. Implementation Notes, but
it could be given its own section with advice like:

* Although most TLS libraries will properly validate a cert, the
application code is usually still responsible for checking that the cert
identifies the intended host. This is because the exact method to be
used depends upon the application protocol in use. This check MUST be
done at the earliest opportunity during the handshake process. This
usually necessitates an application-supplied callback function be
registered with the TLS implementation. Returning a failure code from
the callback MUST terminate the handshake.

* The TLS protocol allows application data to be interleaved within
rengotiation handshake messages. Sometimes this is desired, but may
require extra care. The application-supplied callback and TLS library
normally SHOULD discard any buffered plaintext at the point of
renegotiation. It is recommended that TLS libraries default to neither
sending nor accepting of application data during a renegotiation
(between the Hello and the Finished handshake messages).

and so on...

- Marsh