Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

Dave Crocker <dcrocker@gmail.com> Wed, 03 June 2020 17:27 UTC

Return-Path: <dcrocker@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 BCF423A0C3B for <dmarc@ietfa.amsl.com>; Wed, 3 Jun 2020 10:27:59 -0700 (PDT)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 AL8qqAG61n3m for <dmarc@ietfa.amsl.com>; Wed, 3 Jun 2020 10:27:58 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 987513A0C38 for <dmarc@ietf.org>; Wed, 3 Jun 2020 10:27:58 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id a21so2506837oic.8 for <dmarc@ietf.org>; Wed, 03 Jun 2020 10:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=cHEKaIGPEN07jkWUxFblBRe0Q/Tc1qa9I5XmsMKNPfY=; b=IirX3kkvtFKhLZxZdgX3Y/fgXSpJ2V5h4TSvRrGDwygaMn2tbSZ/3Wd7rD54/RadS3 ZOyOam6nWp7RgQ2HuYMawBhRxn9ZJ9Cmd6Mp1+tvWdPvsS20alet/DaGareTspbcNxfn wSdTJZTTpPdRNx4zA/nTq/RIwQTo5KTS1XQt10axN8hhdvAd59aaAC//D0xDnGdScuKk ncqi+PgqtwkAuV6cdwxQoAfg+7RLgFUt67hBpqSBERDzv+1VaC1oWwsM6hxvC5WUa8es Vf2e324AGe8x/CgcWu1fMc22jBoV+md5gArnyAaBxnQzbAInj01mbm0re1o8DP6Hw8oy uEyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cHEKaIGPEN07jkWUxFblBRe0Q/Tc1qa9I5XmsMKNPfY=; b=l7khiuKihpmmqhJgy0gfy+gYekTTvW6sp71tmR649SaW1o9m4UqEibpl0XJbUrVy3O XkRToqn4cN6cla5MI6GbHjLMhxaAvBS5PmPQXAp5gnN4sikzEq11va9Ef8+UHBUViprQ 1ibhQxIXgCB9qjHQ47laMV7TubJDmVaQHeibqPasz5Nr+KZb0nFgDzEwnaT288CwzACf mOuA7mAAMGCEf2DsWzUvfvt3c/9L5UZrwo3MBC3ynepWu63R3BJzh5sqokhmtmz/XyXe 419Qir8lcqCkTJK8TQKydhcdQxSfTvplqdeJdY5+TxV+RzRzTj2wifyUsVSIKKfiqf2N HX9Q==
X-Gm-Message-State: AOAM53050IiQ/2BuyFSV5VEdibcKJOnn6aWTonyS/a8fPUvBp3i1FiFH lwef4qMXBlxC6j1oT151N38J90H6
X-Google-Smtp-Source: ABdhPJyMnjKdjR6ssw/yQ6/8ZB/ZZ+6iFsGQhxKh9gV9NDKm5g9rGR0cp0tQIFexw2J5eFoJwgO09w==
X-Received: by 2002:aca:cf4c:: with SMTP id f73mr509261oig.165.1591205276643; Wed, 03 Jun 2020 10:27:56 -0700 (PDT)
Received: from ?IPv6:2600:1700:a3a0:4c80:a98b:b45f:bb45:5051? ([2600:1700:a3a0:4c80:a98b:b45f:bb45:5051]) by smtp.gmail.com with ESMTPSA id a17sm622656otj.46.2020.06.03.10.27.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 10:27:56 -0700 (PDT)
To: Alessandro Vesely <vesely@tana.it>
Cc: dmarc@ietf.org
References: <DM5PR0601MB367115AD49513EAF3953716CF68B0@DM5PR0601MB3671.namprd06.prod.outlook.com> <18441e8d-cf87-053e-4957-7b9d6ea9690c@gmail.com> <ff98e267-8e7b-2015-cc1b-7061d04097d8@tana.it> <71b7426b-4619-fd50-4038-3418f3181b1d@gmail.com> <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <1f04f4fd-5c92-b61d-3ca1-e6ea954e33f7@gmail.com>
Date: Wed, 03 Jun 2020 10:27:52 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <2d1d4b31-ad19-db95-b32d-f89c914195a5@tana.it>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/06XqnX-cHVxc-KCDAGZ0xfwOvVs>
Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
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: Wed, 03 Jun 2020 17:28:00 -0000

On 6/3/2020 10:20 AM, Alessandro Vesely wrote:
> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote:
>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote:
>>> MUAs should be discouraged from displaying or using Author:, unless
>>> (verifiably) signed by a trusted domain or otherwise configured by the user.
>> Why?
> That avoids the dreaded back-to-square-one path that Brandon conjectured.  It
> prevents attacks based on this field, while maintaining the DMARC paradigm.

The barrier you specified sounds reasonable.  But it isn't.

Any signature put in place when the Author: field is created is likely 
broken by the time it gets to the recipient.  That's the entire problem 
that necessitates rewriting the From: field.

We do not require 'signatures' on Subject: or the Body or Date:. This is 
just one more field.

The concern about square one is misguided, apparently mostly because it 
continues the erroneous belief that the validation work is done for the 
end user, rather than the filtering engine. Besides that, it ignores the 
fact that authentication mechanisms are presumably still in place.

Users are tricked by the content of the message, not by the From: (or 
Author:) field.

On the other hand, a clean From: (or Author:) field enables consistent 
MUA organizing of messages.  Messing with the From: (or Author:) field 
by intermediaries defeats that.


d/

-- 

Dave Crocker
Brandenburg InternetWorking
bbiw.net