Re: [dmarc-ietf] BATV

Douglas Foster <dougfoster.emailstandards@gmail.com> Sun, 17 April 2022 20:52 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
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 561AE3A15EC for <dmarc@ietfa.amsl.com>; Sun, 17 Apr 2022 13:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.086
X-Spam-Level:
X-Spam-Status: No, score=-1.086 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xRBMKIrcG2DB for <dmarc@ietfa.amsl.com>; Sun, 17 Apr 2022 13:52:51 -0700 (PDT)
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (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 B60AD3A15EB for <dmarc@ietf.org>; Sun, 17 Apr 2022 13:52:51 -0700 (PDT)
Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-e5ca5c580fso2293784fac.3 for <dmarc@ietf.org>; Sun, 17 Apr 2022 13:52:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=71iWrqDPSC3QKNF2FACNa8QwZZqDR01hT6VDrWIrvqQ=; b=IZXfLJvFBbyhm1uDEJ4wNB6L6LuL+INNuMqxtEw2SZkz9iETN88CIz56tw5Whkz87B vzQveDGtBe6zXn3G7X/o2NnaMi39Wi5mZyYb+QVgQWo0+TzoxIJKQJRAxRjHjdvjClcC pfjeXRntTW+VACnIKUEApKNJ5sI59rJPEmlsqzWJKP0ajKmWMtyUtPw6NqejEBufWxW+ q71OrvWhOakaudXdEeun3KqA9Ld00T2qeba8XBEzvFB20WFrGF+4WfwwhZygewGbDg0C SIumSDkdpAl0CGIB60iP2FLLvjei1+Ec+pZOSsAm3St18q7Ai2ER0QYi+jUe4IoI/ZOZ +lDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=71iWrqDPSC3QKNF2FACNa8QwZZqDR01hT6VDrWIrvqQ=; b=QVyhylBrliqarhoDEkYyE6zJsl8KCItYOk51XvbYwBJBOUg6epNfBHBSWLpfwRvLIc eI3cHXrxleP1zDAAvN6Y6owjZ6mQWLCNlp3vaXA6nvyGiRGERsfuTQPK0HF2kseS9Zsn ehYtE39NVgasyYAd9+Tb/ljXW3KDj2V9k3SNCzgjljG2HOGWgxKd5OlvDXKJ02jsf/q5 RDRXvkhhX1xja/etEF2rV5Jeokqr0qpBRMGYEqdPd03re26YVY9raK6DeTPb39HDaTQs rrPoIL0pdhu8iWsgmcpp4FeWuZwcT7vZyW7scf+lWlBqg2eSmLqWwhjVnqE/0dD47aoQ yj/w==
X-Gm-Message-State: AOAM530rPrWJ7FttYEBmrVx1eW1pe2Y/2nJnc1OyAL1nEaxzKAlVd6sE wwAeD+BOQJkTCCa6/xau2wELTTHIgmG6RYqiZoyDPvlI
X-Google-Smtp-Source: ABdhPJxcXjRaw8gRRjVM/gShdBaWhjIjT2ZSruxomEXzbkvqv5mVwtj1T5eIRYHpuND/BmxDGQ/qUOpI3jGLH9yy3Rc=
X-Received: by 2002:a05:6870:2041:b0:de:f8b7:d98e with SMTP id l1-20020a056870204100b000def8b7d98emr3121786oad.51.1650228770313; Sun, 17 Apr 2022 13:52:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAH48Zfz_9wj88D507K56Orw+FDRNnL9XSm7bQ1VZQPo_TTkW7A@mail.gmail.com> <CAL0qLwa=QvZ2AwZmiEbUVcRQu9zmvze3iLOioO7Xu1LG0BoF8w@mail.gmail.com>
In-Reply-To: <CAL0qLwa=QvZ2AwZmiEbUVcRQu9zmvze3iLOioO7Xu1LG0BoF8w@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sun, 17 Apr 2022 16:52:39 -0400
Message-ID: <CAH48Zfw0rK5rd5-imr29h+kGBV0h+nBjWrGT2SRTr4XTXCBhLw@mail.gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a71be805dcdfd3bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fHRBtp-riYIgaSAqVy9xjiDFrGw>
Subject: Re: [dmarc-ietf] BATV
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 17 Apr 2022 20:52:57 -0000

Your DKIM solution is a viable one for the A-R problem, and would also work
for the other idea which triggered the suggestion.
.
>From an ideal standpoint, I would argue that stripping of prior A-R records
should occur at every entry point (Unauthenticated SMTP, Authenticated
SMTP, ActiveSync, EWS, MAPI).    I am not convinced that stripping is
possible from all of those sources, so A-R has always seemed vulnerable to
a persistent attacker.

To your deployment questions:    Barracuda is the commercial
implementation, but it uses "BTV1==" instead of "PRVS=".    I have logged
195 incoming MailFrom domains that are currently using one or the other
technique, including Ricoh (copiers), Cracker Barrel (restaurants), Cigna
(insurance), Experian (credit), Lilly (Pharmaceuticals), and CrowdStrike.

You are correct that it is a small percentage of mail volume; for me it is
less than 1%.  It is also worth noting that fake bounce attacks were a fad
several years ago, but have become rare.

Doug

On Sat, Apr 16, 2022 at 10:17 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Sat, Apr 16, 2022 at 5:35 AM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> I would like to see John Levine's BATV document revived from expired
>> draft status
>> https://datatracker.ietf.org/doc/html/draft-levine-smtp-batv
>>
>> BATV is in use within the current mail stream, and one commercial product
>> has cloned it to make a proprietary version of the same idea, so it is time
>> to declare it a success.  More importantly, it provides a general
>> technique, based on signature and timestamp, which permits private
>> communication between MTAs using insecure RFC5322 header fields.  That
>> technique has other uses.
>>
>
> Who's using it?  Which commercial product are you talking about?
>
> I wrote and released an open source BATV filter for use with postfix and
> sendmail back when it was a new idea.  The interest in the filter or in the
> specification was negligible, as there were legitimate use cases with which
> it interfered, such as these:
>
> https://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation#Problems
>
> For example, A-R does not include a signature security mechanism, so
>> implementers must be concerned about injection of spoofed A-R records.
>>  Because ARC is dependent on the secure transmission of A-R within one
>> organization, weak A-R also weakens ARC.  Both problems would have been
>> avoided by using the BATV signature system, but expired drafts make poor
>> reference documents for other RFCs
>>
>
> If you're following the A-R specification, you only trust your own A-R
> fields (unless you really know what you're doing), and your border MTAs are
> supposed to strip anything it identifies as spoofed.  In theory, you can
> trust anything you see beyond that point that's bearing your own
> authserv-id.  If you think that's not enough, you could DKIM sign the
> message on ingress, including the A-R field you're adding on the way in, so
> that it can be proven legitimate.
>
> -MSK
>