Re: [TLS] Next steps for draft-ietf-tls-renegotiation

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Fri, Nov 27, 2009 at 11:26:34PM +0100, [e-mail] wrote:
> > <wearing Area Director hat>
> > 
> > I have asked the secretariat to start IETF Last Call for
> > draft-rescorla-tls-renegotiation-01.
> > 
> > I've gone through the list archives for the past month, and it seems a
> > large majority of the WG members support the overall approach in this
> > draft (with a small, but very vocal, minority preferring a totally
> > extension-less approach to signalling).
> 
> I don't think that's a fair nor complete characterization of the current
> differences of opinion.  A more complete and correct characterization
> might be:
> 
>  - The RI proposal has a fail-unsafe requirement that peers check the
>    contents of the extensions sent.
> 
>    NOTE: A fix for this wouldn't require an extension-less signalling
>          solution.
> 
>    [IMO: This is serious objection that goes beyond protocol design
>          aesthetics or ease of retrofitting for SSLv3.  I think we can
> 	 live without a fix for this problem, but I'd much rather have a
> 	 fail-safe solution.]


What makes me feel somewhat uncomfortable is the situation when the
client is doing an initial handshake and the server is doing a
renegotiation handshake:

The client will send an emtpy extension.  The server should abort.

But if the server is a little sloppy, and sends back an empty
extension in ServerHello (matching the empty extension received
in ClientHello), then the handshake will succeed.

In that case, the renegotiation vulnerability will be still present,
but this will not be obvious in the regular interop-testing and the
client has no way to detect that the server is goofing his job.

The problem is, that it is so extremely easy for the server to
goof his job.  If we add the verify_data to the renegotiation
and something small but different to the initial handshakes
between updated server and updated client, then it will be
extremely difficult to get it wrong and still interoperate
-- it will be _much_ easier to interoperate hand have it correct.


-Martin