Re: Draft finding - "Transitioning the Web to HTTPS"

If it's imperfect then you're suggesting that the Web Platform be built on
an imperfect foundation or that this foundation can is in fact be perfect
(or capable of being perfect with some modification) but is currently
broken (compromised) and in need of repair (hardening)?

The document is kind of passive in how it deals with the risk posed to the
Web Platform by the currently broken (compromised) security foundation. To
me the biggest risk to security is the risk that is talked about all over
the newspapers (um, online news I mean) and that is so incredibly real and
is an actualized threat to free speech on the web. Why doesn't the document
mention state actors as the currently known threat to security on the web?
I know it's a technical proposal but naming the known threat to the very
foundation of web security in a document that is promoting that foundation
would not be an unusual act. Some may think you're avoiding it on purpose,
and that technologies shouldn't mess with politics, but while I tend to
think that way too the fact is that it's a theme that is now part of our
everyday conversation. It has become a popular topic. I don't think the
TAG/W3C should risk looking so aloof and detached from the real issue that
it's efforts are trying to address. Staying purely technical and not naming
parties is fair, but not acknowledging the risk in a general and clear
statement, e.g. "It is believed that certain state actors have compromised
TLS", leave TAG/W3C open to accusations of being evasive about the subject,
which is unfair to the TAG/W3C because it's evident that all good thinkers
come to the same conclusion: the web MUST be secure for it to thrive as
platform. Period, no buts, no ifs.

Btw, on a related subject, stuff like "signed scripts" which were proposed
on this list by an independent developer (with the conclusion being that
signing a script at least assures that it's not be altered) might be part
of a more perfect foundation. The argument I heard here against Web Crypto
over HTTP (or more comprehensively stuff like OpenPGP.js which used by
Google for its End-to-End security plugin) for client-to-server secure
exchange is that MITM can alter the script, but a signed script would solve
that, so regardless of whether you use a CA or not you should be able to
get pretty good privacy, right? (assuming signed scripts or signed
Chrome/Firefox hosted apps)

Does any of this make any sense? It is being addressed to the TAG/W3C. As a
concerned user of the web (who had lived under state terror and state
surveillance in other parts of the world that don't even approximate to our
privileged state of existence here)  I would appreciate any comments about
this. I think Sean is correct in demanding that current affairs not be
passively omitted from documents that will surely serve as historical
reference to future generations.

Sincerely,

Marc

On Tue, Dec 16, 2014 at 9:57 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> Sean,
>
> > On 14 Dec 2014, at 9:21 am, Sean B. Palmer <sean@miscoranda.com> wrote:
> >
> > The specifics of encryption were only the second part of my email; I
> > appreciate your information there. But again, the policy must note
> > that TLS/SSL is known to be partially compromised.
>
> You keep on saying "must." I'm happy to discuss this with you, but please
> don't presume to demand a particular outcome.
>
> That aside -- the document already says:
>
> """These important properties of authentication, integrity and
> confidentiality are best — if imperfectly — provided on the Web by
> Transport Layer Security (TLS)"""
>
> note "imperfectly." Furthermore,
>
> """We recognize that HTTPS will not solve all — or even many — security
> problems in the Web platform."""
>
> So, we already acknowledge that TLS is less than perfect. I've tried to
> make this more clear in:
>
> https://github.com/w3ctag/web-https/commit/45e5a8916dd23d4705c60c1ea0107b8b0bdff6b4
>
> Doing much more than that essentially turns the document into a history of
> the security flaws in TLS, and that seems wildly inappropriate in this
> document.
>
> Cheers,
>
>
> > It is not "detail" to mention that TLS/SSL is partially compromised
> > when you are advocating widespread use of HTTPS. Widespread use of
> > HTTPS will incur the consequence that many who switch will still be
> > vulnerable to Pervasive Monitoring, per RFC 7258.
> >
> > Policy ought to be realistic in presenting the situation, not mislead
> > regarding perceived security, and guard against complacency. Taking
> > action as I direct will help in each of these areas.
> >
> > On Sat, Dec 13, 2014 at 9:51 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >> Hi Sean,
> >>
> >> This finding is not the end statement on all things encryption; it’s a
> proposal for a high-level policy. The details of encryption are best left
> to specific Recommendations and RFCs; for example, TLS1.3 is removing RC4
> (and HTTP/2 disallows it), and the CFRG is debating the merits of different
> curves.
> >>
> >> Cheers,
> >>
> >>
> >>> On 13 Dec 2014, at 11:06 pm, Sean B. Palmer <sean@miscoranda.com>
> wrote:
> >>>
> >>> Hi Mark,
> >>>
> >>> If you are promoting HTTPS for security, you must also record that
> >>> TLS/SSL were partially compromised as of 2013:
> >>>
> >>> "C.3. (TS//SI//REL) The fact that NSA/CSS has some capabilities
> >>> against the encryption in TLS/SSL, HTTPS, SSH, VPNs, VoIP, WEBMAIL,
> >>> and other network communication technologies"
> >>>
> >>>
> http://www.theguardian.com/world/interactive/2013/sep/05/nsa-project-bullrun-classification-guide
> >>>
> >>> "Several experts, including Bruce Schneier and Christopher Soghoian,
> >>> have speculated that a successful attack against RC4, a 1987
> >>> encryption algorithm still used in at least 50 per cent of all SSL/TLS
> >>> traffic, is a plausible avenue, given several publicly known
> >>> weaknesses of RC4. Others have speculated that NSA has gained ability
> >>> to crack 1024-bit RSA and Diffie Hellman public keys."
> >>>
> >>>
> https://en.wikipedia.org/w/index.php?title=Bullrun_%28decryption_program%29&oldid=631232698#Methods
> >>>
> >>> When certificates are upgraded to ECC, these compromises may be fixed,
> >>> though we are unlikely to know for sure. But there is a good chance
> >>> that the NSA-influenced NIST curves would be used instead of Prof
> >>> Bernstein's Curve25519 and associated apparatus. The IETF must not
> >>> allow this to happen.
> >>>
> >>> Update the draft finding to include this information.
> >>>
> >>> Regards,
> >>>
> >>> On Mon, Dec 8, 2014 at 11:28 PM, Mark Nottingham <mnot@mnot.net>
> wrote:
> >>>> We've started work on a new Finding, to a) serve as a Web version of
> the IAB statement, and b) support the work on Secure Origins in WebAppSec.
> >>>>
> >>>> See: <https://w3ctag.github.io/web-https/>
> >>>>
> >>>> Repo w/ issues list at <https://github.com/w3ctag/web-https>.
> >>>>
> >>>> Cheers,
> >>>>
> >>>>
> >>>> --
> >>>> Mark Nottingham   https://www.mnot.net/
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sean B. Palmer, http://inamidst.com/sbp/
> >>
> >> --
> >> Mark Nottingham   http://www.mnot.net/
> >>
> >>
> >>
> >
> >
> >
> > --
> > Sean B. Palmer, http://inamidst.com/sbp/
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>