Putting questions of whether or not this belongs as a working group document, I think there are some necessary requirements for intra-datacenter passive decryption schemes that are not met by this draft.
Specifically, any passive decryption scheme should the following two properties: 1) Both server and client must explicitly opt-in 2) A third party should be able to tell whether or not this feature is enabled by observing the stream These two requirements protect services on the wider Internet from being accidentally (or surreptitiously forced to be) subject to unauthorized decryption. The static DH proposal satisfies neither of the above requirements. What you likely want is something similar to TLS 1.2 session tickets with centrally managed session ticket keys. The client would advertise support for "passive session decryption" in an extension and the server would return an unencrypted extension containing the session keys encrypted by a server "passive decryption key". The passive decryption key would be managed in the same way as the static DH key in this draft: rotated frequently and synchronized centrally. A TLS 1.2 session ticket-like scheme provides the same semantics as this static DH but provides more safeguards against accidental use outside the datacenter. Both client and server need to opt in, it's visible from the network, and limits the data visible to the inspection service to the session (rather than exposing the master secret which can be used to compute exporters and other things outside of the scope of session inspection). Furthermore, in the session ticket-like scheme, a *public key *could be used to encrypt the session keys, removing the need for a secure distribution scheme for the endpoints. The passive decryption private key could me managed in a secure location and only the public key distributed to the endpoints. Session ticket-like scheme advantages vs this static DH proposal: 1) Mandatory client opt-in 2) Passive indication that scheme is being used 3) Decryption service only gets session keys, not master secret 4) No need for private distribution system for static keys to endpoints In summary, even if this was to be considered as a working group document, I think this is the wrong solution to problem. Nick On Fri, Jul 7, 2017 at 8:03 AM Matthew Green <matthewdgr...@gmail.com> wrote: > The need for enterprise datacenters to access TLS 1.3 plaintext for > security and operational requirements has been under discussion since > shortly before the Seoul IETF meeting. This draft provides current thinking > about the way to facilitate plain text access based on the use of static > (EC)DH keys on the servers. These keys have a lifetime; they get replaced > on a regular schedule. A key manager in the datacenter generates and > distributes these keys. The Asymmetric Key Package [RFC5958] format is > used to transfer and load the keys wherever they are authorized for use. > > We have asked for a few minutes to talk about this draft in the TLS WG > session at the upcoming Prague IETF. Please take a look so we can have a > productive discussion. Of course, we're eager to start that discussion on > the mail list in advance of the meeting. > > The draft can be found here: > > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01 > > Thanks for your attention, > Matt, Ralph, Paul, Steve, and Russ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
