[Secdispatch] about draft-campling-ech-deployment-considerations (Re: Request for a slot at the Secdispatch IETF 113 Session)

[Michael Richardson <[e-mail]>]

{I wish the subject had been changed}

I found Mark's explanation very very well worded, and so I clipped parts of
it out (and top-quoted) below.  I think that

The Enterprise problem with TLS1.3 falls into this situation.
They have, up to now, imposed terminating TLS proxies on their employees,
without clearly informing them.  The problem that they have is the rise of
BYOD (and work from home, using my equipment, not theirs), and again the
problem is imposition of an unauthenticated intermediary without permission.

The argument against asking permission is that it is confusing for users.

While that is partly a UI issue, it's also because many things are occuring
which are not explicit.  The whole HTTP-Authentication vs
HTML-form-POST-authentication debate that we've come back to many times is an
example of that.  We haven't improved authentication in HTTP in a useful way,
so we continue to have authentication occuring at the wrong layer.

Mark Nottingham <[e-mail]> wrote:
    > The underlying problem is that such "transparent proxy" services are
    > unauthenticated -- they rely on the user understanding that the network
    > is going to perform these services, and accepting their
    > imposition. They're also disproportionate, giving complete access to
    > all data flows and capabilities on the connection.

...

    > Performing these tasks in this fashion allows not only legitimate
    > authorities to impose them, but also illegitimate attackers. As such,
    > they're inappropriate for deployment on the Internet, and that's why
    > we're seeing efforts like ECH -- use of this data and the associated
    > control channel without explicit user authorisation is not
    > "permissionless innovation" (as your draft states), it's an open door
    > to abuse. Put bluntly, you (as a network operator) don't have a right
    > to "innovate" with my data (as a user) -- especially without my
    > permission.

...

    > It also doesn't mean that the path forward will be easy. What's
    > required is a discussion and implementation of interfaces for
    > offloading these functions from operating systems, applications, and
    > IoT devices -- potentially to somewhere else on the network -- in a way
    > that maintains users' autonomy, privacy, and security, and in a
    > proportional way (i.e., only as much access to data as required to
    > fulfil the task). That is difficult not only because of the inherent
    > user interface subtleties and potential for abuse/hijacking, but also
    > because there is little current coordination or convergence at that
    > layer.

    > The IETF has a very clear responsibility to assure that the protocols
    > it ships are secure -- hence, ECH. It *could* have a role to play in
    > responsibly offloading these functions, especially where the work
    > intersects protocol design. There is also other work to be done that's
    > squarely outside our scope. I'd suggest that you and your co-authors
    > focus on assisting those positive, forward-looking efforts rather than
    > trying to stop ECH deployment.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-