On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley <hous...@vigilsec.com> wrote:
> 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. > OK, then why not have this happen automatically (e.g., by folding in ServerRandom) rather than doing the provisioning process over and over? > > 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. > Yes, I understand that all of the solutions in this space will require some static configuration. What I'm trying to do is minimize the degree to which that static-ness reduces the entropy in the TLS handshake. In the "fold in ServerRandom" version, the static information gets tempered with per-session random information. In the "smuggle out the private key" version, the static information doesn't even touch the base TLS handshake; it's only used for wrapping the DH private key. I agree that the "smuggle out the private key" still has a static component that you would want to refresh. However, it's minimal, in the sense that you're going to need to authenticate the monitoring box to the TLS server somehow anyway (even if just for provisioning). And it seems like a cleaner separation to have the static component as something off to the side of the main handshake, rather than having to make invasive changes to the handshake code. --Richard > > > 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> > 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
