Re: Mandatory encryption

Roberto Peon <grmocg@...> writes:

> As a reminder, I submitted an ID w.r.t. TLS proxies and MITM.
> The key idea in it, ignoring the technical stuff, is that either party
(client, server) has or should have some decisions to make about what
the proxies are allowed to do, and thus their own behavior when dealing
with them.
>
> The proxy always had the power to restrict and control things which flow
through it. Always will.

Thank you for this document. I freely admit I probably need to read it
again a few times, but it's a good first step.

Some remarks:

A. the parts where you wish content would not be accepted if modified and
would not be modified will be optimized away by implementers. Either the
user-agent cares about modifications (and it will ask a manifest of those
elements signed by a key it already trusts, and it will check this
manifest) or it doesn't and no amount of spec will change that

B. If the user agent has no means of verifying the data is unmodified…
→ being anal there only wastes network resources, adds latency and annoys
the user on a non-roaming connexion. If external access is closed it's
closed an no amount of continuous user agent hammering is going to change
that

C. I don't think URI syntax of html syntax changes is reasonable to
expect. If you want the content-provider to hint something should only be
fetched in archi-secure mode you need to place the hint in the transport
layer (like hsts today)

D. therefore, the way to go is transport-level signed manifests (or
manifests of signatures). This is actually useful even without
intermediaries – that permits mirroring of elements signed by someone else
(the content provider with which you've established a tls tunnel is not
necessarily the entity you trust to sign the content)

E. I think you started from separate caching and trusted proxies and
realised mid-document they were just complementary modes
Indeed a real-life scenario would look more like this:

* user-agent is configured with a list of explicit proxies

* the first time it needs to retrieve or post something, or on network
changes it checks if they are available, and establishes a secure
connection with them (checking not just some proxy exists at some ip, bu
that it has a trusted cert)

* if no previous connexion history with this proxy is cached, the user
agent asks what is the proxy operator policy (stupid to try blindly
lots-of-operations without knowing beforehand how they are likely to be
treated, especially if several known proxies are available)

  'what can I get for *'
  → answer: trusted mode only, caching mode only, caching and trusted,
forbidden, restricted (need to provide auth to the proxy to get access),
direct (should try accessing the target directly), otherproxy (can not
handle this request, ask someone else)
mixed (request too broad, different rules apply to urls that match this
filter)
   + expiration time (when the policy is likely to change next for this
request)

* if necessary (the typical answer for * will be mixed) it repeats with
more specific request (specific domain, url set, etc).

* like with hsts it caches the answers so it does not need to query policy
all the time

(did you say out-of-band pac-file? die die die)

* once the user agent knows how a particular request can proceed on the
available proxies, it provides an auth token over the secure channel (if
needed), a key (if something is only available in trusted mode, and the
user is ok to use trusted mode for this resource), and proceeds

* even if an url is available in trusted mode the client should not switch
systematically away from caching mode unless necessary (content provider
hint, user preference) doing away with caching and malware scanning has
its own problems

* at any point the proxy can reply to a specific operation with a mode
change request (that the browser can accept or not), due to unscheduled
policy changes, or just policy rules that apply to specific url patterns
or mime types

F. user agent needs to accept proxy messages such as 'not found', 'auth
renewal needed'

G. protocol needs to enable the user agent to request signature manifest
or manifest of signatures of some objects (even without any intermediary)

H '[we] must worry about endpoint per-connection stream limits' indeed. A
big proxy setup will max out typical stream limits

I Good users agents should remember user wishes and in particular what
they absolutely do not want to go through trusted mode

And that's all for today

Best regards,

-- 
Nicolas Mailhot

Received on Wednesday, 18 July 2012 21:50:32 UTC