Just want to +1 the notion that this should be opt-in for both sides and in an extension!
On Sat, Jul 8, 2017 at 23:16 Nick Sullivan <nicholas.sulli...@gmail.com> wrote: > 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 > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
