W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: SSL/TLS everywhere fail

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Thu, 3 Dec 2015 19:26:56 -0700
Cc: Ted Hardie <ted.ietf@gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <5660F9F0.7070705@measurement-factory.com>
On 12/03/2015 05:38 PM, Ted Hardie wrote:

> On Thu, Dec 3, 2015 at 2:26 PM, Alex Rousskov wrote:
>     It could be this
>     WG job to design protocols and deployment recommendations that make
>     monitoring easy to integrate, discover, and either consent to or reject.


> ​The working group is constrained to work
> ​within the limits set out in general IETF policy.  In this case, that
> is RFC 2804.


A good solution for the problems discussed on this email thread would be
"consent to be monitored". RFC 2804 does not apply to connections where
the parties know about monitoring and consent to being monitored
(Section 3 "wiretapping definition" conditions #1 and either #2 or #3
are not met, depending on the direction of the message). If there is
consent, there is no wiretapping per RFC 2804.


> Look particularly at section 3.  As you will note from that, there are
> certainly middleboxes which are within scope (configured HTTP proxies
> among them).  But there are others which are not.  I know of no
> interception proxy requiring a newly installed root CA which would fit
> within the current policy, but I'm willing to be informed should there
> be one.

The prevalence of interception proxies is our other engineering failure,
but if I have deliberately installed your root CA on my phone and
clicked "I agree to be monitored by Ted" button in my favorite browser,
then you are no longer wiretapping my Google requests per RFC 2804.


> But the common case is clearly outside the scope of the
> engineering efforts appropriate to the IETF, according to our current
> policies.


Today, there are actually two different kinds of common cases:

1. Good old stealth wiretapping (NSA and such).

2. Monitoring with consent (numerous employers, arguably many parents,
and, evidently, Kazakhstan(**)).

I am only talking about #2 category, which does not violate RFC 2804
letter or spirit AFAICT.


Thank you,

Alex.
(**) One could argue that installing a Kazakh NSA Root certificate is
not a strong form of informed consent. I do not necessarily disagree.
However, AFAICT, Kazakhstan authorities would have picked a more
user-friendly consent/integration method if IETF provided them with one:
They are _not_ hiding their monitoring, apparently, so it is reasonable
to speculate that they would actually prefer an easy, user-friendly
consent model to the current necessity of installing root CAs using
obscure configuration dialogs.

If not, please remove that particular example from #2 cases.
Received on Friday, 4 December 2015 02:27:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC