Re: [TLS] assert TLSext in renego-ServerHello instead of disable

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Marsh Ray wrote:
> > 
> > Martin Rex wrote:
> > > Allowing
> > > server to assert this particular TLS extension in the ServerHello
> > > of a _renegotiation_handhshake_ without having received it in the
> > > ClientHello
> > 
> > What's going to check it?
> 
> The client will have to check it, of course -- or abort with
> a handshake failure.
> 
> It is not very nice to drop the entire responsibility on the client
> (which could be silently ignoring the server hello extension), I agree.
> Such a semantics would change an opt-in for secure renegotiation into
> an opt-out.
> 
> The underlying scenario, that we are looking at, is that the server
> is asking the client whether it takes responsibility for the contents
> of the previous session.

Thinking about it, it is probably too daring to interpret the
absence of an error as the confirmation of intent.

How about an alternative HelloRequest, a "SecureHelloRequest",
that signals to the client it is supposed to assert the
secure renegotiation TLS extension on the renego ClientHello
including the verify_data of the last client.finished
or the server will abort the handshake.

I'm wondering what a Server with an existing SSLv3 (0x03,0x00) session
can do if it wants either a secure renegotiation or abort.

Since SSLv3 does not define a "no_renegotiation" alert, a server that
sends a HelloRequest and the determination to abort on insecure
renegotiation could as well send a SecureHelloRequest in order
to "encourage" a client that is only configured to send SSLv3
ClientHellos for maximum connectivity (and no app-level fallback).

-Martin