On Thu, Jan 5, 2023 at 8:59 AM Eric Rescorla <ekr@xxxxxxxx> 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.
