Re: [Pearg] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Jan 5, 2023 at 8:59 AM Eric Rescorla <[e-mail]> wrote:

> Hi John,
>
> Thanks for raising this topic. I would make a few points here.
>
> 1. I've heard the term "zero trust" used in a number of ways, ranging
> from "use a network architecture that doesn't involve firewalls" to
> "blockchain". So I'm not sure that talking about "today's zero trust
> principles" is going to get us very far.
>

+1

Zero Trust is a marketing term and has been rendered meaningless by
everyone calling their stuff 'zero trust' regardless of what it is. Since
every security system requires a degree of trust in something, the pretense
of zero trust is actively damaging as it leads to incorrect analysis.



> 2. I agree that there are very significant threats to people's
> security and privacy at the endpoints, from a number of sources,
> including (1) software that was installed for users without their
> consent (2) software that they intended to install and does not behave
> the way that they expect and (3) direct attack on the software on
> their machines.
>

Agree.


> 3. Essentially none of these threats are the province of the IETF,
> which defines networking protocols. We are not well positioned to
> either (1) improve the security of those endpoints or (2) address
> situations in which the software on the endpoint is directly attacking
> the user's privacy, e.g., by leaking their browsing behavior within an
> app.
>

There we disagree.

Endpoint security isn't my primary concern but a lot of what we do in IETF
affects endpoint security. The #1 way in which endpoint compromise occurs
is that a malicious payload is sent to an individual via SMTP. This
persists because it is not one problem, it is multiple problems and
everyone can point to other people for being at fault. Let me be clear
here, if your enterprise can collapse because some junior employee presses
the wrong button, that is the fault of the CEO and CISO, it is not the
fault of the employee. So what are the real causes?

1) SMTP lacks authentication of sender origin to the end user so anyone can
impersonate other company employees.
2) MIME allows attachments with active content.
3) Commonly used applications automatically run active content with no
authentication of origin.
4) Existing mechanisms to sign active content are utterly unfit for use in
a corporate environment.

The first two are very clearly within IETF scope and so is any solution to
the third.

Can the IETF come up with a complete solution on its own? Probably not, but
the IETF can be a part of a broader solution.

If the necessary players are not in the room, get them there. MIT and the
Kennedy School have no difficulty getting senior current and past leaders
in the intelligence and information security world to attend their
Chatham House rules cyber events. Preventing endpoint compromise is a major
concern to the NSA and cybercommand and EU equivalents.

It is certainly not a hopeless situation either. There is no iron law that
says that a corporation has to use the same email system for internal and
external mail. If a corporation deploys a separate email for internal
communications and SMTP is handled by a separate system which entirely
blocks active attachments, risk of endpoint compromise through
impersonation attacks is considerably reduced.

If the new internal email system is also built on an open standard and
supports open federation with other systems, it can eventually replace SMTP.


4. I agree that there are some modifications to those protocols (you
> raise PFS above, and also in some cases PCS, but perhaps even moreso,
> the use of replayable identifiers such as passwords and cookies) that
> would somewhat improve the resistance of those protocols to attack on
> the endpoints. In my experience, the IETF does take these forms
> of attack reasonably seriously.
>

The problem is that it has taken this long for the industry to bite the
bullet and recognize that we have to get rid of the passwords completely
when we have known they are broken and unfixable since 2000.

The route to ubiquitous use of FIDO/PassKey is to get everyone using a
ubiquitous, open, interoperable credential vault that supports passwords
and passkeys and is not tied to a single proprietary walled garden. And of
course, the industry keeps failing at that because the goal for the BigTech
players is to keep people inside their walled gardens.

Doing that right is another thing the IETF could be doing but isn't.



> 5. The oft-cited RFC 3552 language about assuming the endpoints
> doesn't reflect a lack of awareness that endpoints can be compromised;
> we were well aware of such attacks at the time we wrote 3552. Rather,
> it's about the separation of concerns and having the protocol
> pieces do what they are able to do:
>
>    The Internet environment has a fairly well understood threat model.
>    In general, we assume that the end-systems engaging in a protocol
>    exchange have not themselves been compromised.  Protecting against an
>    attack when one of the end-systems has been compromised is
>    extraordinarily difficult.  It is, however, possible to design
>    protocols which minimize the extent of the damage done under these
>    circumstances.
>
> As you can see, this text explicitly acknowledges the possibility
> of endpoint compromise and considers that it is possible to
> partly mitigate it, as I said above. I think we should continue
> to ask the question of whether we could do better in this area,
> as you do above, but I think that the most appropriate way
> for the IETF (as opposed to other organizations, such as, say
> TC39 or Bytecode Alliance) to do this is to focus on improving
> our protocols.
>

I agree with the sentiment. But a heck of a lot of water has gone under the
bridge since 3552. What was an acceptable security approach then isn't
today.

20 years ago the prevailing mindset was that one compromise meant game
over. We don't build systems like that any more. We consider issues like
implementation flaws, compromise of TTPs, and a lot of other things we
didn't then.

And here is the most important part, we don't just analyse the security of
components, we look at the systems.

I can't give you an architecture that will guarantee that you are safe in
every possible eventuality, but I can provide protection that is robust
unless there are multiple failures in multiple different systems. That is
why zero trust is such a bad slogan, if you want robust, practical security
you have to divide trust between multiple systems and parties so that you
don't trust any one of them absolutely and multiple parties have to defect
or systems have to fail for a breach to occur.

I have the code, I have the specifications, they are clearly within scope
of what IETF says it wants to do. But nobody seems interested in doing
anything more than tinker with existing protocols.