Re: [Spud] SPUD Scope?

[Daniel Kahn Gillmor <[e-mail]>]

On Sat 2015-06-06 13:44:33 -0400, Ken Calvert wrote:
> Some middleboxes are paranoid for good (or at least understandable)
> reason: they are there to implement trust domain boundaries.  Because
> those boundaries don't exist in the original architecture, firewalls
> work by overloading mechanisms that are poorly suited for the job.

Maybe.  This sounds a lot like someone is still thinking in terms of
"perimeter defense", but on most modern, public networks, perimeters are
*extremely* porous.  And of course, once a threat is inside the
perimeter, such a defense is useless.

> A well-designed mechanism that enables a packet to certify
> policy-compliance in-band, without DPI, would at least help with
> firewalls.

Maybe we just need to start using "the evil bit" as specified:

  https://tools.ietf.org/html/rfc3514

;)

Apologies for the snark, but that RFC illuminates the difficulties with
providing such an indication in a way that satisfies the security goals
you're targeting.  Would this be done to implement "trust domain
boundaries" securely?

> Yes, the path is fraught with challenges; I don't disagree with most
> of your points.  On the other hand, call me an optimist, but I believe
> such a mechanism could not only help break the "ossification" logjam,
> but perhaps eventually shift the balance of power back toward the end
> users by giving them more choices w.r.t. network services.

how would this mechanism give the users more choice w.r.t. network
services?  It looks lke a way to facilitate additional metadata leakage
*to* network providers.  are you suggesting that some network providers
would require more metadata than others, and users collectively ("the
marketplace") could collectively select network providers on the basis
of their metadata collection policies?

If this is the suggestion, i think it vastly overestimates the average
user's (a) knowledge of the underlying mechanism, (b) ability to assess
their own risk from particular metadata leakage to a given provider, and
(c) time available to deal with the choicepoints presented (by each
network connection?) by this scenario.

        --dkg