Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Jacob Hoffman-Andrews <[e-mail]>]

With all respect to the authors for a well-written paper, this draft
should not be adopted by TLS WG, because it would weaken the security of
TLS as deployed in practice.

If the TLS WG were to adopt this draft, one of the likely outcomes would
be implementation in a variety of popular TLS libraries, like OpenSSL
and SChannel. Unfortunately, including interception capability in
off-the-shelf software is like keeping your plutonium next to your
potato chips; something is bound to go wrong. For instance, performance
advocates may suggest turning on the interception capability in order to
save cycles. If such advice is broadly adopted, we will effectively have
reintroduced non-forward secret sessions to TLS. In TLS 1.3 there are no
NULL cipher suites. Why should there be a commonly implemented mode that
breaks forward secrecy?

The "Weaknesses of Alternative Solutions" section nicely sums up the
tradeoffs of various techniques. Under "Export of ephemeral keys," it says:

> The complexity of the solution is a problem that adds risk.

This is absolutely true, but doesn't mention the bearer. The enterprise
that requires the interception bears the risk (or, more likely, the
vendors who sell interception software). I think when balancing the
monetary risk to the enterprise against the privacy risk to billions of
consumer Internet users, the consumers should win.

I would also point out that retrospectively decrypting pcaps asks TLS to
do double duty: as at-rest encryption in addition to transit encryption.
If, instead, each TLS server shares a copy of its plaintext via a TLS
connection to an encrypted storage service, the enterprise gets much
better security properties. Not only does it retain forward secrecy for
in-datacenter traffic, it can control the keys for at-rest data much
more tightly. Instead of every TLS frontend having the keys for
retrospective decryption, those keys can be limited to auditors or
security team members.