Subject: Re: [saag] can an on-path attacker drop traffic?

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2020 23:54:06 -0300

On 2/9/20 13:27, Michael Richardson wrote:
[...]
> 
> A firewall or router is a potential on-path attacker, but it can also drop packets.
> What do we call this?
> This was historically called a MITM, and it implied all the attributes of
> on-path.  But it is unclear to me if MITM > on-path, or MITM == on-path.

FWIW, I'd call this "man in the middle", and I'd say MITM > on-path.

MITM implies the attacker receives the packets, and then it's up to the 
attacker to just inspect and pass on, or inspect & drop, or simply drop.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Oct 2020 07:03:14 -0700

As I think this discussion reveals, we don't have a really precise
description of MITM, in part because it's quite an old term from an
era where we had much less ability to analyze security protocols than
we do today. One result of improvements in analysis is the need for
precise definitions so that we can formalize the guarantees of systems
against those definitions. This process is rather further along in in
cryptography where there are very precise definitions for both the
assumptions that our primitives depend on (RO, CDH, etc.) and the
security guarantees they provide (IND-CCA2, etc.), but it is happening
in communications security as well.

In general, we need terms for both attacker capabilities and attacks.

For capabilities, our basic assumption is what is often called a
Dolev-Yao attacker, in which the attacker has complete control of the
channel (this is what 3552 describes as the Internet Threat model
[0]). However, it's also useful to try to consider more limited
attackers such as those who can only read from the wire and those who
cannot remove packets. To my knowledge, we don't have a consensus set
of precise definitions for these yet, though both 3552 and QUIC [1]
make a stab at this). Similarly, some attacks are well-defined
(reflection, identity misbinding, KCI, impersonation etc.) and some are
not.

This brings us to MITM which is often used both for a set of
capabilities (usually roughly a Dolev-Yao attacker) and for a class of
active attacks including straight up impersonation to various kinds of
relay attacks). This broad a scope of usage isn't that useful and
rather than trying to give it a precise definition, it's probably time
to retire the term and replace it with a set of terms (perhaps
including some new terms) that do have precise definitions.

-Ekr

[0] https://tools.ietf.org/html/rfc3552#section-3
[1]
https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-31#section-21.13.3

On Thu, Oct 1, 2020 at 8:01 PM Fernando Gont <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Dan Harkins <[email-masked]>
Date: Sat, 03 Oct 2020 18:14:22 -0700

On 10/2/20 7:03 AM, Eric Rescorla wrote:
[snip]
> cannot remove packets.
   Why? If we want to develop protocols that are secure in the presence of
a powerful attacker who has complete control of the medium what value
is there in considering a "more limited attacker"?

   It sounds like you're making a distinction between a passive attacker
and an active attacker. Which is fine but what use do you see in a protocol
that is secure against this "limited attacker" but not against the more
powerful attacker?

   Dan.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Oct 2020 22:25:26 -0400

Eric Rescorla <[email-masked]> wrote:
    > description of MITM, in part because it's quite an old term from an era
    > where we had much less ability to analyze security protocols than we do
    > today. One result of improvements in analysis is the need for precise
    > definitions so that we can formalize the guarantees of systems against
    > those definitions.

I'm very much in agreement.

    > [0]).

"Dolev-Yao" is a bit of a mouthful, but maybe if I say it really fast as if
it's the name of a Kata it will work for me :-)

    > However, it's also useful to try to consider more limited

The QUIC 21.13.3.1 "on-path" attacker seems to be a Dolev-Yao attacker.

The 21.13.3.2 "off-path" attacker seems to have the ability to observe
packets, which I normally would not think an off-path attacker would have.
So this definition is very surprising to me.

RFC7416 has some terms (sinkhole, wormhole) that might be useful.
I notice that sections 21.13.3.4 about how an off-path could become on-path
by offering "better" routing.

Perhaps this is worth an hour of IETF109 SAAG time.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Oct 2020 19:58:15 -0700

> that is secure against this "limited attacker" but not against the more

IMO the primary reason is that (!) there are some attacks which we do not
presently know how to defend against in the case of a Dolev-Yao attacker,
but which we can defend against a weaker attacker and (2) weaker attackers
exist.

As a concrete example, it is possible for such an attacker to terminate
even connections which are cryptographically protected (e.g., QUIC) by
simply refusing to carry any packet, so in this respect, QUIC and TCP are
similar. However a weaker attacker (e.g., an off-path attacker) can
terminate TCP connections by forging RSTs, which does not work against QUIC
because the connection termination signals are cryptographically protected.
I believe this is of some security value -- though perhaps you don't agree,
but we can only properly analyze it by considering a range of attacker
capabilities.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Oct 2020 19:59:47 -0700

On Sat, Oct 3, 2020 at 7:25 PM Michael Richardson <[email-masked]>
wrote:

> era

I agree. It might be useful to create a new name, as long as we are careful
to have
a precise definition.

> So this definition is very surprising to me.

I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it in
IETF-LC.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Oct 2020 20:05:57 -0700

> but we can only properly analyze it by considering a range of attacker

Following up to myself, an example of where the distinction between a
passive and active attacker is useful is browser fingerprinting. A browser
fingerprint which can be measured by the site without taking any explicit
action (e.g., User-Agent) is more concerning than one which requires the
site to take some browser-visible action. In the former case, we are not
able to know whether sites are using it for tracking and thus must assume
they are, but in the latter we can measure -- and potentially restrict --
the use of the parameter.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 4 Oct 2020 04:42:46 +0000

Dan Harkins <[email-masked]> writes:

>Which is fine but what use do you see in a protocol that is secure against
>this "limited attacker" but not against the more powerful attacker?

Because it's far easier to deploy a relatively straightforward, realistic
protocol secure against a general attack than it is to deply an awkward,
complex, impractical protocol that's theoretically (but often not practically)
secure against a more unlimited attacker.  To quote the end of John Gordon's
joke:

  Now most people in Alice's position would give up. Not Alice. She has
  courage which can only be described as awesome. Against all odds, over a
  noisy telephone line, tapped by the tax authorities and the secret police,
  Alice will happily attempt, with someone she doesn't trust, whom she cannot
  hear clearly, and who is probably someone else, to fiddle her tax returns
  and to organize a coup d'etat, while at the same time minimizing the cost of
  the phone call.

  A coding theorist is someone who doesn't think Alice is crazy.

I don't need a theoretically perfect protocol that's practically un-
deployable, I just need something that's practical and good enough for the
job.

Peter.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 3 Oct 2020 22:23:20 -0700

> On Oct 3, 2020, at 8:00 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I agree it's not ideal. QUIC has been pubreq-ed, so you could raise it in IETF-LC.

I think of it as man-in-the-middle, man-on-the-side and man-in-the-rough. For me, the man in the middle is what EKR refers to as the Dolev-Yao attacker; best hope there is to detect the attack and reduce it to a denial of service.

The man on the side is capable of reading the traffic and injecting messages; it cannot easily delete messages,  but it can win races and get his own fakery delivered before the genuine packets -- TCP RST is an example of such attacks. Various national organizations have that capability. It is much easier for them to implement than a full MITM. I think that with effort we can defeat this class of attackers.

The man in the rough does not see the traffic but can make guesses. DDOS attacks, port scanning, observing or gaming DNS caches fall in that category. Botnets sometimes resort to these attacks.

And yes, in 2020 we probably need names that don't carry "man-in-foo" imagery. But English is not my mother tongue...

-- Christian Huitema

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 04 Oct 2020 08:17:13 -0700

I like Christian's triage (minus the "men"). The "where are they 
relative to the path" differentiation is likely to be more 
understandable to people who are not security geeks than "what they can 
do with creative use of packets". Using a road analogy: a person running 
a tollbooth, a person who can watch the cars go by and tell his 
colleagues when to enter the stream in order to do damage, a person who 
cannot see the traffic or send in cars but can cause lightning storms 
and send fake news to the cars on the road.

--Paul Hoffman

On 3 Oct 2020, at 22:23, Christian Huitema wrote:

> I think of it as man-in-the-middle, man-on-the-side and 
> man-in-the-rough. For me, the man in the middle is what EKR refers to 
> as the Dolev-Yao attacker; best hope there is to detect the attack and 
> reduce it to a denial of service.
>
> The man on the side is capable of reading the traffic and injecting 
> messages; it cannot easily delete messages,  but it can win races and 
> get his own fakery delivered before the genuine packets -- TCP RST is 
> an example of such attacks. Various national organizations have that 
> capability. It is much easier for them to implement than a full MITM. 
> I think that with effort we can defeat this class of attackers.
>
> The man in the rough does not see the traffic but can make guesses. 
> DDOS attacks, port scanning, observing or gaming DNS caches fall in 
> that category. Botnets sometimes resort to these attacks.
>
> And yes, in 2020 we probably need names that don't carry "man-in-foo" 
> imagery. But English is not my mother tongue...
>
> -- Christian Huitema

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 4 Oct 2020 17:41:44 +0200

On 2020-10-04, at 17:17, Paul Hoffman <[email-masked]> wrote:
> 
> I like Christian's triage (minus the "men”).

+1.

Note that these are classes of capabilities.
It is worth talking about classes of attacks separately.

Grüße, Carsten

---

From: Alan DeKok <[email-masked]>
Date: Sun, 4 Oct 2020 12:46:29 -0400

> On Oct 4, 2020, at 11:17 AM, Paul Hoffman <[email-masked]> wrote:
> 
> I like Christian's triage (minus the "men"). The "where are they relative to the path" differentiation is likely to be more understandable to people who are not security geeks than "what they can do with creative use of packets". Using a road analogy: a person running a tollbooth, a person who can watch the cars go by and tell his colleagues when to enter the stream in order to do damage, a person who cannot see the traffic or send in cars but can cause lightning storms and send fake news to the cars on the road.

  My $0.02 is to call this "the council of attackers".  One is a malicious messenger, who rewrites messages he sends.  Another is the oppressive observer, who uses your information against you.  And the third is the chaos creator, who just breaks things so you can't use them.

  Alliteration is cute, and helps with memory.  :)
 
  Alan DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Sun, 04 Oct 2020 10:15:37 -0700

> deployable, I just need something that's practical and good enough for the

   For some people the job includes tax avoidance and fomenting of coups.

   Dan.

---

From: Dan Harkins <[email-masked]>
Date: Sun, 04 Oct 2020 10:22:40 -0700

> that category. Botnets sometimes resort to these attacks.

   This is useful. Defining it as classes of capabilities. The 
man-in-the-rough has
certain capabilities, class C. The man-on-the-side has those plus some 
others, class B.
And the man-in-the-middle (the Dolev-Yao attacker) has those plus some 
others, class
A. And A > B > C.

> imagery. But English is not my mother tongue...
   Yes, and sadly, this being 2020, identity politics plus bike shedding 
will mean most
of the time is spent on naming/imagery.

   Dan.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Oct 2020 16:31:12 -0400

>   Why? If we want to develop protocols that are secure in the presence
    > of a powerful attacker who has complete control of the medium what
    > value is there in considering a "more limited attacker"?

The utility of the terminology is that it makes it clear what kinds of
threats there are, and what mechanisms defend against which.

There are many cases where we can assume (as a result of a sound L2 protocol)
that there are no Dolev-Yao on-path attackers, but that there may be many
off-path attackers who can send traffic.

At the same time, the existence of nodes which may harbour malware, giving
them access to the L2-media, but not to make on-path attacks, makes
understanding what the layers of defense we might have.

---

From: Nico Williams <[email-masked]>
Date: Sun, 4 Oct 2020 17:17:16 -0500

> > that is secure against this "limited attacker" but not against the more

We could come up with a name for each set of attacker capabilities, or
we could just list the capabilities.  We should want a compact
representation so as to aid in keeping things pithy.

It is true that neither "on-path" nor "MITM" are sufficiently exact.

For example, "on-path" need not imply "active attacker", for example,
and "MITM" need not imply physically on-path.  And an active attacker
who is on-path can be an MITM at some layers but maybe not others.

An active attacker who is on-path should be able to observe, modify, and
insert messages, but dropping messages might be harder.  For example, in
a wireless system dropping a message might require jamming it, but that
would require making a decision to drop a particular message before the
transmission of it ends -- having to see the whole message first would
mean not being able to jam it because the whole message will also
already have been received by the intended recipient.

Note that in the wireless example "on-path" is just not a very good
descriptor at all.  If the communication is line-of-sight and the
attacker could literally block all radiation in the relevant frequencies
between the two end-points, then they can be on-path in the same sense
that the attacker could be on the wire.  Otherwise the attacker is
on-path some ways, and not at all in others.

IMO there's enough combinations that we probably just want to list the
attacker's capabilities.  We could encode it pithily as a set of one-
character flags, say:

  Ln{flags},Ln{flags}...

where <n> is a layer and {flags} is a set of letters, each representing
a capability:

 - O (observe)
 - M (modify)
 - I (insert)
 - D (drop)

E.g., 'L3O' == "on-path" eavesdropper, "L3OMID" == all-powerful on-path
MITM at layer 3 that a protocol might want to defend against, but taking
EKR's point about DoS (below) we might limit our threat models to just
L3OMI attackers.

Such pithy attacker capability description language would probably need
a lot of work to be really useful.  For example, a real attacker might
only be on-path enough to see some DNS traffic but then might leverage
DNS spoofing and cache poisoning to get itself to be on-path enough in
some cases.

> but we can only properly analyze it by considering a range of attacker

This is a DoS attack.  It is true that many DoS attacks cannot be
defeated cryptographically.  For example, a physical cable cut cannot be
protected against with crypto.  What kinds of active attacks other than
DoS attacks cannot be defended against?

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Oct 2020 16:47:57 -0700

> DoS attacks cannot be defended against?

I'm not sure that I would characterize connection termination as DoS
(arguably, this is another case of terminological imprecision). For
instance, sometimes it's a piece of another attack, such as in ABP+13 [0]
or BDF+14 [1].

In any case, another example of an attack that is difficult to defend
against cryptographically is IP address spoofing attacks. For instance, an
on-path attacker can force QUIC migration (how useful this is is not clear)
but an off-path attacker cannot and an on-path attacker who cannot delete
packets is supposed to be able to cause a hiccup but not permanent
migration.

Finally, another example of a limited threat model is one in which the
attacker has Dolev-Yao access to only some set of network segments. This is
often used in the analysis of anonymity protocols like Tor. While it is
believed to be possible to build low latency protocols which provide
anonymity under this threat model, AFAIK it is not known how to do so
efficiently.

-Ekr

[0] http://www.isg.rhul.ac.uk/tls/RC4biases.pdf
[1] https://www.mitls.org/pages/attacks/3SHAKE

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Oct 2020 16:55:45 -0700

> anonymity under this threat model, AFAIK it is not known how to do so

Correcting my bad writing here: "While it is believed to be possible to
build anonymity protocols under the stronger threat model, AFAIK it is not
known how to do so efficiently."

-Ekr