Re: [dmarc-ietf] Mandatory Sender Authentication

Dave Crocker <dhc@dcrocker.net> Sat, 08 June 2019 16:49 UTC

Return-Path: <dhc@dcrocker.net>
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 23648120123 for <dmarc@ietfa.amsl.com>; Sat, 8 Jun 2019 09:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 TNJgr5YkRtDb for <dmarc@ietfa.amsl.com>; Sat, 8 Jun 2019 09:49:12 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F2412011B for <dmarc@ietf.org>; Sat, 8 Jun 2019 09:49:12 -0700 (PDT)
Received: from [10.97.137.43] ([149.137.255.211]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x58GpJT4006023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Jun 2019 09:51:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1560012679; bh=Z2diibYa5SvmTLJI1m1ZWqnaRV2cl2mXRwb3X7R0kro=; h=From:Subject:To:References:Cc:Reply-To:Date:In-Reply-To:From; b=fMmYvIScJSTNuHuHXgmTkCKvPr53ZCJjg/AiXAxtmtCLM7RL0gpdXlW+iE5g4l7Bs Qb7qdZq3nP4a4Mz9gfOnbBfDwOZY9EuVm1I3t86La73LTLAwk/DsdZ7LfjoKNioubb SCsUKV1xhGqw6QBl2JG23hrbJdSk+0WrIQ5SGe5Y=
From: Dave Crocker <dhc@dcrocker.net>
To: fosterd@bayviewphysicians.com
References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com>
Cc: dmarc@ietf.org
Reply-To: dcrocker@bbiw.net
Message-ID: <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net>
Date: Sat, 08 Jun 2019 09:49:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <941abdbf28684283b972f69f25876220@bayviewphysicians.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/B1PZti495yQvg_NCcJ96ir_IJS0>
Subject: Re: [dmarc-ietf] Mandatory Sender Authentication
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: Sat, 08 Jun 2019 16:49:15 -0000

On 6/6/2019 7:09 PM, Douglas E. Foster wrote:
>>> 1. By 'sender', which actor in the sequence do you mean? The term is
> highly ambiguous.
> By Sender Authentication, I mean message "From Address" authentication.  
>   This involves two rules:
> 
>   * The sending IP address is known to be authorized to send for the
>     SMTP Sender-Address because of MX or SPF, and

MX does not 'authorize' sending by an IP address, although some 
receivers do check for MX as a heuristic.  But a heuristic is outside of 
any 'standard'.

SPF does register IP to domain name for sending.


>   * the SMTP Sender-Address is known to be authorized to send for the

Sorry, but the term "SMTP Sender-Address" does not have any specified or 
reliable meaning.


>     message from Address because of either
>       o domain alignment or
>       o a verifiable DKIM signature for the domain of the message
>         From-Address.
> 
> The message From-Address is what the user sees, so it seems important to 
> know that the user is not being deceived by an impersonator.

I assume you mean the RFC5322-level From: field, as opposed to the 
RFC5321-level Mail From command.  Except that most users don't actually 
see that address because these days most MUAs only display the display 
address.

As for end users being deceived, there's quite a bit of experience that 
showing users indicators doesn't alter their behavior.


>>> 2. Your certitude presumes an empirical foundation, given how often good
> theory does not make good practice. People have been working in this
> space for a very long time and one might have expected the industry to
> have latched on such a simple requirement were it that clear it was
> /the/ essential requirement. Please document the basis for your certitude.
> What I actually intend is that "a recipient has a viable option to 
> implement mandatory sender authentication."

I don't understand what it means to have an option to implement 
something that is mandatory.  It's mandatory.

Also by saying 'recipient' rather than 'receiver' you appear to be 
indicating the end users will do meaningful filtering based on this kind 
of information.  They won't.


> This i equivalent to enforcing basic DMARC rules whether the sender has 
> a DMARC policy or not.   This requires:

That means you are seeking to alter fundamental email semantics by fiat, 
globally.  Surely you jest.


>>> 4. Consider the limitations to 'sender' authentication.
> 
> I am spending a lot of time thinking about the limitations of sender 
> authentication.   For a spammer domain, SPF / DKIM / DMARC are easy.  

What do you mean?


>   For impersonation, Friendly Name and embedded logo images can be 
> pretty effective without violating SPF / DKIM / DMARC.

That's correct.  And there has been extensive discussions looking to do 
something about that but there are no proposals on the table, because so 
far none has looked viable.


> This means that Sender Authentication may produce more false positives 

No it doesn't.

The existing authentication mechanisms do a good job of authenticating 
what they are authenticating.

It appears that you are seeking to use the information far beyond what 
is valid.


> To minimize false positives, I would like to see:
> 
>   * Pressure on list forwarders to either not break signatures, or
>     follow the IETF example of replacing the original from with the list
>     domain and signing the new message with the list domain.

You want to bring pressure on list processing developers and/or 
operators.  Good luck with that.


>   * Advice to senders to reduce signature complexity.   In the general

What does that mean?  What specific proposal do you have?


>     mail stream, the purpose of the DKIM signature is to authenticate

You appear to misunderstand the semantics of DKIM.  Please re-read its 
specification and supporting document, because they have simple, concise 
language about what it does.



> But I have already been told that IETF is not interested in Recipient 
> product problems, and is not concerned with security, which has left me 
> very disappointed.


I suspect you have been told nothing of the sort.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net