some brief comments on mixedcontent

mkwst@google.com said on Tue, 17 Mar 2015 11:28:01 +0100:

> Great feedback, thank you.
>
> Would you mind reposting this to the list? I think it contains a number of
> editorial changes that we can make in CR, so I'd like to have a thread to
> point to when making those changes. :)
>
> -mike

ok, thanks, here you go...

=JeffH had said on Mon, 16 Mar 2015 18:10:58 -0700:


Hi Mike,

I understand from Brad that mixedcontent [*] has attained CR status -
congrats! (tho I don't see that announced on the list but perhaps I'm blind).

anyway, I'd mentioned I had comments on the spec, but my day job has taken
priority of late, unfortunately.  In any case, at this point I don't think
I'd have anything normative to add, as it seems y'all handled the relation
to RFC6797 appropriately.

thus my remaining comments would likely be only editorial, and at this point 
likely superfluous, at least from webappsec's perspective, hence I'll just 
send this very quick overview to you, to do with what you will (i don't want 
to slow things down, and if the spec is really CR, it looks like from the 
process doc [0] that further edits /could/ slow it down at least in terms of 
admin overhead). tho if you feel otherwise just tell me and I'll re-send 
this to the list.

my main comment is that the name "mixed content" is quite misleading to
someone who's new to web security (like myself back in 2009).  for example,
when the at-the-time IETF Apps Area Director (Peter St Andre) was reviewing
the HSTS internet-draft, he noted this in his review [1]..

###
SECTION 2.3.1.3

The term "mixed content" threw me off because it is also used in XML:

http://www.w3.org/TR/2008/REC-xml-20081126/#sec-mixed-content

Also, it might be good to consistently use and prefer the term "mixed
security context" in this specification.
###

I note that in the webappsec list discussions of the mixedcontent spec,
various folks at times did use the terms "security context" and "secure
document context", but unfortunately those terms aren't used in mixedcontext.

also RFC6797 includes this [2]..

###
     NOTE:  "Mixed content" as used above (see also Section 5.3 in
            [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed
            security context" in this specification and should not be
            confused with the same "mixed content" term used in the
            context of markup languages such as XML and HTML.
###

So anyway, I realize that given how embedded the term "mixed contect" is in
the web security world that it isn't going to be changed. however, I do
suggest trying to disambiguate and clarify it in a spec such as
mixedcontent.  e.g., I'd be tempted to add a subtitle of "mixed security
context", and/or a disclaimer similar to the note above from RFC6797 that
clarifies it as distinct from the notion in the markup language world.

Also, [WSC-UI] is a Recommendation, and it clearly defines 'mixed content'
[3] --- and mixedcontent [*] is clearly re-defining the term without
reference to [WSC-UI]. I don't know how the W3C deals with one spec
"updating" another (as is done in the IETF), but without resolution, it's a
loose end (from my perspective anyway).

in terms of the Note at the end of the Introduction in [*], you might want
to s/more a user agent/more user agents/.

FWIW, the earliest mentions of "Downloading non-secure content from a secure
web site.." wrt IE that I can find refer to IE 6, and perhaps IE 5 or 5.5
(yes, i poked around the internet archive too). I could not find any
references to IE 4.

also..hm..regarding the defn of mixed content in [*]..

    "A resource is said to be mixed content if the resource’s origin is
insecure, and the context responsible for loading it restricts mixed content."

..seems a bit awkward in that the resource isn't going to be loaded if the
loading context restricts such loads.

And the example..

    "The image http://example.com/image.png is mixed content when loaded by
https://not.example.com/."

..seems odd because it talks about "when loaded", but mixed content is
detected prior to loads in the case of a priori insecure (origin | url), or
in the act of establishing a TLS connection and discovering that the
resultant TLS-protection is deprecated.

so I'd be tempted to establish terms such as..

    a priori mixed content: insecure URLs present in an otherwise secure
document context, or discovered to be an insecure origins at tls connection
establishment time.

    mixed content: a priori mixed content that was loaded into a formerly
secure document context.

..and I'd also somehow define '(a priori) mixed content' to be equivalent to
'(a priori) mixed security context"


wrt "security considerations" I would add an item briefly discussing that
being careful/strict about 'mixed content' is only protecting against
attackers on the wire -- it does nothing to protect the requester if any of
the servers involved in serving the resource being fetched are themselves
surreptitiously compromised.  this is a point often neglected it seems.

HTH,

=JeffH

[*]  http://www.w3.org/TR/mixed-content/
      https://w3c.github.io/webappsec/specs/mixedcontent/

[0] http://www.w3.org/2014/Process-20140801

[1] https://www.ietf.org/mail-archive/web/websec/current/msg00476.html

[2] https://tools.ietf.org/html/rfc6797#section-2.3.1.3

[3] http://www.w3.org/TR/wsc-ui/#securepage
      http://www.w3.org/TR/wsc-ui/#def-mixed-content

Received on Tuesday, 17 March 2015 16:03:23 UTC