On 07/17/2017 10:18 AM, Yoav Nir wrote: >> On 17 Jul 2017, at 17:06, Roland Dobbins <rdobb...@arbor.net> wrote: >> >> On 16 Jul 2017, at 11:19, Salz, Rich wrote: >> >>> The key point here is Within the enterprise. >> +1 > It’s an illusion that inside the enterprise uses different technologies than > outside the enterprise. IP was for outside, and yet it’s all over the inside. > > In the end, either this is in OpenSSL (perhaps plus a patch) or it’s not. > Either it’s in SChannel or it’s not. Either F5 have it or they don’t. > > If it’s not, it will be impossible to deploy in the enterprise network. > They’re not all going to implement it themselves. And if it is, then it’s on > the open Internet, and then at least some people will have it turned on. The > border between the enterprise and the non-enterprise is pretty blurry. >
Right, and that's the core motivation for a lot of the fierce resistance this draft is experiencing. Fundamentally, we are here talking about things at the Internet Engineering Task Force. We have an Internet threat model, partially manifested in things like RFC 7624 but largely just latent institutional knowledge, that includes a hostile network. We know that Internet protocols get used in Intranets as well, but that is not the main use case for our work, and only a small portion of the scenarios that we must consider when designing Internet protocols. On at least many Enterprise Intranets, the threat model is different from the one we generally use for designing Internet protocols, so there is an impedance mismatch between what features are desired or seen as problematic on the Intranet and the Internet. Because the risks/disadvantages of the current proposal, when applied to the Internet as a whole, are so large, there is a lot of pushback, and a desire to provide strong assurances that any proposal in this space does not leak from the Intranet onto the Internet, both at a protocol level and a implementation level. If there was a scheme that cryptographically required input from both TLS client and server in order to enable the needed "key exfiltration" (or equivalent) for the Intranet use case, that seems like it would resolve most of the concerns being raised. Unfortunately, it seems really hard to come up with something like that, when there are so many options that are unilateral for the server. This is not just a question of "we promise we'll only use it on the Intranet" because of the reasons Yoav states above -- even though I assume that everyone participating in this thread is acting in good faith, once the capability is in popular software packages, it could easily be enabled accidentally on the Internet, or coercively required of certain entities, e.g., by national security letter, once enablement is just a configuration setting (as opposed to writing code). So, in order to have something that is verifiably opt-in by both parties, it seems like it would have to be a ClientHello/ServerHello extension (included in the transcript for the generated traffic keys) where both sides commit that they are willing to exfiltrate keys to a given named entity(ies) (whether that's by raw public key, certificate name, etc., is quite flexible). Because of the key schedule (the traffic keys are produced after that point in the handshake), it seems like such a scheme would require encrypting DH private values to the third party (and potentially a PSK as well). I'm curious whether a non-handwavy writeup of such a scheme would get a better reception than draft-green-tls-static-dh-in-tls13 is getting. It does lose forward secrecy for the traffic in question, but such traffic is clearly marked, and rotating the third-party key sufficiently often could regain some forward secrecy properties. (Of course I'm also interested in hearing if that is not feasible for the Enterprise case since I don't understand those requirements very well.) But it seems that we're not really getting anywhere just arguing about the current proposal (and repeating ourselves a lot), and proposing concrete alternatives (that do not require rearchitecting the enterprise networks) might be a way to make progress. (It's still unclear whether such a scheme would be acceptable as a WG item or Standards-Track, of course.) -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls