Achieving precision in the language used is what the process is all about :)
The reason I think it is useful to make a distinction is that the value came from identifying a security policy violation and pinning generally understood to encompass enforcement of a security policy. Getting a security policy mechanism to the point where it is enforceable is hard. Google has asked us not to implement the pinning code in Comodo Dragon even for google.com for operational reasons that look valid to me. We can use Perspectives or Convergence or similar to detect and report violations in cases where we do not have sufficiently good data to force connection failure. It is clearly desirable to have the client have the capability to fail a connection but too many false positives will result in people turning the systems off (unless they are in Iran). I think we will see security policy coming in different degrees of quality: 0) No information 1) Weak - e.g. data that has been collected from passive observations and heuristic means. 2) Good - the data comes from an authoritative source (e.g. HTTP headers, DNS records) 3) Strong - there is authenticated, curated data from an authoritative source backed up by data from a trusted source 4) Proof - the client has the benefit of a full cryptographic authentication of the security policy that is tied to immutable sources (e.g. Merkle tree based notary). At the moment I see a lot of proposals that attempt to find the sweet spot on this continuum. Well maybe that is the wrong approach for the protocol to take. Maybe a better approach is to have a protocol that supports transport of security policy data of any quality and allows the client to make an appropriate decision. This would also take into account the degree of concern the user had. Iranian dissidents and security specialists would probably want to be more aggressive than regular users. So a default approach would probably be for the client to merely report policy violations against weak policy to some external party, warn the user if there is a violation against good policy and block the connection on Strong policy or Proof. Getting to proof is good (yeah, I did the formal methods thing too). But it is also very difficult to achieve. On Fri, Jan 20, 2012 at 1:59 PM, Chris Palmer <[email protected]> wrote: > On Fri, Jan 20, 2012 at 8:14 AM, Phillip Hallam-Baker <[email protected]> > wrote: > > >> Without pinning, fraudulent certificates are invisible, especially when > >> applied to specific individuals. The fraudulent diginotar cerrtificates > in > >> Iran would have gone unnoticed had it not been for the pinning of Google > >> certificates. > > > > The Google certs were not pinned. Pinning is a very specific mechanism. > > We consider them to have been pinned. The dynamic pinning proposal in > the WebSec WG is a generalization of what we call "preloaded" (or > "static") pins. > > Word-noodling aside, the attack might very well have remained > invisible without Chrome's knowledge of and insistence on Gmail's true > SPKIs. > > > -- > They who can give up general-purpose computing to obtain a little > temporary safety, deserve neither general-purpose computing nor > safety. > -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
