On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > On 08/07/17 18:05, Russ Housley wrote: >> In draft-green-tls-static-dh-in-tls13, there is not one. I have not >> thought about it in these terms. The server, if acting in bad faith, >> can always release the client's traffic. > Is it bad faith if the server is compelled to enable this > wiretap interface? For a wiretapper this is a great scheme, > as they only need to force it to be turned on and accept a > tiny bit of data and then they can pick up those packets > from anywhere without having to deal with problems at the > web server end. So no need to even re-imburse the web server > for the intercepted access anymore.
The same applies to static RSA ciphersuites. I understand your desire to move on with TLS 1.3, but we did burn what seemed to be a somewhat important usecase to some people, and this draft demonstrates that TLS 1.3 can be deployed in datacenters without hurting that usecase. As much as I think enterprise networks are suffering from bad design decisions that solve problems with boxes and not endpoint changes, this is a problem people are claiming to face, and there are some security implications. Servers already use static DH, in some cases by accident. > > Honestly, doesn't that clearly mean a conflict with 2804? > And one that cannot afaics be avoided. Why did static RSA not imply that? > > S. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
