On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria <sank...@cdac.in> wrote:
> Hello, > > How is Certificate Compression advantageous over tls cached-info extension? > Only case I can think of is - when the certificate is being sent for the > first time, > it can be compressed. Since the client doesn't have a copy of the > certificate, > cached-info can't be used. Are there more cases where compression is > useful? > Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2 Is compression not a simpler implementation - given the 'two' hard problems of computer science (caching, naming, off-by-one)? For example, you'd need to maintain a per-host cache of certificate information to meaningfully make use of it (... or else you end up with cross-origin state leakage, at least in the context of a browser, which is a Bad Thing). You would either need to read that information from stable storage prior to making the connection (so that you can negotiate the cached info), or you'd need to do a lazy-path where you index the cached entries and send those as available to the server, while in parallel beginning to load those entries. If those entries are corrupted, but used in the connection, the connection will fail. If those entries are removed during the connection establishment, the connection will fail. In short, cached-info represents a much greater degree of complexity and questionable privacy (both cross-origin and same origin - again, something relevant for browsers, but perhaps not relevant for others). Let's keep it simple :)
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
