On 20/11/13 10:23 PM, Ryan Sleevi wrote:
That was issue #53. It was closed, and there was no consensus to remove 'strict'. The only things missing from the draft is the closing of #57-#60.On Tue, November 19, 2013 3:36 pm, Yoav Nir wrote:Hm. Interesting predicament. Two thoughts:If the goal is to allow clients to note and obey the 'strict' directive even in the face of a SSL Interception proxy... what you propose won't work. The proxies will be built to just remove the strict directive, or the header all together. If the organization running the proxy wanted to block access to the site in question, they would do so. If they want to monitor ongoing access, they will strip the directive/header so the clients continue to connect. If they are ambivalent - 'access it or not, we don't care, but must monitor you if you do' - the stripping feature may or may not be enabled. What you propose would only help in the latter case, it will not actually provide more security if the website considers the proxy to be an adversary. And if they add the strict header, I would imagine that the website does consider them to be an adversary, or at least that they do not wish the connection to succeed..I agree that it does not help security, but it increases the chances of the server policy being enforced. This is not far-fetched. Most TLS proxies are next-generation firewalls or caching proxies. They won't remove the strict directive. Of course, snooping proxies will act differently.So I don't think what you propose is worthwhile, specifically because it does add risk via sites bricking themselves, while not improving security considerably. As far as the laptop moving between home and work... I get the impression this situation may be regarded as a 'failure' of the protocol. That is, we have unintentionally broke something. I disagree. I think the situation has worked as desired.It's the other way around. The desktop that remains at the office and keeps ignoring the strict pins is the failure.Because if we replace the players with a rogue government performing TLS MitM, with the specific goal of isolating clients from receiving up-to-date security policies... we would declare this same situation a success. I don't see a way to reconcile the two situations, as they behave almost exactly the same. TLS Proxies add a third player into what was previously a (primarily) two-party protocol*. I think the strict directive preserves the reasonable property that any one of the three parties can choose not to participate based on the settings of the protocol. - The TLS proxy can block access or choose not to intercept - The user can not visit the site - The site can declare "I don't want anyone else seeing the data I consider to be for the user's eyes only"So the benevolent TLS proxy should note the "strict" directive and block the connection by itself? It makes sense, but that would require an upgrade of the TLS proxies. Changing client behavior would work with the proxies that are deployed now.I expect that Firefox and Google may even continue to preload entries in their browsers that apply the 'strict' directive specifically to provide websites the power to assert their right to a MitM-free connection. I know several websites who would like to exercise that right.What? And have their sites not work in all the places that have newer firewalls? I doubt it. Anyway, I can see how this would allow a buggy proxy to brick the users, so I now agree that this is not worthwhile. Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websecApologies that this discussion has happened due to the editors not having refreshed the draft. As I recall (perhaps incorrectly), our takeaway from IETF 86 was the removal of the 'strict' directive, since the notion of having a remote server provide a directive to override local policy is just escalating a policy arms race.
I'm not sure of the value of pinning internal sites. But regardless, I think the text with the changes agreed upon for the few open issues reflects the consensus of the group or what's left of it (the group, not the consensus).One of the key discussions was had was regarding pinning and how, in current implementations (eg: Chrome), one can only pin to chains that terminate in a 'well-known root'. The 'strict' directive (or its absence) was an attempt to provide some indication that the site accepts being pinned to an internal trust anchor. I recall (and again, perhaps incorrectly), that it was either Eric Rescorla or Jeff Hodges that suggested an implementation change might better accomodate this: 1) If noting pins, and it chains to a well-known trust anchor, local policy (read: potentially MITM enterprise devices) may be able to override 2) If noting pins, and it does not chain to a well-known trust anchor, effectively note the pins with no override capability (eg: the pins exactly as specified) The goal of this was less about enabling MITM proxies (although they're an unfortunate reality and, to at least some, a perceived necessity), and instead finding a way to balance pinning for both "public" sites as well as "internal" sites.
I think it's time to push this out. Yoav
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
