
Data Center Use of Static Diffie-Hellman in TLS 1.3 - based2
https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-00
======
cesarb
The background is probably this email thread: [https://www.ietf.org/mail-
archive/web/tls/current/msg21278.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg21278.html)

Previous discussion of that email thread:
[https://news.ycombinator.com/item?id=12641880](https://news.ycombinator.com/item?id=12641880)

Basically, someone noticed (too late) that TLS 1.3 no longer has the RSA key
exchange, which they liked because it allowed decryption of the encrypted
traffic by passive middleboxes (which have a copy of the RSA private key).
This draft is probably a response to that.

------
vorpalhex
This is concerning. While TLS interception may be desirable by some, this is a
dangerous precedent and I hope the de facto standard for all software will be
to block and disallow this kind of behavior, and warn when it's been enabled
("This connection is not fully secure").

------
abrodersen
Browser vendors should show a security warning when encountering this
behavior. Default configurations of all software must be to disallow. The
burden should be on the enterprise to configure their client devices to allow
MITM.

~~~
atonse
This theoretically seems like a good way to alert users, but what exactly
would you even tell users? Most users barely understand past "make sure the
padlock is there" – and many more technical users that I've observed don't
even understand SSL warnings apart from "it's still SSL, make the warning go
away" – so, showing a prompt about something even more obscure like static key
exchange, will be lost on all but the most advanced security people.

There are already plenty of ways for enterprises to get around this, like
having their own CA and deploying that as a trusted CA to their machines. Then
they can issue certs that their proxies could use, and their machines would
just trust those certs.

Why don't they just use that method?

~~~
infogulch
The same thing you do with any other invalid configuration like SHA1 or
expired certificates. Show a warning and a big red x through the padlock.

------
nickik
I just saw a talk at 33C3 about TLS 1.3 and they tell the story behind this
alternative TLS 1.3. Its a pretty fun talk.

[https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...](https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great_the_good_and_the_bad)

------
sigjuice
_... eliminating the Perfect Forward Secrecy ..._.

Seems irresponsible to a layman like me.

~~~
phicoh
There are many ways to achieve the same effect. The most obvious is to install
the private key of the service on the middle box and terminate the TLS
connection there.

More complex is to log the DH private key that is used and make that available
to the middle box.

And as last resort, the server can just send all plain text to the middle box.

There is no such thing as one-size-fits-all security. The important thing of
course, is to make sure that such a feature cannot be turned on accidentally.

I don't know about EC, but in classical DH, if the server uses the same DH
private key for all connections, then a client can detect that (by initiating
multiple connections). So a paranoid client library can issue a warning.

------
justaaron
sounds so complex that I'm in diffie hell, man!

*sorry, couldn't resist :D

