Re: [core] AD review of draft-ietf-core-echo-request-tag-10

[Roman Danyliw <[e-mail]>]

Hi!

The notion of defining, labelling and discussing the distinction between attackers who can read, inject, delete, and modify data vs. read and inject, but not necessarily delete on modify data, seems like helpful precision.  Thanks for doing it.  

To make a few general comments ...

For me, "on-path" speaks to where an attacker is located topologically, not what capabilities the attacker will _always_ have -- there can be mitigating factors based on the particular details of the protocol or operational configurations.  I'd also say the same for "MiTM" too.  Furthermore, I don’t think that in the abstract that we have a an commonly accepted definition precise enough with MiTM vs. on-path attacker to the degree  that we can make the distinction that the latter (again in the abstract) has less capabilities than the former (or vice versa).  

In terms of prior definitions, consulting Section 3.5 of RFC3552:

3.5. On-path versus off-path

   In order for a datagram to be transmitted from one host to another,
   it generally must traverse some set of intermediate links and
   gateways.  Such gateways are naturally able to read, modify, or
   remove any datagram transmitted along that path.  This makes it much
   easier to mount a wide variety of attacks if you are on-path.

This suggests that an "on-path attacker" can indeed read, modify and remove datagrams.

Back to this specific document, enumerating the specific collection of attacker capabilities _with_ a description of where this adversary would need to be topologically seems like the right editorial approach.  Again, thanks for trying to be so clear.

Regards,
Roman 

> -----Original Message-----
> From: core <[e-mail]> On Behalf Of Barry Leiba
> Sent: Wednesday, September 2, 2020 8:56 AM
> To: Göran Selander <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10
> 
> For what it's worth, I just reviewed a routing document that uses the phrase
> "an attacker in the middle of the network", which is another option.
> 
> Barry
> 
> On Wed, Sep 2, 2020 at 8:52 AM Göran Selander
> <[e-mail]> wrote:
> >
> > Hi,
> >
> > As I understand "replace" and Carsten's provided definitions, an on-path
> attacker does not necessarily have that capability. But I agree with John's
> proposal and updated the github version accordingly. In the same way I also
> replaced the only use of "on-path attacker" in the draft with "attacker". The
> commit is here:
> >
> > https://github.com/core-wg/echo-request-tag/commit/29969c4
> >
> > Any other comments on the recent changes? We plan to submit a new
> version on Friday.
> >
> > Göran
> >
> >
> > On 2020-09-01, 21:29, "Barry Leiba" <[e-mail]> wrote:
> >
> >     John has a good point here, and I support his proposal.
> >
> >     That said, remember: I did say that it's not a big deal and I'm
> >     leaving it to y'all's best judgment.  All I wanted was for you to
> >     consider the issue... not to rehash "fun" discussions from elsewhere.
> >     And whichever way you choose isn't going to block this document.
> >
> >     Barry
> >
> >     On Tue, Sep 1, 2020 at 3:13 PM John Mattsson
> <[e-mail]> wrote:
> >     >
> >     > In this sentence I think on-path attacker works quite well or even better.
> It already follows from the sentence that the attacker is able to replace one
> block with another. The attacker in this case does only needs to be able to
> reorder packets flowing in one direction of the communication.
> >     >
> >     > We could also just use the word attacker, e.g.
> >     >
> >     > "it is still possible for an attacker able to reorder packets on the path
> from client to server to maliciously replace a later operation's blocks with an
> earlier operation's blocks."
> >     >
> >     > Cheers,
> >     > John
> >     >
> >     > -----Original Message-----
> >     > From: Carsten Bormann <[e-mail]>
> >     > Date: Tuesday, 1 September 2020 at 18:40
> >     > To: Göran Selander <goran.selander=[e-mail]>
> >     > Cc: Barry Leiba <[e-mail]>, "draft-ietf-core-echo-
> [e-mail]" <[e-mail]>,
> "[e-mail]" <[e-mail]>
> >     > Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10
> >     > Resent from: <[e-mail]>
> >     > Resent to: <[e-mail]>, John Mattsson
> <[e-mail]>, <[e-mail]>,
> <[e-mail]>, <[e-mail]>, <[e-mail]>,
> <[e-mail]>, <[e-mail]>, Marco Tiloca
> <[e-mail]>
> >     > Resent date: Tuesday, 1 September 2020 at 18:40
> >     >
> >     >     On 2020-09-01, at 16:19, Göran Selander
> <goran.selander=[e-mail]> wrote:
> >     >     >
> >     >     >
> >     >     >    — Section 3.5.1 —
> >     >     >
> >     >     >       is still possible for a man-in-the-middle to maliciously replace a
> >     >     >       later operation's blocks with an earlier operation's blocks
> >     >     >
> >     >     >    Not a requirement here, and I will accept your best judgment:  in
> the
> >     >     >    spirit of recent discussion on inclusive vs exclusionary language, I
> ask
> >     >     >    you to consider changing “a man-in-the-middle” to “an on-path
> attacker”.
> >     >     >
> >     >     > [GS] I thought there was a slight difference between "on-path
> attacker" and "man-in-the-middle”, in that the latter has access to the message
> flow whereas the former need not have. For example, an on-path attacker may
> only be able to inject messages. In this case ("replace") the latter would then be
> more precise. If I'm right then I propose we use available distinctions pending a
> new dictionary, otherwise I'm fine with changing.
> >     >
> >     >     Oh, so we are getting to have this fun discussion on *this* draft.
> >     >
> >     >     A MITM can read, inject, delete, and modify data.
> >     >
> >     >     An on-path attacker can read and inject, but not necessarily delete or
> modify data.
> >     >
> >     >     I would not use the latter as a synonym for the former.
> >     >
> >     >     The other proposal in
> https://protect2.fireeye.com/v1/url?k=8bc8ba21-d57827b9-8bc8faba-
> 861fcb972bfc-afe20b2d89bbd667&q=1&e=406fbb72-b2f0-4844-bd11-
> 3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology is even
> more broken: An impersonation attacker doesn’t even have to be on-path.
> >     >
> >     >     (See also my comment on
> https://protect2.fireeye.com/v1/url?k=a110182c-ffa085b4-a11058b7-
> 861fcb972bfc-2890999e614b0870&q=1&e=406fbb72-b2f0-4844-bd11-
> 3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology%2Fpull
> %2F1, which fell by the wayside in the recent lull on this topic.)
> >     >
> >     >     In the mid-2000s, there was an attempt to replace MITM attack by
> “middleperson attack”.  That utterly failed, a simple Google search says “man-
> in-the-middle” (54100 hits on dl.acm.org) is overwhelmingly still the term of
> art and not “middleperson” (31 hits on dl.acm.org).
> >     >
> >     >     Wikipedia at least knows about the other established word for MITM,
> Janus attack
> https://en.wikipedia.org/w/index.php?title=Janus_attack&redirect=no — not
> very successful either (9 hits on dl.acm.org).
> >     >
> >     >     One word that already has the right semantics and does not require
> the cultural background of “Janus attack” is “Interposer attack”.  0 hits on
> dl.acm.org, but has all the right properties.  So in the above we would replace
> MITM by “interposer”:
> >     >
> >     >     >       is still possible for an interposer to maliciously replace a
> >     >     >       later operation's blocks with an earlier operation's blocks
> >     >
> >     >     WFM, even if this is blazing a new trail.
> >     >
> >     >     Grüße, Carsten
> >     >
> >     >
> >     >
> >     >
> >
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core