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

[Eric Rescorla <[e-mail]>]

At Mon, 30 Nov 2009 11:07:45 -0600,
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.]

I don't really agree that this is a serious objection. As I said
earlier, the security of TLS requires that the peer behave correctly
in a variety of unobservable ways. If it doesn't, we have far
more serious security problems than this (in particular, in order
for the failure you're concerned about to occur, this failure
requires *both* sides to be incorrectly implemented, whereas there
are plenty of issues that can be created by merely one side being
incorrect).

Moreover, there *are* implementation errors where the various proposed
alternative signalling mechanisms can go wrong as well, as our discussion
over the past few days indicates. So I can't even agree with the
characterization of this issue as "fail-safe" versus "fail-unsafe".
Rather, each solution is subject to different kinds of implementation
screwups. I don't find the argument that the screwups you can
make with RI are somehow easier to be particularly convincing.

Moreover, if you're really concerned about TLS being safe in the face
of implementation errors, you should worry about designing mechanisms
that are safe in the face of PRNG failure, seeing as we've seen at
least two such errors in live TLS stacks.

-Ekr