[Cryptography] Encryption opinion

[ianG]

2 for 1.

On 27/08/2014 04:06 am, Watson Ladd wrote:
> On Tue, Aug 26, 2014 at 6:38 PM, Paul Ferguson <fergdawgster at mykolab.com> wrote:
> On 8/26/2014 6:29 PM, ianG wrote:
> 
>>>> On 26/08/2014 23:29 pm, Paul Ferguson wrote:
>>>>>> On 8/26/2014 3:15 PM, Bear wrote:
>>>>>>
>>>>>>>> HTTPS is NOT an effective protection against MITM.
>>>>>>>> Furthermore, MITM is easier, not harder, to address than
>>>>>>>> phishing, and even if HTTPS were effective protection
>>>>>>>> against MITM it still would not be an effective protection
>>>>>>>> against phishing.
>>>>>>
>>>>>> The real "in the middle" threat these days is
>>>>>> credential-stealing Man-in-the-Browser (MitB) malware, such as
>>>>>> most modern day banking Trojans (ZeuS, et al).
>>>>>>
>>>>>> This is truly "in the middle" insofar as the attacker is
>>>>>> actively and surreptitiously part of the end-to-end session.
>>>>
>>>> It's curious that you say that.  In MITM there are the two end
>>>> nodes and a node in the middle.  When MITB takes over Alice's node,
>>>> he isn't in the middle anymore, he's Alice's node.
> 
> 
> Okay, so you got me on a technicality. :-)


Right -- but framing it as inside or outside doesn't change the
importance, only the marketability.  Sick world, huh?


> So I figured I would bring that up, especially since I see the IETF
> security area completely disconnected from reality with regards to
> security operations.

<cough :>

>> <snip>
> 
> Sure, encryption is a good thing, when designed & implemented
> correctly, but if the end systems are compromised (Welcome to my
> world!) then you are simply provide a secure transit mechanism for
> criminals to conduct their... crimes, given that they have control of
> the end system with "great security".
> 
> It's a Tao thing. :-)
> 
>> And what exactly can the IETF do about it?


That is a question!

I spent many years over at Mozilla, trying to get them to do something,
anything about phishing.  They refused.

Once, just once, patient long-winded argument got the engineers there to
say "Oh, you have a point.  Right.  Phishing.  Our users.  Shit."

To which they added:  "Now you have to go to IETF and PKIX committee and
get them to tell us what to do."

Boom.  The long and the short of it was that the browser vendors had
outsourced their security architecture to the standards groups.  (Why
they did this is a fascinating study in and of itself.)  So, now that
they had no architecture components for security they are entirely
dependent on the IETF and/or other folks ... *to tell them what to do*.

Yet, the IETF are unified in their consensus that phishing is not their
problem.  Perhaps, a cute social engineering thing that happens to other
people, but decidedly not their purview because it ain't no MITM, dammit.

Both groups aren't wrong, to themselves.  Both groups are right in some
light, by some assumptions akin to SEPs, "someone else's problems."

But neither group are serving the public interest;  they are locked in a
deadly embrace of insecurity, serving a long out-of-date security model.


>> Mandate that people not use
>> C unless absolutely necessary for system utilities?  Force people to
>> use capabilities so downloading a screensaver of dancing ponies
>> doesn't automatically mean handing over everything you do to an
>> attacker? Implement echo servers correctly?


It would help if the IETF loudly said something like:

    "Use of the HTTPS product will solve these problems:
    in-protocol MITM, confidentiality leakage, reliability...

    It will not solve phishing or ex-protocol MITM, however
    we agree to term it.

    *Vendors must solve these problems in the application*
    else be eternally damned by their users."

But they don't.  And won't.  IETF group members believes that phishing
is not MITM, and it is outside their bailiwick.  They really don't care
that much, they only care about the model-properties from 1990s.

Want proof?  Go check out the new work to put opportunistic security
into TCP.  Half of the people there cannot grok the need for the
encryption before the authentication, and keep coming up with "what
ifs..." as if things like SSH, Skype don't exist.  It's like they are
not actually on the Internet, but rather in some sort of CS protocol
course bubble that teaches CIA and the MITM as the only danger they have
to destroy above all things.



See now why I describe MITM as include phishing?


>> The solutions to these problems emerged in the 1950-1960's, and as
>> late as the 1980's the Orange Book made the sort of system that CapOS,
>> Coyote, and Ethos attempted to make the gold standard. No one did it
>> for a variety of reasons, but you certainly could with enough work,
>> make a single-user system with the property that all access to
>> documents is authorized by a UI action, or use Keychain/factotum style
>> auth for all SSH private keys.


Tru, dat.  The nearest we got to a widely distributed secure platform
was a macbook.  Controversy starts...

>> The reasons for non-adoption of these solutions are complex, and the
>> IETF deserves a lot of blame for failing to understand the Chomsky
>> Hierarchy and the consequences for validation, particularly when
>> different implementations need to produce the same results on all
>> inputs for security.


I don't claim to understand the above point, but it's redolent of a few
rants that have been ruled 'in the rough' ;-)


>> Security is a subset of correctness: I don't care that viewing a cat
>> picture can cause grey and multicolored splotches on my screen within
>> the area the picture says it occupies, but I do care that it can lead
>> to my tax returns being exfiltrated to Somalia, or all my contacts
>> being rounded up by the Secret Police. Somehow, in 60 years of
>> software engineering practice, we have not yet learned the nature of
>> the problem: ensuring a system of rules has a property.


Yup.  It's good to tell people we're teaching them security, but
actually teach them correctness or reliability.



iang