Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > Here is my analysis of the requirements and implementation efforts 
> > for TLS extension RI with magic cipher suites value (MCSV), based on
> >  my recent experiences from implementing 
> > draft-mrex-tls-secure-renegotiation-03 in OpenSSL-0.9.8l and looking
> >  at the early implementation of draft-rescorla in the 
> > OpenSSL-0.9.8-snapshot.
> > 
> > The purpose of the MCSV is:
> > 
> > - provide interop with installed base of old, extensions-intolerant 
> > servers (original&correct SSLv3 and "defective" TLSv1.0)
> 
> The draft-freier-ssl-version3-02.txt says to ignore data after the
> Client Hello, which implies extension-intolerant SSLv3 servers are
> defective, too. Not that it really matters at this point. Had you
> mentioned something about an earlier version not saying that?

The official SSLv3 spec doesn't say that!

The IETF archives do not know freier-ssl-version3-02  (only -00 and -01)
freier-ssl-version3-02 is probably what is known as
draft-ietf-tls-ssl-version3-00.txt -- a document which the TLS WG
chose _NOT_ to publish as informational, and which Netscape did
_NOT_ see as an official spec, otherwise they would have updated
their much more prominently offered versions of the SSLv3 spec
based on the freier -01 draft _without_ the extensibility option.


> 
> > - provide protection in backwards interop scenarios (renegotiation 
> > requested by old servers).
> 
> It will never be safe to conduct renegotiation with a remote party in
> the absence of negotiated RI.

That is wrong.  An old server (potentially an extensions-intolerant one)
does only mean that renegotiation with _that_ old server will remain
unprotected.

What secure TLS renegotiation should protect from is a downgrade attack,
that an MitM acts as an old extensions-intolerant server and then
proxies an updated clients renegotiation with an presumably old server
into the handshake of a backwards-compatible updated server.

Only MCSV can provide this protection.  TLS extension RI on
renegotiation will break interop with all old servers that request
renegotiation.


> 
> The expectation is that clients and servers will be transitioned into
> "strict mode" at the earliest opportunity.

You seem to entirely ignore the transition period.
We can not shut down the entire internet, wait for 6 or 12 months
until everybody has updated every client and server, and then
re-launch the internet.


If we do not provide provisions for smooth interop for at least the
transition period, it will hurt _everyone_!

Users and admins will _not_ install client-side patches if these
are disruptive to some usage scenarios (it's mostly a server problem).
And when clients are not updated, then Server operators that need
that functionality and do not want to loose significant sales
can not disable old renegotiations on their servers.


> 
> > - empty TLS extension RI MUST NOT be sent, ever!
> 
> No, you just shouldn't send it if you prefer to interop with old, broken
> servers. Lots of clients (browsers, etc) currently do send extensions on
> Client Hello, so they may never choose to send MCSV on those connections.

Several hundred millions clients do _not_ send extensions on ClientHello.

> 
> It is hoped that at some point in the future, extension-intolerant (and
> -ignorant) servers will be insignificant and the MCSV can stop being
> sent by clients.

5-10 years.

> 
> Yes, the MCSV is a work-around for old broken servers. This work-around
> does not constitute the endorsement of brokenness by anyone. It's simply
> that in this one bugfix we are choosing to be extra accommodating.

No, MCSV is _not_ only a necessesity for a few broken TLSv1.0 servers,
it is also a necessity for a number of fully compliant SSLv3 servers
_and_ it is an enabler to _relief_ old servers (including extensions-tolerant)
from having to add 5x the amount of code to their code base which has
nothing to do with the underlying security problem.


> 
> > - TLS extension RI with Client.Finished.verify_data in ClientHello -
> >  MUST NOT be sent on renegotiation handshakes in backward interop 
> > scenarios with old servers which could otherwise break
> 
> They are already broken. It's better to break them in a way that doesn't
> represent a vulnerability.

The client can easily abort when it doesn't like the server's answer,
so there is absolutely _no_ justification for the client to send
data that will cause interop problems.  For an updated server in
an MitM attack scenario, the presence of the MCSV is sufficient to
realize that it is talking to an updated client that is probing.


> 
> There's no safe way to renegotiate with a remote party that doesn't
> properly use RI on all handshakes.

You're confused.  This requirement is about protection from MitM-attacks,
it is _NOT_ about successful secure renegotiations (which are not
possible when talking to an old server in backwards interop mode).


> 
> > - MUST be sent in all other renegotiations
> 
> All renegotiations.
> 
> > If the spec would require that an empty TLS extension RI in a 
> > ClientHello MUST be completely ignored, then _everyone_ can save 5-10
> >  LoC.
> 
> Why would you want to ignore that a client is attempting to negotiate
> the use of RI?

Simple answer: to facilitate testing and QA.  Make sure that every
client is correctly sending MCSV.  We do not need two signaling
mechanisms where one is perfectly sufficient.  Besides, MCSV is
3-5 octets less on the wire and you need the code for MCSV anyway--
so the most reasonable solution is to make it mandatory to use.


> 
> Yep. They have to write a few lines of code to implement a tiny part of
> the June 2003 RFC 3546 on TLS extensions.
> 
> > Adding MCSV to ClientHello on the client and parsing MCSV from the 
> > ClientHello on the server will typically be <10 LoC each.
> > 
> > Creating an processing an empty TLS extension RI on the ServerHello 
> > is also typically <10 LoC each for extension-less implementations.
> 
> So you're saying that an implementor who has let their code rot for the
> last 6.5 years could save 140 LoC?
> 
> Personally, I don't find that to be a primary consideration.

Rot for 6.5 years?  What are you talking about?

There is even brand new code under active maintenance without
support for TLS extensions.  TLS extensions is purely optional, not
part of the vulnerability and does not need to be part of the solution.

Besides, in those cases where it is about code that has been mostly
unchanged for 6+ years, it is not "implementers" who will have to
add the secure renegotiation patch, it will often be "maintainers"
with little knowledge about the code -- and then, it makes perfect
sense to ask them for only 20 lines of code instead of 150+


> 
> > Additional types of TLS peers when TLS extension RI is implemented:
> > 
> > 11.) updated TLS client, RI-minimal,    no renegotiation
> 
> Could you explain what you mean by RI-minimal, RI-only, and "extensions".

RI-minimal client (one which does not implement renegotiation):

  sends MCSV on ClientHello, tolerates ServerHellos with extra data
  following compression-method, i.e. will complete handshake
  if that extra data is 7 octets long and resembles an empty extension RI

    0x00 0x05 0xFF 0x01 0x00 0x01 0x00

  and abort the handshake otherwise.

RI-minimal server (one which does not implement renegotiation):

  searches MCSV in ClientHello, ignores TLS extensions completely
  sends back the above 7 octets extra data after compression_method
  in ServerHello when MCSV was found.


RI-only client (one which does not implement TLS extensions in general
  but adds secure renegotiation with TLS extension RI):

  minimalistic TLS extensions support, only for TLS extension RI,
  sends MCSV in initial ClientHellos,
  sends TLS extension RI with Client.Finished.verify_data on renegotiation
  can parse TLS extension RI in ServerHello,
  and in order to reliably recognize updated Servers on renegotiation,
  it must be able to find TLS extension RI among other ServerHello
  extensions (or abort if there are others)


RI-only server (one which does not implemet TLS extensions in general
  but adds secure renegotiation with TLS extension RI):

  minimalistic TLS extensions support, only for TLS extension RI,
  can find and parse TLS extension RI in ClientHello between other
  extensions,
  will send back fixed 7-octet string above on initial handshakes
  and TLS extension RI with content on renegotiation handshakes
  when the ClientHello contains MCSV or TLS extension RI.




> 
> Those tiny LoC differences are not significant, especially considering
> the margin of error for those types of things. Usually you're lucky to
> get within a factor of two.

20 LoC vs. 80 LoC can be a HUGE difference for old code that one
doesn't know.

~20 LoC is  1 day implementing, 1 day testing.
~80 LoC is  3 day implementing, 5 day testing.


> 
> They certainly don't give a realistic indication of "level of effort".

I've been doing development, support, maintenance and QA for mission
critical software for the past 14 year, and I can assure you, they
do give a pretty good picture about the effort.

If you're providing free and open source software, you might not
worry about trial-and-error.

If you are a software vendor that charges for maintenance, then it
is a completely different issue.  You do not change any code that
has been in extended maintenance mode for a few years, and the
original authors of that code are likely not the ones who will
have to patch the code.  There are software logistic procedures
in place that make it extremely expensive and extremely unlikely
that you make code changes that break interoperability "unintentionally".

Have you worked for a software company with 5000+ software developers
during the last three years?


-Martin