Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

Dave Crocker <dhc@dcrocker.net> Tue, 06 February 2024 01:51 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BE7C14F6B0 for <ietf-dkim@ietfa.amsl.com>; Mon, 5 Feb 2024 17:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=dcrocker.net
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 q7ZIlA8REd8F for <ietf-dkim@ietfa.amsl.com>; Mon, 5 Feb 2024 17:50:55 -0800 (PST)
Received: from snail.cherry.relay.mailchannels.net (snail.cherry.relay.mailchannels.net [23.83.223.170]) (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 44A04C14F6AB for <ietf-dkim@ietf.org>; Mon, 5 Feb 2024 17:50:54 -0800 (PST)
X-Sender-Id: hostingeremail|x-authuser|dhc@dcrocker.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DD7F4C2C16 for <ietf-dkim@ietf.org>; Tue, 6 Feb 2024 01:50:53 +0000 (UTC)
Received: from uk-fast-smtpout4.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 00811C37E8 for <ietf-dkim@ietf.org>; Tue, 6 Feb 2024 01:50:52 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1707184253; a=rsa-sha256; cv=none; b=ROo3EE2C5cd3jzP9YOM8wlSXIxs0vAMSmtyxM2dcP1omyYOL1q7CU5Ztso8XJ0J6KgpLdT Bw7mHusvyga5Ii7vBAxpdc0B/gWu2cEtk/gKxcJq0g2fjCn2/D3ZQC0ineJluUGt74V+EG dzk0NkilV5MM8ciLQ0cUBapr72x7JoLvGEel72fC/Omt7SH8SSLHtZ/pZZ/5Civ5goQsHB kzuBGAmWKnyA088CKLQT+yszdqpNI+kBada0iuyQT1Jw3s+MKu2FuZKQ5LmIkw6nc+cL3v bpxBYV6fbF8bYuuOoEf3Z2WZQJLbPKK42daJskX9a06XkRvXIz4YTlQ7xFo54g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1707184253; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:dkim-signature; bh=Ik8tNP8Q67wryjCKu2Co3SY+JyKbRYUFy5IKCHtwBtk=; b=w3bDZjcJl7yPW6Ks/VUIb3iLLmRVFFd7Y2gpigOQp3Y1EGHHGyt9tlA8nlkJyOSwqYnCN0 PkGxqpCy2tKC0HSwOjqGNSB1YHLgAFOd2OTEp+/UJB9rZlaPnLBosaJ8BXgwl6fmzTE2wp xY3CUPVcCV/5lzrbkMZzdCl53D1BnoCMOYdHHNXhxRlTN4KKsvwdYGPh2dXEQM40l8PGmc cME6sPEgDj/+2RkNXG1srDoe0H+UqpE77qXeFCvpy0LJsjGElRV/7Q9zld77INULAgGf0O zkPeaubLECSl6GSYq5o527z11KkdvXToLvoNnDRzS8gZfegbuDO2bZuKc7GzsQ==
ARC-Authentication-Results: i=1; rspamd-6bdc45795d-dp8cr; auth=pass smtp.auth=hostingeremail smtp.mailfrom=dhc@dcrocker.net
X-Sender-Id: hostingeremail|x-authuser|dhc@dcrocker.net
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authuser|dhc@dcrocker.net
X-MailChannels-Auth-Id: hostingeremail
X-Zesty-Slimy: 47d8020829aefa26_1707184253681_3556191706
X-MC-Loop-Signature: 1707184253680:1696918465
X-MC-Ingress-Time: 1707184253680
Received: from uk-fast-smtpout4.hostinger.io (uk-fast-smtpout4.hostinger.io [31.220.23.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.113.22.51 (trex/6.9.2); Tue, 06 Feb 2024 01:50:53 +0000
Content-Type: multipart/alternative; boundary="------------KsMS3hahBw5dwDSuqSKAEzfZ"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dcrocker.net; s=hostingermail-a; t=1707184249; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=Ik8tNP8Q67wryjCKu2Co3SY+JyKbRYUFy5IKCHtwBtk=; b=AMtp5h2AFKDK1grPuNbOkTzqTpTNy+TWp3suVgz8xU55SNuF8V7+2/LOKL1YwK8O3Qtmn5 D++6I3NljyFpxe0r522HJU0zgUa8aOYxKz4BIKVHCu8R3ithNmRNtls21gQtZ18gTwMlEq LfGCAESTqQMNY0EllXAUj0b6EisJwPfHEhG/W+4QvcZKpQsEyNCNJfp5zQNUAWpw3umQcl l3qGC/IR6t+X9A5y7pXY89y14Xvi9gC55Rd3iSMN1opO4XNis0ihHVR/vM/XeWHZF3Rdud FGxdOARHt9v/6pDa0anS6AurMlL8MWh+TFVArpt1mEajA4MZtyqx+xIj5csIDg==
Message-ID: <f648073f-7953-4b64-99f2-642d4eddf0a7@dcrocker.net>
Date: Mon, 05 Feb 2024 17:50:46 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Jim Fenton <fenton@bluepopcorn.net>
Cc: ietf-dkim@ietf.org
References: <20240119192026.DEDFF810437D@ary.qy> <20240120000053.FrDLzS4U@steffen%sdaoden.eu> <3f72e0c3-d245-16f7-57b2-831bfa53efbd@taugh.com> <4F161749-91D6-4E2D-AF70-89C5F172B971@isdg.net> <64f0cfd3-9d86-4d5e-b213-d0e53972c65a@tana.it> <af70d974-b2cb-4ac3-af9f-f0461238ebbb@isdg.net> <0cb52576-67af-4248-9866-5d2e2ef1adfd@tana.it> <8EA4F7EB-CBAF-4CBA-AD3B-03ECC8B05172@isdg.net> <012291f4-5098-4e6b-b9b9-a7e1fd681138@tana.it> <e59bbaa2-945c-4ed8-85b4-3a79ebc8bfbd@dcrocker.net> <20240205212412.Kq4PkTNC@steffen%sdaoden.eu> <1c0a74ed-9366-4e11-9604-eab211a17046@dcrocker.net> <7035E051-7B4D-4CE1-A923-7BE59FC76195@bluepopcorn.net> <33756c23-7ff5-4ce1-a326-270155da4125@bbiw.net> <3E7A38EF-4026-4943-8BC3-22516E3F1C56@bluepopcorn.net>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
In-Reply-To: <3E7A38EF-4026-4943-8BC3-22516E3F1C56@bluepopcorn.net>
X-CM-Envelope: MS4xfL73Bb0vvQORC2xSckww0UQnyys3tmftUfja+5rWrsMNoKE01MePL65SXdMP5Md5Ul7upzJ2ZoLe+00Unjqt2kJ5/Rb1IdqQEYXbjM+YPqxr6vOdH3Qd 0q2Yr1eLftrYs539j8nTfBWtEvZShyu0BRFI7VkG3UgyF9bZmmKEtxga2oyQyRogzVY/xUNPIhyIdlt3DClrPmoYE2m4slw38C4FwcvSAby9h67CqJSeI8EH
X-CM-Analysis: v=2.4 cv=RsPDLjmK c=1 sm=1 tr=0 ts=65c19079 a=f+oD5hTMMv8HtluUlp4ziA==:117 a=f+oD5hTMMv8HtluUlp4ziA==:17 a=-8J-CVF0aq-YtkYw:21 a=r77TgQKjGQsHNAKrUKIA:9 a=79AGnFNJAAAA:8 a=stR3rVVuAAAA:8 a=PW-cKIC9AAAA:8 a=47X5gBRpAAAA:8 a=aM5wZHYUAAAA:8 a=6ENAvOlSAAAA:8 a=AeJBNHyeAAAA:8 a=k7Ga1wGzAAAA:8 a=NNCETrXQHN1vRVOkf5QA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=q9ROd0MqrEkA:10 a=GF8P9PNQOvIA:10 a=8LfgHNaa6p4A:10 a=bqqTFMr8AAAA:8 a=QIdcO5Ytst1ulC_KAwUA:9 a=EnihVLdxGz1XvpEJ:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=zInEZSpGcAIF5GZ4Uyca:22 a=PDbfc8WnuiZXldMEPNTx:22 a=_V9axEqdFZVOrpBZZaM1:22 a=WxAA9rGfFfAdGKAkKs6L:22 a=qsqo9w1XZMnkHIPguJr7:22 a=ijMaxGghyylP-n2pFjDB:22 a=_8dWJSjk4SIQ3xhwCQ0d:22
X-AuthUser: dhc@dcrocker.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/uhGIX8760lvdC0vL2RGy_cM1YvA>
Subject: Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim/>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2024 01:51:00 -0000

On 2/5/2024 2:08 PM, Jim Fenton wrote:
> On 5 Feb 2024, at 14:02, Dave Crocker wrote:
>> On 2/5/2024 1:56 PM, Jim Fenton wrote:
>>> And you will also provide citations to refereed research about what you just asserted as well, yes?
>> Ahh, you want me to prove the negative. That's not exactly how these things go.
> You said that the URL lock symbol failed. Asking for research to back that up is not asking for you to prove the negative.


Ahh.  Defending by attacking.  Nice.

But actually, given what I said, yes it is being asked to prove the 
negative.

I said it's been a failure. Failure means that after many years, it has 
not been a success.  Were the symbol successful, we'd see reductions in 
user understanding, awareness and resistance abuse.

Do we have serious data that it has been?  If so, where is it? Do we 
even have an anecdotal sense of widespread utility?  I think not.

But wait.  There's more...

All of the following are strong indicators of failure:

    /"In our study, we asked a cross-section
    <https://techxplore.com/tags/cross+section/> of 528 web users
    <https://techxplore.com/tags/web+users/>, aged between 18 and 86
    years of age, a number of questions about the internet. Some 53% of
    them held a bachelor's degree or above and 22% had a college
    certificate, while the remainder had no further education. /

    /One of our questions was, "On the Google Chrome browser bar, do you
    know what the padlock icon represents/means?" /

    /Of the 463 who responded, 63% stated they knew, or thought they
    knew, what the padlock symbol on their web browser meant, but only
    7% gave the correct meaning."/

https://techxplore.com/news/2023-11-idea-padlock-icon-internet-browser.html

https://www.nextgov.com/cybersecurity/2019/06/fbi-warning-lock-icon-doesnt-mean-website-safe/157629/

    /'In an alert published Monday
    <https://www.ic3.gov/media/2019/190610.aspx>, the bureau’s Internet
    Crime Complaint Center, or IC3, warned that scammers are using the
    public’s trust in website certificates as part of phishing campaigns./

    /“The presence of ‘https’ and the lock icon are supposed to indicate
    the web traffic is encrypted and that visitors can share data
    safely,” the bureau wrote in the alert. “Unfortunately, cyber
    criminals are banking on the public’s trust of ‘https’ and the lock
    icon.” '/

https://theconversation.com/the-vast-majority-of-us-have-no-idea-what-the-padlock-icon-on-our-internet-browser-is-and-its-putting-us-at-risk-216581

https://www.sciencealert.com/theres-a-tiny-icon-on-your-screen-but-almost-nobody-knows-why

https://www.theverge.com/2023/5/3/23709498/google-chrome-lock-icon-web-browser-https-security-update-redesign

https://www.howtogeek.com/890033/google-chrome-is-ditching-the-lock-icon-for-websites/


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social