Richard: > Without taking a position on whether this group should take on this work, a > couple of questions about alternative approaches (sorry if these have been > answered before): > > 1. It seems like the requirement here is that the DH private key be > *predictable* by the monitoring box based on some static configuration. That > is, it seems like you could have keys that are predictable to the monitoring > device, but still vary over time, something like setting the private key from > a KDF(SecretSharedWithMonitoringDevice, ServerRandom). Without having done > much analysis, this seems more conservative than making things entirely > static. Is there a reason to prefer the purely static approach besides > simplicity?
Please see Section 6 of the draft. The non-ephemeral DH keys MUST have a validity period. The keys are expected to change over time. > 2. You could avoid changing how the DH works altogether by simply exporting > the DH private key, encrypted with a key shared with the monitoring device, > in a server extension. (Not in EncryptedExtensions, obviously.) This would > also have the benefit of explicitly signaling when such monitoring is in use. > The only real challenge here is that the client would have to offer the > extension in order for the server to be able to send it, which I expect > things like browsers would be unlikely to do. However, given that the target > of this draft seems to be intra-data-center TLS, perhaps this is a workable > requirement? In most common deployment case, the load balancer at the edge of the enterprise datacenter will terminate the TLS session and start a new one. The TLS session that protects the traffic on the public Internet works exactly as described in draft-ietf-tls-tls13. The non-ephemeral DH keys are associated only with sessions that are inside the enterprise datacenter. So, you are right, no browser will be at either end of any of these TLS sessions. There is no change to the way that the protocol makes use of the DH key. The drft-green, the server need to look in a table to choose a valid non-ephemeral DH key. In your proposal, the server need to wrap the ephemeral DH private key in a key-enceyption key. Both solutions require the distribution of some key (either the non-ephemenral DH key or the key-encryption key) to the parties that are authorized to see the traffic. Stephen: > I don't believe the WG should adopt this as it goes > against rfc2804 and encourages bad behaviour. We > ought not be helping to normalise broken crypto. I'm > happy to repeat that at the mic in Prague but would > be even happier if this draft were not discussed > there - these attempts to weaken security have IMO > already taken up too much time and too many cycles. Repeating from above, the non-ephemeral DH keys are associated only with sessions that are inside the enterprise datacenter. In some industries, there are regulatory requirements that cannot be met without access to the plaintext. Without some authorized access mechanism, the enterprise will be forced to use plaintext within the datacenter. That seems like a worse alternative to me. Russ > On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green <matthewdgr...@gmail.com > <mailto: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 > <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
