Re: [TLS] History of extensions

[David-Sarah Hopwood <[e-mail]>]

Martin Rex wrote:
> Eric Rescorla wrote:
>> Nicolas Williams 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 to 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.
> 
> I think you're mistaken.
> 
> The common Web Browsers may have such a fallback, but there are
> much more users of TLS than just Web Browsers.

Yes, of TLS. Not so much of SSL. Most specifications for carrying
other protocols started with TLS, not SSLv3. There may still be some
instances of extension-intolerant servers other than web servers,
but I'm not aware of any evidence that there are enough to consider
that a significant problem.

> The majority of
> programmatic clients don't use such a fallback.  Remember, that
> this fallback is entirely an apps thingy -- you can not put it
> into TLS itself.  So you will need to patch every app using
> TLS to add a reconnect fallback in order to be able to use
> TLS extension RI and not loose connectivity.

No, not at all. The idea that server bugs need to be addressed by
complicated workarounds in clients is primarily a "feature" of the web
(or more precisely the cultural and technical biases of web client
implementors). In most other contexts, a more appropriate response
to a server being broken, is to fix the server.

In any case, the extension draft can and should be specified in such
a way that even if a client does not send the extension on an *initial*
handshake, a connection to a patched server will not be vulnerable.
(The server does not *know* that the vulnerability has been avoided,
but in fact it has.)

> The reconnect fallback is a performance problem by itself,
> and requires a significant of code added to the app.
> 
> I'm sorry, but I don't like this idea at all.

Which idea? I didn't read Eric's post as recommending that all TLS
clients should implement the fallback, or saying that they need to.
(For stateful protocols, reconnection wouldn't necessarily work,
anyway.) His point was that since web clients already implement
the fallback, they won't fail to interoperate. For non-web clients,
TLS- or extension-intolerance have not been demonstrated to be a
significant issue.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com