One issue that pinning raises is that it is in a sense orthogonal to strict
security.
Obviously a strict security site is very likely to want to pin. But there
may also be cases where pinning is wanted without strictness. For example:
Promiscuous security:
The site deploys SSL as an option that browsers can choose to use. Pages
may include transcluded content from insecure sites. The cert may just be a
self signed cert, browsers should just silently upgrade the transport to TLS
and not bother the user.
Traditional security:
The site is advertised as HTTPS, there is a cert validated in some
fashion (DV, DNSSEC) but there may be links to transcluded content from non
SSL sources.
The reason I think these will be essential with pinning is that very few
sites will be able to go from insecure to strict security in one bound while
managing SSL certs centrally is something that many sites always do.
Thus I think that either pinning should have a new header (they are cheap,
IANA does not bite) or if we don't yet have a legacy issue on the strict
header it should be reworked as security properties and strictness should be
one of the dimensions.
Promiscuous security is really useful. In fact I suspect that most of the
use cases that drove the creation of DV could be met by strict security and
transparent browser upgrade to SSL.
I would also like to see a scope and protocol parameter reserved. This would
define the domain to which the assertion applied and be ignored in HTTP
transactions. Adding in scope means that the format can be used as a
mechanism for pushing out security policy as an emergency measure. It could
also be used to configure host or browser specific security policy
configuration.
So for example, let us walk back the cat on the Diginotar incident but
assume that some of the sites affected by the attack are publishing security
policy records with pinning and we have some browser side capability.
The response team takes the list of affected sites and pings each one for an
HTTP transaction and looks for a security header with pinning, if there is
one they add in a scope (and protocol parameter if necessary) and add it to
their list. At the end they sign the list with a PKCS#7/CMS wrapper and push
it out. So browsers see something like:
Strict-Transport-Security: scope=*.cia.gov; protocol=_http._tcp;
max-age=... pin=..... unpin=.....
Strict-Transport-Security: scope=*.paypal.com; protocol=_http._tcp;
max-age=... pin=..... unpin=....
Strict-Transport-Security: scope=login.twitter.com protocol=_http._tcp;
max-age=... pin=..... unpin=....
Such a file with 500 odd entries would essentially cover 98% of the sites
likely to be of interest in the attacks on Iranian citizens and likely most
other state level attacks.
This type of mechanism would provide for secure on first contact. It can be
communicated even when the Internet connection is severely compromised.
Iranian ISPs are not going to be allowed to pass DNSSEC records once there
is any infrastructure in place that would allow them to be applied to
prevent the attacks by the Iranian government. In fact last week China and
Russia proposed a set of 'best practices' to the UN that to me at least
appear to lay the ground for justifying that type of move.
So we can also put the same information into a DNS record and it could be
useful in some circumstances, but defeating a nation state level attacker
requires looking more than one move ahead.
Agreeing on a common format allows for agility in the distribution mechanism
to get round that type of block. If the only file that can be used by Chrome
is a Chrome specific file it is going to be much harder to transport the
files than if we can have one file that also supports Tor, Firefox, IE etc.
This type of file can be communicated by USB thumbdrive if necessary (which
is already one of the principal means of communication for important data in
such areas). It can be pushed out by anti-virus products, etc.
Using CMS as the package format means that there can be multiple signatures.
That helps solve the administrative problem of getting Microsoft or Google
to trust a package signed by another party. Relying parties can even take a
quorum of signers if they choose. That helps to solve an administrative
problem on the back end which is how to make sure that we protect all the
browsers that people might use without expanding the circle of responders to
include the attackers.
Note that with this approach the response team can respond without having to
contact the sites targeted in the attack. This is critical because there may
not be time to do so. We want to be able to respond in hours, not days.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
