Re: Trust and provacy problems with draft-loreto-httpbis-explicitly-auth-proxy

[Paul Wouters <[e-mail]>]

On Mon, 5 May 2014, Raphaël Durand wrote:

> I've just read the draft draft-loreto-httpbis-explicitly-auth-proxy, and I see a lot of trust and privacy problem in this
> "Explicit auth proxy".
> https://datatracker.ietf.org/doc/draft-loreto-httpbis-explicitly-auth-proxy/?include_text=1
> 
> The first problem is in the "opt-out" section (3.3).
> First, it has to be "opt-in" not "opt-out" (it's called an "explicit auth proxy isn't it ?")

It refers to the user having accepted to proxy for everything and than
explicitely excluding something. So I don't have a problem with that
specific toggle - I do, like you,  have a problem with the entire document.

> "To ensure the trustfulness of proxies, certification authorities validation procedure for issuing proxy certificates
> should be more rigorous than for issuing normal certificates and may also include technical details and processes relevant
> for the security assurance."
> 
> No, public CA must not sign these certificates. Proxies certificates must be signed by a local CA explicitly trusted by the
> user.

I fully agree.

> "6. Security Considerations
> "Those resources are protected end-to- end between user agent and origin server as usual."
> 
> No they are not, there is a third-party proxy between them. The user do not operate it, so he can't trust it.

Indeed, and it further interferes and breaks out-of-band key validation,
such as TLSA/DNSSEC. So a protocol modification is completely useless,
as the application needs to turn off so many security features, it might
as well take the certificate check/override into the application as
well.

I must say, it is becoming rather tiring to see new incantations of
protocol modifications to account for "legalised MITM attacks". How
many times do we have to repeat that is a problem to be solved at the
application and/or OS level and not at the protocol level?

We have enough problems keeping our protocols secure without adding
dangerous protocol-based legalised attack modes into our protocols.

I am strongly against in-band MITM protocol modifications as specified
by this draft, its precursor drafts, and the inevitable follow up drafts.

Take your legalised enterprise MITM ideas to the OS and browser vendors.

Paul