W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: CfC: Mixed Content to PR; deadline July 6th.

From: Brian Smith <brian@briansmith.org>
Date: Mon, 6 Jul 2015 13:14:05 -0400
Message-ID: <CAFewVt5WzyeCzfDUD2LgxoKxg4TJtE-Nz2rS8dHacjXqOZqf6Q@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Kristijan Burnik <burnik@google.com>, Ryan Sleevi <sleevi@google.com>
Mike West <mkwst@google.com> wrote:

> Ok. Looking at the diff, I can totally live with dropping the concept from
> MIX. You happy with
> https://github.com/w3c/webappsec/commit/2fa9d6757123cd3e4d53a347ba8bc57437c5d292,
> Brian?

Hi Mike,

First, a specific point: Your change added the use of the term "deprecated
authentication" but I think that weaknesses in aspects other than
authentication are to be included too (e.g. use of RC4), so I don't think
"deprecated authentication" is a good term to use.

I'm guessing you are asking me because of my previous (months ago) request
to have it dropped from the spec. There were three reasons I requested it
to be dropped:

1. Nobody implemented it, so we don't really know if it can be implemented.
In fact, my understanding, from observing Google's work on SHA-1
deprecation, is that it is actually much harder to implement than was
originally thought.

2. The specification would be simpler without it. In particular, without
the deprecated TLS stuff, it could be made much clearer that the blocking
described in the document always happens before any data (HTTP request,
Websocket handshake, etc.) is sent on the wire. (Note that I think that CSP
should be defined to work like that too.)

3. "Deprecated TLS protection" wasn't specified well enough to .

I think the change you linked to above is moving in the direction of
solving all three of those issues. However, it also retains some of the
complexity associated the removed stuff because you didn't remove the
concept of "insecure origin" that is a superset of "a priori insecure
origin" and you didn't remove section 5.3, "Should response to request be
blocked as mixed content?" Note that both #1 and #2 above apply to those
things too, so they should also be removed.

To be clear, I support the abstract idea of blocking deprecated
TLS-protected subresources, and I do think that a specification for how
that should work should appear in a future version of some specification,
but not the current one.

Received on Monday, 6 July 2015 17:14:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC