Re: Proposal: Marking HTTP As Non-Secure

>Surely you haven't missed the big danger in plain text traffic. That
>traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
>Access Operations (TAO). In layman's terms, adversaries are using the
>information gathered to gain unauthorized access to systems.

With DV (weak validation) it then goes encrypted to them, I donıt see the
advantage. The magic bullet TOR to prevent from being monitored also
showed up, that the expected privacy may be broken. Itıs a good idea but
therefor stepping back from the value of PKIX is the wrong way in my
opinion.

>The race to the bottom among CAs is to blame for the quality of
>verification by the CAs.

Right, so DV need to be deprecated or set to a recognizable lower level,
clearly stating that itıs only encryption, nothing else.

>With companies like StartCom, Cacert and Mozilla offering free
>certificates, there is no barrier to entry.

And no barrier breaking the value of certificate authorities vs.
self-signed certificates (Cacert is the only good exception, for a good
reason their approach is different).

>Plus, I don't think a certificate needs to say anything about the
>operator. They need to ensure the server is authenticated. That is, the
>public key bound to the DNS name is authentic.

If a certificate doesnıt tell, what should tell? How should I be sure to
be on www.onlinebanking.de and not www.onlínebanking.de (see the accent)
by getting spoofed or phished? Itıs the same for Facebook.com or
Facebo0k.com, ...

>As I understand it, phishers try to avoid TLS because they count on the
>plain text channel to avoid all the browser warnings. Peter Gutmann
>discusses this in his Engineering Security book
>(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

If there is a free certificate for everyone and everything is https, which
browser warnings should occur?

>Why green for EV (or why yellow for DV or DANE)? EV does not add any
>technical controls. From a security standpoint, DV and EV are equivalent.

Thatıs what certificates are for. If we only would want to have
encryption, there would never be any requirement for certificates.
Browsers and servers handle cipher suites, handshakes etc., the
certificate is the digital equivalent to an authorized identity card, and
there for sure DV and EV are different. Security is about confidentiality,
integrity and availability. Confidentiality is the encryption, integrity
is the validation.

>If DNS is authentic, then DANE provides stronger assurances than DV or EV
>since the domain operator published the information and the veracity does
>not rely on others like CAs (modulo DBOUND).

>From the pure technical standpoint, yes, from the validation standpoint,
no. DANE has the hazel of compatibility, but it also struggle with harder
mandatory realization of restrictions (online or offline key material, key
sizes, algorithm, debian bug or heart bleed reissue, Š, all the topics,
which recently arised), for pinning validated (EV) certificates, itıs the
best solution vs. pinning or transparency.

>Not relying on a CA is a good thing since its usually advantageous to
>minimize trust (for some definition of "trust"). Plus, CAs donıt really
>warrant anything, so its not clear what exactly they are providing to
>relying parties (they are providing a a signature for money to the
>applicant).

As there is not internet governance, they are the only available
alternative. Similar to other agencies existing worldwide, they fetch
money for validation services and warrant for mis-validation. They are
dictated strict rules on how to do and be audited to proof, they follow
this rules. Thatıs how auditing currently works in many places and
although itıs not the optimal system, itıs the one currently available.

>Open question: do you think the browsers will support a model other than
>the CA Zoo for rooting trust?

If a reliable, usable and manageable concept will be established, for
sure. But as e.g. ISO 27001 establish the same model, there is a company
being paid for stating what they audited is correct and issuing a seal
(being ISO 27001 certified) which end users should trust in.

Received on Tuesday, 16 December 2014 01:12:18 UTC