Re: [TLS] History of extensions

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> > 
> > IIUC the arguments about SSLv3, there's an installed base of SSLv3 and
> > TLS 1.0-with-bugs that is more likely to get patched to fix this and
> > only this than to get upgraded t TLS 1.1+ or to have all their bugs
> > patched.  I'm not sure that that's true.  IF it is true, then we have to
> > consider the possibility of designing the fix so that it's easier to
> > patch those.
> 
> As I said, clients offer extensions already and know how to fall
> back to not using extensions. I don't see that there is a problem
> here.

There are still millions of Web Browsers in use out there that
do not contain a fallback reconnect at the application level.
MSIE 6 comes to mind (I use it on 4 different machines).

A fix that only changes a small amount of code in schannel.dll is
probably easy.  But you're suggesting that MSIE6 needs to be enhanced
with a fallback reconnect in order to allow the TLS renego patch to
be applied without impairing connectivity/interoperability of MSIE6
with a part of the installed base.

That sounds like poor engineering to me.

We can fix this entirely in TLS in a highly interoperable fashion
by using and existing protocol element in the ClientHello handshake
message rather than a relatively new optional feature like TLS
extensions that has demonstrated to cause significant interop problems.


Personally I would not mind if in 6 months my Browser would start
to warn me if I'm connecting to an unpatched server.  But in order
to do that, we MUST have a negotiation which will determine this
reliably through ServerHello.  Making assumptions why a connection
was simply closed by the server (silently or with a fatal alert)
will NOT provide this information.  The TLS extension RI is unable
to provide this information, and that is a significant shortcoming.


-Martin


-Martin