Re: [dmarc-ietf] THIS IS ABUSE (it might be)

Alessandro Vesely <vesely@tana.it> Sat, 08 April 2023 11:16 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F442C151B37 for <dmarc@ietfa.amsl.com>; Sat, 8 Apr 2023 04:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="akU9ADAl"; dkim=pass (1152-bit key) header.d=tana.it header.b="CBLzapo6"
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 48xuLMy08oum for <dmarc@ietfa.amsl.com>; Sat, 8 Apr 2023 04:16:16 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A62C14CE45 for <dmarc@ietf.org>; Sat, 8 Apr 2023 04:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1680952566; bh=Cri78UHfP7dnghDx6VOoWW5z11sXOpFcr3oaruM6aao=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=akU9ADAlmCYwxoRzsfybt/SEUIjtasdg5m8aXERnwcm16/oPlNwMC9zXqAedLr+R+ NOGzIJbCfDr7UQcsKrBBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1680952566; bh=Cri78UHfP7dnghDx6VOoWW5z11sXOpFcr3oaruM6aao=; h=Date:Subject:To:References:From:In-Reply-To; b=CBLzapo6r0ctfv/fc0LdLhFjhWyZhJlIpZc/j3rJynT8HpxAgTNLuSXOXONIf4cwD EvSFpB6c7oao1MNioSBxnqUD1/kJ5cuuF5LhJoEntFrBWUO7xEI0qO10mpKWco+pHz NezQM5Si0BeR8G6ICAPR2ifyrGGRB7/d7c5Wfk3RSQ3otFSQb69qHwMJ2PmCN
Original-Subject: Re: [dmarc-ietf] THIS IS ABUSE (it might be)
Author: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC09F.0000000064314CF6.00002C83; Sat, 08 Apr 2023 13:16:06 +0200
Message-ID: <2a35cc3f-7dde-8e63-98c3-05f64ab63f57@tana.it>
Date: Sat, 08 Apr 2023 13:16:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: en-US, it-IT
To: dmarc@ietf.org
References: <MN2PR11MB43519A6CD95E5C80AA1EC2CFF7899@MN2PR11MB4351.namprd11.prod.outlook.com> <82BA61C2-8A68-4CD7-ABCC-8E7BD19C7F68@kitterman.com> <54d18f40-636a-aa78-a301-5ad00868f17a@tana.it> <8898686F-429F-4166-8C05-3A554FB0ABFF@kitterman.com> <CAH48ZfwH44nXntNEycDLxO8MbZ-pdwAbQWVZs9Kmn+BYsTp__A@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAH48ZfwH44nXntNEycDLxO8MbZ-pdwAbQWVZs9Kmn+BYsTp__A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/LvYwZB6w03sSUCYqXNVhfAOOS0A>
Subject: Re: [dmarc-ietf] THIS IS ABUSE (it might be)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Apr 2023 11:16:22 -0000

Identifier rewrite affects the leg from MLM to subscriber.  Email security in 
the leg from poster to MLM is completely ignored by the draft, although MLMs 
constitutes a major concern.

We joyfully rely on traditional techniques to counter potential attacks, 
estimating that there is no reason to adopt cryptographic stuff to secure email.

Water we talking about?


Best
Ale


On Sat 08/Apr/2023 01:54:21 +0200 Douglas Foster wrote:
> Scott's approach solves our longest-running argument, but not in the way
> that I expected.    We can embrace his approach with a single Security
> Consideration to this effect:
> 
> "Mailing lists are frequently characterized by operating practices that
> depend on security through obscurity rather than Sender Authentication.
>   Identifier rewrite may be used as necessary to evade detection of weak
> Sender Authentication practices.   While exceptions doubtless exist,
> determining the trustworthiness of messages from any particular mailing
> list is difficult, and beyond the scope of this document.   Participation
> risk should be taken into account when subscribing to a mailing list and
> accepting incoming messages from a list."
> 
> However, this type of truthfulness does not seem to be what the charter
> document intended.
> 
> Doug Foster
> 
> 
> 
> On Fri, Apr 7, 2023 at 4:24 PM Scott Kitterman <sklist@kitterman.com> wrote:
> 
>>
>>
>> On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely <vesely@tana.it> wrote:
>> >It is going to be problematic to kick off someone who impersonates
>> different users.  What do you do, block IP numbers?
>> >
>> >We keep on saying that mailing list have worked this way for decades.
>> Sure. And email in general has been working for decades before the need to
>> use authentication arose.  So we can bet that people using MLs is highly
>> selected and well behaved... but is that true?  Wouldn't a jester be able
>> to completely disrupt our work by heavily repeating impersonations to the
>> point that we'll be forced to restrict to Github tools to discuss our
>> drafts?  I wouldn't bet...
>> >
>> >Some time ago I proposed a p=mlm-validate[*] telling receivers to reject
>> on failure only if they are a mailing list or similar forwarder.  I thought
>> that would cause minimal disruption since such kind of posts most of the
>> times reach destination in one hop —akin to transactional stuff— and a
>> poster who gets a bounce can quickly retry.  Such kind of tool would
>> eliminate impersonation chances.
>> >
>> >An obvious truth is that we cannot publish a successful protocol if we
>> ourselves see no reason to make any use of it.
>>
>> To the extent managing mailing list subscriber abuse is a problem, it's
>> not a DMARC problem.
>>
>> The IETF has had problems with sock puppets before and managed to address
>> them.
>>
>> Scott K
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc