IE 9 and 10RP treats Cache-Control no-cache as no-store. I would expect IE to act the same way other browsers do. Other browsers try to revalidate the request by sending a check using ETAG or modificationdate. IE does not revalidate even if those informations were part of the previous response. IE always performs a new request without revalidation-headers. Due to that IE does get less/no 304 status codes on various sites which results in IE producing more traffic and IE beeing much slower than other browsers.
This bug was already present in previous version of IE (See Bug-ID 415623). Hopefully you get it right this time.
no-cache = "must not use cache without successful revalidation"
If you use the cache with a successful revalidation that's just fine.
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.