From nobody Sun Dec 4 11:55:19 2022 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC18C14F607 for ; Sun, 4 Dec 2022 11:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olliejc.uk Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORbGX35leR4C for ; Sun, 4 Dec 2022 11:55:13 -0800 (PST) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10160C14CEE0 for ; Sun, 4 Dec 2022 11:55:12 -0800 (PST) Date: Sun, 04 Dec 2022 19:55:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=olliejc.uk; s=protonmail3; t=1670183709; x=1670442909; bh=3Nypd2N1DwMM6QZiWaooCzPNQ7FlkmvXWbtwtW9bRwo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=1se4nGNgE0vPEPkEQI7+79cxi9LgG2EaVTzRQBm402YqbWkROPJxG/NndBFdq07Xs 4EJ3+ZPxBMHm8mLta/l/cv+4dQCnQ/XBIpGl17o60W92cZoMq1k/MI0IhYrDNSfjhm FQ/BWfgRj3az1IQNpHH7GzEwpoQyRUp2szcZDTD3Qc4aTB5zcJTQpEzqrPvjYQYUuM FXrzpOC0gLlE9mOkXXfbdv30Nsxlg8KEtnISP70dGmRAyfXDnMWk74NXRYDlB5LKuI Mvk0BxdyRGLNJnJsRSJ3xpxOP4SLnZYqvAjZ9ImhGkh3LvIJ0NN5v0mXBe7fRQYl6p t/xywAktKH4vg== To: John R Levine From: Ollie IETF Cc: Dispatch WG Message-ID: <7iqzN8LGbQYpGu51OESQZnHLQMGzpFHGiJgPTLySkLkHa5jw-wAVKyOnWrCoJchviAmNOAfQSZnyoGR3QTZDPFWV2wZQJQgaRaNz5Dd-qJw=@olliejc.uk> In-Reply-To: <059faafd-80b2-66c0-7d8d-0087220f92ab@taugh.com> References: <20221204051320.0FF0650855F1@ary.qy> <-Qj162OnP3i43R95dL09E0OpifUzGvXqwTWEE8n14tndS8OQ902nGVvUTizxttYYEdamlyG54XdgeJCyFfntI8UJnVPbPRTvJk3VL_PMgqU=@olliejc.uk> <059faafd-80b2-66c0-7d8d-0087220f92ab@taugh.com> Feedback-ID: 63001471:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] Proposal for scantxt; scanning opt-in/out, identification, verification, notification, and reporting X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2022 19:55:18 -0000 > It's not hard to see how you could come up with standard ways for scanner= s > to say here's the kinds of scanning they do and here's the IPs they scan > from, and for the victims to say here's the IP ranges you can scan and th= e > ports you can probe, and replies from the scanners saying here's what we > found. That is my objective - to come up with those standard ways? I consider allowing/identifying via IP to be quite dated, prone to spoofing= and network attacks (BGP hijacking) and requires effort to maintain and ma= ke people aware of the source IPs (and I'd argue IPv6 adoption makes it har= der). Adding a token of some sort makes the source IP agnostic (think environment= s where source IP may not be known, multi-cloud FaaS/SaaS) and reduces the = spoofing potential, this is especially important in the instances where it = is used to bypass firewall/WAFs. Also, IPs may be transient, so if someone reviews logs days/months later, t= he IP may not 'belong' to the scanner anymore and so the token could be ret= rospectively verified (as long as the scanners public key is still availabl= e - perhaps there could be guidance around scanners keeping these in their = JWK etc. for a minimum time period). That said, I do suggest a standard way to indirectly identify via IP: Source IP -> PTR "_scanner.*" (where this also has the "scanner" TXT record= ) -> A/AAAA of Source IP So a victim/scanee could do a PTR lookup on the source IP and check for rev= erse DNS alignment and the TXT record and then allow if the domain equals a= known/allowed list - this mechanism would allow a scanner to change IPs. > Since the parties already know wach other you can wrap it in OAUTH > or the like to authenticate it. Part of the proposal is to have a primarily asynchronous approach where the= parties don't necessarily know, or need to know, each other. > The bad guys will scan anyway, and challenges have > a poor reputation in the security world. Yup, but this isn't for the bad ones, it's for people looking to do respons= ible, transparent scanning. Ollie