Michael D'Errico wrote:
> I think that it would be good to find a unified solution that
> everybody is happy with, and believe that this may be it:
> 
>   1) Client-to-Server signalling can be done in either of
>      two ways:
> 
>      A) an empty Secure_Renegotiation (SR) extension, or
>      B) a "magic" cipher suite
> 
>   2) Server-to-Client signal is always an empty SR extension
> 
>   3) Incorporate previous verify_data into Finished calc.

I like it!

> The particulars:
> 
> A client that currently sends any other extensions MUST also
> send the empty SR extension.

Is the server's behavior defined if he does not? E.g. alert message,
terminate, format C: /y, etc.

Wouldn't a robust implementation have to look out for that condition anyway?

Does this requirement amount to "this will never happen so you don't
have to bother testing for it (until your product hits the net)"?

> A client that currently does not send any extensions MAY send
> the empty SR extension, or MAY send the magic cipher suite.

Can he send both (is the 'or' inclusive)? What happens when the server
receives both?

Can a patched client send neither?

> In response to either 1A or 1B, the server responds with an
> empty SR extension.

The (patched) server MUST respond with ...

If the server does not respond with the extension the client MAY,
depending on external configuration, elect to continue the handshake
insecurely, or alert+abort (specifics).

The client SHOULD check that the extension_data is in fact empty (i.e.,
just its two length bytes of 00 00), and alert+aborting if not.

> The only ugliness is this apparently-
> unsolicited extension returned by the server in response to
> the magic cipher suite. I used to be against this, but have
> since decided that it is no more ugly than flipping a version
> bit or any of the other ideas.

RFC 4346 (TLS 1.1) (and earlier versions)
http://tools.ietf.org/html/rfc4346#section-7.4.1.3
says Server Hello doesn't have extensions at all, yet it is updated by
RFC 4366 which adds them. What we are doing is no different AFAICT.

> It remains to be decided if adding the verify_data to the
> handshake message stream is the right way to do (3), or if
> changing the PRF in some way is better, such as changing the
> seed to be the handshake message hash appended with the old
> verify_data, or some other method.

I think most people are comfortable with that approach.

Suggestions:

This extension applies equally to ALL handshakes on a single connection
regardless of whether they are an initial handshake or a renegotiation.

Client and server MUST negotiate the use of SR in the same manner
(including the choice of magic ciphersuite or Client Hello extension)
for all handshakes on a single connection.

Clients and servers SHOULD detect the case where the other party has
inconsistently negotiated the use of (or not using) SR and immediately
discard buffered data and alert+abort.

> Benefits:
> 
> All versions including SSLv3 are fixed and able to renegotiate
> safely.

Hooray!

> This is entirely backward-compatible with SSLv3, even SSLv2
> ClientHello.  It is better than RI because when the magic
> cipher suite is used there, the server can not check the
> verify_data from the client (since it is not sent), so it
> can not renegotiate with those old clients at all.

Yippee!

> Using an empty extension is much more lightweight a use of
> extensions than RI since there is no need to pack the verify_
> data into it when sending, or to extract the data when
> receiving.

It saves 24 bytes in each direction!

> Clients that don't want to add full support for extensions do
> not need to -- they can just check for the existence of the
> empty SR extension which is a fixed 6-byte string.

Hard for anyone to complain about that, considering nobody was really
happy with the alternatives.

> I would fully support this "new"[*] solution.  Anybody else?

I support the solution!

Can we get the "bits on the wire" part drafted without unnecessary other
baggage?

- Marsh