[therightkey] Starting on some drafts

[Phillip Hallam-Baker <[e-mail]>]

I am starting to work on a suite of drafts to set out the architecture
I described earlier in the pdf document. The starting point I am
working from is the security policy draft Rob and I wrote earlier:

http://tools.ietf.org/html/draft-hallambaker-securitypolicy-01

The idea of this draft was that it would serve the needs of static
security policy distribution which is one of the modes of policy
distribution we are going to need. I see a need for the following
documents:


1) Security Policy Specification
    * Abstract security policy statements
    * Format for representing static security policy statements by trust brokers
    * Format for originating security policy as DNS headers
    * Format for originating security policy as application (i.e. HTTP) headers

2) Online broker protocol
    * Abstract protocol
    * Web Service REST binding
    * UDP REST binding
    * DNS binding

3) Architecture document


In a bit more detail:

1) Security Policy Specification

Having looked at this problem a lot I think we need to support more
than one way to exchange security policy statements. In particular
there is definitely a need to be able to originate security policy as
application headers (e.g. WebSec pinning) and the DNS is clearly the
proper infrastructure to originate authoritative statements about
domain names.

But merely originating security policy is not enough. First it is
unlikely that there will be a great deal of security policy available
to start with. Second, relying on administrator originated assertions
is likely to give too many false positives to hardfail.

So the scenario I think will prevail at the start is something like

5% or so of SSL web sites publish security policies through the DNS
20% or so publish security policies as application headers
90% or so of Web sites are stable enough for a low confidence security
policy to be inferred by observation and heuristics

One of the things we have learned from experience is that detecting
and reporting security policy violations has greater benefit to the
community of users than merely protecting individual users. So things
like Convergence and CT and such add to what is provided by the EFF
observatory alone, but the core value comes from detecting and
reporting.

The good news is that we can get detecting and reporting for 90% of
the Web through the trust broker model without any adoption by Web
sites. This is critical as far as deployment goes as it breaks the
deployment deadlock cycle. There is an incentive for clients to deploy
on day 1. As the number of deployed clients increases, there is an
incentive for Web sites to originate policy assertions and guide the
process.

I see two modes for broker interactions. The first is a static hotlist
of 'critical' security policies that the trust broker pushes out to
the client. This would be used for ensuring policy enforcement in
cases of actual attack. Some sites are attacked so frequently as to
make the permanent hotlist.

The second mode is an online protocol performed on a per IP connection
basis and has rather different performance constraints and so needs to
be considered separately.


2) Online broker protocol

At present a HTTPS client typically performs the following interactions:

1) DNS lookup to resolve 'www.example.com'
2) Connect to port 443 on www.example.com
3) Start TLS session, acquire cert
4) DNS lookup to resolve ocsp.ca.com
5) OCSP request to ocsp.ca.com
6) WTF starts TLS session
7) OCSP response is received (too late)

Adding in a call to a trust broker on top is a non starter. So any
trust broker interaction has to replace either or both of the DNS and
OSCP interactions.

I suggest both. So the abstract protocol becomes

1) UDP request to trustbroker.com ? DNS-name + Port + Protocol  *(+ options)
    UDP response : IPaddress + Port + SecurityOptions *(+ options) *(+ proof)
2) Client connects to specified IPaddress, port, etc.

The proof might consist of:

DNS RRs
DNSSEC RRs
Notary statements
Certificates
SAML assertions
etc.

How much proof a client requires would depend on the application and
the user. Needs will differ.

As a practical matter, there would be a need to use the protocol when
the only ports available are 80, 443 and port 53 to the DNS resolver
chosen by the ISP. So there would be a need to layer the protocol onto
DNS. This would probably mean some sort of BASE32/64 encoding hack and
TXT records.

Trying to pass proof over that type of connection is probably a
non-starter and so there would have to be a http/REST service as well.


-- 
Website: http://hallambaker.com/