On 2/12/13 2:25 AM, Trevor Perrin wrote:
The proposal there is for pins that chain to a well-known CA can be overridden, but pins that chain to local CAs cannot. This means that public sites, such as banks, social media and corporate portals (one type of "SSL VPN") cannot opt out of this local policy override.On Sun, Dec 1, 2013 at 9:49 AM, Yoav Nir <[email protected]> wrote:On 29/11/13 10:24 PM, Trevor Perrin wrote:On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir <[email protected]> wrote:To summarize, although there has been much discussion since version -06, most of it did not result in massive changes to the document, so IMO we don't need another WGLC.* Weren't we going to discuss the relationship of preloaded to dynamic pins? See email [1]. * The rationale in thread [2] for "strict" seems different from the rationale in previous list discussions [3]. Ryan now argues that "strict" is not needed. I think that's worth considering. * I had feedback on an earlier draft which is still relevant [4], see below. [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html[hat off] Well, [2] is just an idea I had two weeks ago, which Tom Ritter shot down and easily convinced me. The "strict" directive has come up in discussion at httpbis as well. There's all kinds of talk about adding a "trusted proxy" (a proxy that can see the plaintext). These are used today by performing a MitM attack on the client (with the grudging cooperation of the user or the administrator of her computer. The server does not have any way to ask the browser to not cooperate with the MitM. A "strict" PKP is one great way to convey that policyThe browser has already decided to cooperate with the MITM. I side with Chris and Ryan: it's pointless for the site to try to win a policy arms race here. The question remains whether "strict" is necessary for the "pinning to local trust anchor" case. Ryan argues that it's not, and describes a way for the browser to handle this without "strict": http://www.ietf.org/mail-archive/web/websec/current/msg01947.html That proposal makes sense to me, and avoids the complexity of an additional directive. So I support removing "strict", and adding text for this "pinning to local trust anchor" case.
With vendor hat on, we have been asked by customers whether we could prevent traffic to SSL VPNs (which we provide) from being decrypted. Currently, the only options we can give them are to deploy client certificates or to use IPsec VPNs. The above proposal adds one other way - to deploy a corporate CA. All three defeat the purpose of SSL VPNs that is that they can be used from pretty much any device. A "strict" directive and enforcing browser version (yes, I know it can be spoofed - none of this is secure against a malicious client) can get us close enough.
Yoav
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
