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

Eric Rescorla <ekr@rtfm.com> Sun, 04 October 2020 03:00 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427953A0AC5 for <saag@ietfa.amsl.com>; Sat, 3 Oct 2020 20:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4FHepGOgyWv for <saag@ietfa.amsl.com>; Sat, 3 Oct 2020 20:00:25 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D0B3A08CA for <saag@ietf.org>; Sat, 3 Oct 2020 20:00:25 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id h6so57141lfj.3 for <saag@ietf.org>; Sat, 03 Oct 2020 20:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LIGFOosY43a83Kt7znLFRs9uue3zuJ498DogtgNE6Rc=; b=oLKp20HJzQAynMH1c+cGUmtngGEkw+Bmj5BdOXqsdsAPy70/9JUeHCGxFQlBrmjSP5 Lnw4gGOOY4cXD/4JEz7odNbOkpLRaSvqmtP9cZc7OsHYx3J/lJSrZ4bBjqP/ku3RcNJH TdhW8rAeO1l6/D+aG5+eBjHInnXhMPiWROn9vdYHMalvWD78roAjIMtc+lWgrFSXhn7O LDwd7xCb/PNmgVCQ9FBM0FgRSS0lmw+NDBToexMCOwRZQPvPXptc1lgngnE6zGTrgLre eFcEw5ZBhGbIkb7lfyzxciHJ1kh4QL4mubqrEteJOA2tmgcds/WP4lHiqTzRIP5EK9I2 pBgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LIGFOosY43a83Kt7znLFRs9uue3zuJ498DogtgNE6Rc=; b=AQzYRWbZw2B0SVRe8NinKLyoJZs8u4ycCoyo98zjTpPrK+kTZgL1cmuLTIM+D5rNTn vTTwpXgKv4dvHfjdGZsrMfbLR/UxrziKD1UoCMcKHAXYnVyAQhtzhPOEaCf06UEf7f3M ewNyzJTTzSQXLZctDaKhHI3YlYKc5/ysxJiIQDHStVSgc3JJF6ioqCyjJ4lW07NnX35r GRSfOPySEKdVdWtSl+gc+CLCghoLw1nnGsaG18wqkGhDhiR1PVh1dEXdcjEK/0qmI6ZU mG1ZGTsXlW5gM8RA8LCz1wJUcyu5jH9ZxQw+oNcNG6i36onYmcm+yoFzton4LaeB7lD8 EHPQ==
X-Gm-Message-State: AOAM532MFRinWgKfstgstxgBUgGh8Sah2kJN/hbhyYklVU/Xy4BVjlN6 rkGtn4mBhPoFb5UzY1zpJzo+hgLmSD4BRsa+BRkamA==
X-Google-Smtp-Source: ABdhPJwILQn2JnB8oWaFKOUTlMYDx28GE6VH8apgpc1EMv/g7Lef+c8GFml21ZLsx7s8qt5ZQUEHnMvQr9uMVrRyq14=
X-Received: by 2002:ac2:4e92:: with SMTP id o18mr3321750lfr.543.1601780423701; Sat, 03 Oct 2020 20:00:23 -0700 (PDT)
MIME-Version: 1.0
References: <4645.1599064072@localhost> <6859c97d-3f0c-0361-5e72-5b82e93568f7@gont.com.ar> <CABcZeBNuBhu8KUoZJsY3VR8LzDa78_n53rRZ-5nMrpCbqh_6KQ@mail.gmail.com> <14793.1601778326@localhost>
In-Reply-To: <14793.1601778326@localhost>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 3 Oct 2020 19:59:47 -0700
Message-ID: <CABcZeBPPZuRri7vC1gR+asmiyi+ABDA3RA16UHJQbEgW95+q_g@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Fernando Gont <fernando@gont.com.ar>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000029cc7f05b0cf91d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/zEMaIKiQlly8plzjdm1cWRomdfA>
Subject: Re: [saag] can an on-path attacker drop traffic?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Oct 2020 03:00:27 -0000

On Sat, Oct 3, 2020 at 7:25 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Eric Rescorla <ekr@rtfm.com> wrote:
>     > 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.
>
> I'm very much in agreement.
>
>     > 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]).
>
> "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 :-)
>

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


>     > 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.
>
> 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.
>

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

-Ekr

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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>