Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > 
> > So you want the IETF to rubber-stamp an obviously inferior approach
> > because you prefered to come up with a solution in secret?
> 
> That is being unfair.
> 
> It was not EKR's decision to work on a fix in secret, it was mine and
> Steve Dispensa's. We thought that we would have a better chance at
> presenting a good fix for the bug along side its disclosure if we
> brought some of the relevant engineering types together at the beginning
> of the process.
> 
> We did tentatively agree on a proposal for an Internet Draft in secret,
> and now we are seeing the limitations of that approach. It would not
> have been anyone's first choice, least of all EKR's.


It is _not_ my intention to critizise that people develop ideas or
protocols outside of the IETF (open or closed group) and then come
to the IETF for standardization.  That's actually quite common and
not a problem.

But when a proposal enters the IETF process, the IETF and the
working group should discuss it based on its technical merits.

I'm getting the impression that the technical merit is not getting
the attention that it deserves.  TLS extensions are evidently largely
untested in the installed base.  The majority of the installed clients
does _NOT_ send it, and those clients that have started sending it,
apparently didn't dare to do this without an automatic fallback.

Having to retrofit the TLS extensions in a generic fashion into
SSLv3 and TLSv1.0 servers is a completely unnecessary and trivially
avoidable roadblock for maintainers.

And it doesn't seem to be to leave the fallbacks or SSLv3-compatibility
options that exist in current Browsers completely out in the rain,
where we could also trivially cover those scenarious with the
smaller and easier-to-implement extension-less approach.


Considering the urgency of the problem, now is a particularly
bad time to begin gathering interop experience with TLS extensions,
given that TLS WG didn't care about them for years.

To me, it looks like the REAL problems with the installed base described
in draft-pettersen-tls-interop-experience-00.txt (June 2006 !) didn't
result in any significant actions by the TLS WG to improve this, let
alone determine the scope and severity of the problems.


Quoting Section 6. of  draft-pettersen-tls-interop-experience-00.txt

   6.  Consequences

   As a consequence of the problems detailed above, many mass-market
   client vendors have had to deploy SSL/TLS implementations that
   disable protocol features if the server does not understand it.  In
   particular, this was necessary both for the move to TLS 1.0, and to
   TLS 1.1, but it has also become necessary for TLS Extensions.


-Martin