Re: [TLS] TLS renegotiation issue

[Martin Rex <mrex at sap.com>]

Nicolas Williams wrote:
> 
> Initial comments based on a brief skim:
> 
>  - Please add a normative reference to RFC5056.

I admit to not know what that exactly means, but it sounds wrong.

It is perfectly possible to write this document in a fashion that
an implementor does NOT NEED to read rfc5056, and therefore I
would strongly prefer to keep it that way.

> 
>  - There's no real need for the ServerHello to include both of the
>    Finished messages from the outer TLS connection.  (I think there's no
>    real need for the ServerHello to include either of them, actually,
>    but I've not thought enough about that.)  But it's OK as is, of
>    course.

The Server should send back something different than on initial
connect in order to indicate to the client that it is convinced
this is a renegotiation rather than an initial handshake.

Sending back the verify_data from Server finished seems fair to me.


> 
>  - You call for each TLS handshake to bind to the one immediately
>    outside it.
> 
>    Would it be better to bind to the outer-most one instead?

I prefer it the way it is currently described, referencing the
predecessor.

> 
>    (In practice there's probably never more than one outer and one inner
>    handshake, right?)

Technically, there can NEVER be more than two, as required by
the TLS spec (there is only one current and one pending) so technically,
the existing proposal is referencing the "outer-most" TLS session.

You were probably asking for the first TLS-handshake on a connection?

The existing proposal looks like less code to me.

> 
>  - There is a way for clients to protect themselves even when servers
>    don't implement this extension:

I would hope there is a way, but I have not seen one so far!

There are actually two different scenarios:
the one I suggested where both sides, client and server perform
a renegotiation, and the one described by Marsh, where a clients
initial TLS handshake is proxied into a renegotiation for the
server.

Without a change of the server, the client has certain difficulties
to determine whether it is participating in an initial TLS handshake
or being proxied into a renegotiation in Marsh's scenario.

There are certain safeguards a client can apply (but which are not
currently advised by the spec, so are unlikely to be implemented
in existing clients.

A TLS client could insist on a server credential to not change
during a renegotiation.  That helps for my scenario, but
not for that of Marsh.

A TLS client should probably not accept a HelloRequest and neither
a CertificateRequest message on a server-anonymous TLS session
(DH_anon).


> 
>  - Might as well update RFC5246 to indicate that the Finished messages
>    for any connection MUST be exported to applications.  Better get this
>    done now.

I haven't sufficiently thought about this to like it.

Adding the finished messages to the renegotiation handshake
is fine, because they have originally exchanged under the protection
of the currently active ciphersuite, so this should have zero impact.

You're asking to make something available that has not been previously
available to the application.  This might be harmless, but I don't know.

-Martin