[Ietf-dkim] Re: DKIM with body length

[Hector Santos]

> On May 25, 2024, at 12:49 PM, John R Levine  wrote:
> 
> On Fri, 24 May 2024, Jon Callas wrote:
>>> blank lines.) Maybe you can tell it's from a list and the crud is
>>> benign, or maybe you can't and you should treat it as suspicious.
>> 
>> And yet, I didn't make up the word robustness, it's there in the spec as 
>> Dave quoted.
> 
> When I read the whole paragraph, the message I get is that l= is intended to 
> survive mailing lists but it has many problems so don't use it.  My 
> recollection is that for a few features like l=, most of us found them 
> useless, a few people really really wanted them, so that paragraph was a way 
> to get the document out the door.
> 
> Twenty years ago there was no DMARC* and the issue was that until DKIM became 
> more widely used, mail from dusty lists would have no signatures at all.  In 
> fact lists did start signing pretty quickly, list mail all has DKIM 
> reputation and that particular issue is moot.
> 
> I do not ever recall l= being an proposed as an invitation to recipient 
> systems to do surgery on incoming mail.  If anyone had ever suggested that, 
> I'm sure I'm not the only list manager who would have been sure to strip any 
> l= signatures to prevent downstream funny business.
> 
>> 1) It appears that the issue with l= is that implementers are not doing it 
>> correctly, ...
> 
> If there ever was a correct way to use l=, there sure isn't now.  But per 
> your next message we seem to agree on the outcome.

Yet, as shown, there are many implementations that support it for usage 
(outbound) and ignoring (inbound) per the consensus.   I did agree with the 
option and left it as option for sysops to enable/disable.   But I agree it was 
not an answer to restoring original verification and can be a loop hole.   

All the best,
Hector Santos



___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: [Dcrup] [standards] [Editorial Errata Reported] RFC8463 (7930)

[Hector Santos]

> 
> |Because that's not actually accurate, due to the inclusion of the digest
> |OID in the signature payload in the "single" primitive.
> 
> ...but the above says "two hashes".  But despite that.
> An Ed25519 sign operation alone creates three SHA-512 digests
> which are incorporated into several further calculations.  Whereas
> for RSA it is, to the best of my knowledge, crucial to let it pass
> over as few bytes as possible (for encryption as such i think
> OpenSSL will refuse to do so after a certain limit), for EC with
> its embedded digests it may be more expensive but even beneficial
> to push more data rounds onto the embedded digests.
> So maybe, and in hindsight to the RFC that i would try to publish
> in fall if i am allowed to and if the email giants still have not
> moved towards this RFC 8463, it might make sense to adjust the
> data-hash in that it may come from hash-alg or be included via
> sig-alg.
> 
> --steffen

I don’t wish to oversimplify here,  but I wonder if the confusion is with the 
idea that in order to support RFC8463, a complaint implementation would have to 
sign two DKIM signatures for backward compatibility.   One DKIM signature using 
SHA256 and a second signature using Ed25519. 

No one will support exclusively Ed25519 unless dealing with highly direct 1 to 
1 comm I/O with a permission-based system. In other words, supporting this 
crypto enhancement requires a high overhead of two signatures, The ignorant 
RFC8463 system (the majority) is not ready for this. One SHA256 signature is 
sufficient,  I would not Ed25519 provides smaller keys that are more supportive 
by DNS Zone Managers. 

All the best,
Hector Santos




___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Re: [Ietf-dkim] Testing a DKIM implementation

[Hector Santos]

On 3/22/2024 8:25 AM, David Harris wrote:

My thanks to Murray S. Kucherawy, who was most helpful in answering my
previous questions about specifics of RFC6376..

I now have my implementation complete: I was wondering if there is a
recommended way of testing it - for instance, a reference site that allows you
to send messages and then replies with information about the correctness of
your implementation, or an application that can generate signatures for data
you supply, showing its work product (the various hashes and canonicalized
forms) so you can compare it with your own.

Any pointers would be appreciated.

Thanks in advance for any assistance.


There are number of verifiers.   One such address is 
dkim-autoresp...@isdg.net will verify your DKIM signatures and apply 
DKIM Policies such as ADSP (deprecated), DMARC and report the result.


--
Hector Santos,
https://santronics.com
https://winserver.com






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Hector Santos]

Whoa!  I wondered about that!! Lock Icon was gone and it’s not a “switch” 
indication “options” icon.

You know, a good bit of the time is a programmer getting excited with a new UI 
API and switches to it!!  Imo, there was no need for that change,  Everything 
in the options was 100% about security and privacy related.  So what if the 
laymen didn’t know what it was. The default is set for unsecured 
communications. Focus on that, the secured defaults. The 10-20% experts that 
did know this intuitively with the lock icon was did not have an issue. 
Sometimes the first inclination is the best.  Go with your GUTS.  Always works 
in the long term.


All the best,
Hector Santos



> On Feb 5, 2024, at 8:50 PM, Dave Crocker  wrote:
> Om
> 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 
> <mailto:mast:@dcrocker@mastodon.social>___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned

[Hector Santos]

The "Report as Spam” button is always there.  They have normalized the practice 
for users to expect legitimate mail in spam boxes, thus causing more eyeballs 
around the junk. That is all spammers want.


https://www.wsj.com/articles/google-and-yahoo-are-cracking-down-on-inbox-spam-dont-expect-less-email-marketing-dd124c19
Google and Yahoo Are Cracking Down on Inbox Spam. Don’t Expect Less Email 
Marketing.
wsj.com


All the best,
Hector Santos



> On Feb 6, 2024, at 1:43 PM, John Levine  wrote:
> 
> It appears that Jim Fenton   said:
>> 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. I suspect there is research out there that backs up that 
>> statement, and I’m just
>> asking for the same amount of rigor that you are asking for.
> 
> In this case, Dave's right.  Here's a conference paper from Google saying 
> that only 11% of users
> understood what the lock meant.
> 
> https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/
> 
> The annual Usenix SOUPS conferences are full of papers about failed security 
> UI.  Here's this year's.
> Don't miss the one saying that Gmail's message origin indicator doesn't work, 
> 
> https://www.usenix.org/conference/soups2023/technical-sessions
> 
> R's,
> John
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Hector Santos]

On 2/5/2024 11:50 AM, Dave Crocker wrote:


(*) Lon ago, Knuth visited UCLA when I was there, and 'structured 
programming' was a hot topic.  He did a presentation to test a 
perspective that he later wrote up.  He observed that fully 
structured programs, without gotos, could sometimes make code 
/worse/.  He shows some code without any gotos that was correct but 
extremely difficult to read and understand.  Then he showed a 
version, with two loops -- one after the other -- and inside each 
was a goto into the other.  OMG.  But this code was clear, concise 
and easy to understand.


I recall an old corporate project SE coding guideline: usage of a GOTO 
LABEL was allowed if the LABEL is within the reader's page view, i.e. 
25 lines (using 25x80 terminal standards).


--
Hector Santos,
https://santronics.com
https://winserver.com



___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Hector Santos]

> On Feb 3, 2024, at 8:23 AM, Alessandro Vesely  wrote:
> 
> On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote:
>> Of course, the MUA is another issue.  What read order should be expected for 
>> Oversign headers?  Each MUA can be different although I would think streamed 
>> in data are naturally read sequentially and the first display headers found 
>> are used in the UI.
> 
> 
> Yeah, which is the opposite of DKIM specified order.


>>   Only To: is allowed to be a list.
> 
> 
> RFC 5322 specifies lists for From:, To:, Cc:, Bcc:, Reply-To:, Resent-From:, 
> Resent-To:, Resent-Cc: and Resent-Bcc:.


My comment was regarding the MUA and the order data is read. I wonder which 
MUAs will display a list for Display fields From: and Resent-*. If any.  Are 
all of these OverSign targets?  

if we go down this road, the recommendation might be to always sign all 
headers, including the missing, including ARC and trace headers and before 
signing, reorder specific headers to DKIM-ready MUA read-order standards, if 
any.

Are MUAs now doing verifications and filtering failures?  Or is it the backend, 
the host, the MDA, that is still generally responsible for doing the 
verification and mail filtering before passing it on to users?


All the best,
Hector Santos

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

[Hector Santos]

On 2/2/2024 12:03 AM, Murray S. Kucherawy wrote:

On Thu, Feb 1, 2024 at 10:03 AM John Levine  wrote:

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso
 wrote:
>
>> But i cannot read this from RFC 6376.
>
>Sections 2.8 and 3.4.4 don't answer this?

Not really.  They say what to do with CRLF but not with a lone
CR or lone LF.


Ah, I misunderstood the question.

I agree that by the time you're talking to a DKIM (or any) filter, I 
expect that this has been handled somehow. CRLF ends a line, 
anything before that is part of the line, and WSP is just a space or 
a tab.  Past that, garbage in, garbage out.




+1.   5322/5321 EOL is CRLF



--
Hector Santos,
https://santronics.com
https://winserver.com

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Hector Santos]

On 2/1/2024 6:38 AM, Alessandro Vesely wrote:

On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:

If I add this feature to wcDKIM, it can be introduced as:

[X] Enable DKIM Replay Protection


That'd be deceptive, as DKIM replay in Dave's sense won't be 
blocked, while there can be other effects on signature robustness.



First, thanks to your and Murray's input.

I need to review Dave's "DKIM Replay" concerns.   Legacy systems have 
many entry points to create, import/export methods, transformation, 
filling missing fields, etc. Overall, I considered the potential 
"Replay" concern was about taking an existing signed message (from a 
purported "trusted signer" ) but MUA display fields, namely, To: and 
Subject: are missing or not signed.  These can potentially be replayed 
with tampered To:, Subject fields and exported.  The multiple 
5322.From headers MUA concern was highlighted many moons ago.  Easily 
Addressed with incoming SMTP filters rejecting multi-From messages.




A better sentence could be:

[X] Prevent further additions of this field


"This" meaning there is a header selection to monitor?    See below


Note that some packages allow choices such as

[ ] Sign and oversign only if present in the message
[ ] Oversign only if already present in the h= list
[ ] Oversign anyway 


Given how our package offer the signing defaults:

UseRequiredHeadersOnly = 1   # optional, 1 - use 
RequireHeaders
RequiredHeaders    = 
From:To:Date:Message-Id:Organization:Subject:Received*:List-ID
SkipHeaders    = 
X-*:Authentication-Results:DKIM-Signature:DomainKey-Signature:Return-Path
StripHeaders   = # optional, headers 
stripped by resigners


Basically, as the message to be signed headers are read in, each are 
checked again the RequiredHeaders (when enabled).  If missing, the 
header is not signed.  The exception is From: which is always 
signed.   Signed headers are added to the "h=" fields.


So how about this, if I follow this, new namespace fields:

OversignHeader.To = # default blank
OversignHeader.Subject =  # default blank
.
.
OversignHeader.Field-Name=   # future oversign header

This allows an oversign header to be signed if missing.  If correct, 
easily to update the code.


Of course, the MUA is another issue.  What read order should be 
expected for Oversign headers?  Each MUA can be different although I 
would think streamed in data are naturally read sequentially and the 
first display headers found are used in the UI.  Only To: is allowed 
to be a list.



--
Hector Santos,
https://santronics.com
https://winserver.com



___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Hector Santos]

> On Jan 19, 2024, at 8:41 PM, John R Levine  wrote:
> 
> Manfred said:
>> (Seems like "seal"ing would be a better term than "oversign"ing.)
> 
> We've called it oversigning for a decade now.
> 

Interesting.  

First time I have come across the term (“oversign”)  and it appears to be a 
feature with several products in the market. But checking the RFC, unless I 
missed it, it’s not a RFC defined term.  Replay is the term used.

To me, the term connotes “redundant signing” beyond what is necessary or 
desired for a particular signing rule.   If I add this feature to wcDKIM, it 
can be introduced as:

[X] Enable DKIM Replay Protection

The F1 help will indicate the addition of headers, i.e.  To:, Subject:, etc. as 
empty field values are used to enforce the hashing binding of these potentially 
missing headers to the signature. If enabled, then these specific headers 
MUST be included in the list of headers to be signed and the headers MUST 
exist.  If not, the headers with empty values will be hash bound to the 
signature.

Is that “Oversigning?”

Perhaps. Imo, it is redundant header(s) signing when it may not be required for 
certain DKIM signing routes.  

What is most important is what it is suppose to help address - DKIM Replay 
hacks.

All the best,
Hector Santos




___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Hector Santos]

Agree with Mike regarding ARC.  Not a fan of adding more 5322 overhead for an 
isolated purpose,  but I want to further explore how ARC can save broken mail, 
or more specifically 1) a SMTP forward where SPF now fails at the next 
unexpected hop or 2) a LIST distribution DKIM 1st party signature failure 
occurs due to modified content. A resigner is present but not acknowledged in 
our current frame of authorization thought.

We have two integrated concepts:

1) Use ARC to resolve the broken integrity transition, or
2) Use DMARCBis “auth=“ proposal to resolve a broken SPF or DKIM.

—
HLS

> On Aug 4, 2023, at 2:41 PM, Michael Thomas  wrote:
> 
> 
> 
> On 8/4/23 11:31 AM, Tim Wicinski wrote:
>> 
>> Michael
>> 
>> Actually it appears  draft-chuang-replay-resistant-arc is listed in the 
>> charter (I had to check for myself). 
>> We can have the larger ARC discussion but I'll want to talk to Murray and 
>> Laura on that also.
> And what of the mailing list traversal? That clearly has nothing at all to do 
> with the current charter.
> 
> DKIM is a full internet standard. ARC is an experiment with no data given to 
> show that it does anything that DKIM can't. Any proposal should be written in 
> terms of modifications to DKIM itself, not some unproven experiment.
> 
> Mike
> 
>> 
>> tim
>> 
>> 
>> On Fri, Aug 4, 2023 at 2:27 PM Michael Thomas > > wrote:
>>> 
>>> On 8/4/23 11:12 AM, Wei Chuang wrote:
>>> > Hi all,
>>> > I just wanted to mention two proposals for tolerating mailing list 
>>> > modifications as suggested in person IETF-117. They both use ARC 
>>> > headers as infrastructure, but go about tolerating mailing list 
>>> > modifications in different ways.
>>> > 1) Disclose and reverse mailing list transforms so that we can 
>>> > authenticate those messages with the original DKIM signature: 
>>> > https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
>>> > 2) Replay-resistant-arc draft proposes authenticating a sender defined 
>>> > path from originating sender to receiver.  It also has the sender 
>>> > specify the intended recipient to prevent replay amplification.  It is 
>>> > insensitive to message body modifications: 
>>> > https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
>>> > Both approaches do not require trusting results in 
>>> > ARC-Authentication-Results which has been a concern.  Instead they 
>>> > provide signatures and values that a third party can independently and 
>>> > objectively verify.  Discussion of these drafts belong on the DKIM 
>>> > list (ietf-dkim@ietf.org ).  Also just 
>>> > mentioning I've heard there are 
>>> > other interesting related drafts.
>>> >
>>> What does this have to do with the current charter? ARC is off-topic and 
>>> should be banned by the chairs. That is especially true since DKIM is a 
>>> full internet standard and ARC is an experiment with no supporting data 
>>> to show that it's done what it claims.
>>> 
>>> Mike
>>> 
>>> ___
>>> Ietf-dkim mailing list
>>> Ietf-dkim@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/ietf-dkim
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DMARC's auth=dkim+spf tag

[Hector Santos]

> On Jul 3, 2023, at 10:06 AM, Barry Leiba  wrote:
> 
>> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay
>> belongs to the ietf-dkim list.  (In case, it could also be expressed outside
>> DMARC, for example by an additional DKIM tag.)
> 
> I do agree with this, yes.
> 

+1

There may be additional integrated protocol considerations for ESMTP, SPF and 
DKIM that may go beyond what DMARCbis is willing to consider.

—
HLS








___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] On the current state of DKIM and the replay problem

[Hector Santos]

> On Mar 28, 2023, at 1:36 PM, Michael Thomas  wrote:
> 
> Since the chair is threatening to ban me, I decided to write up my view of 
> things in a longer form.
> 
> https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html
> 
> This has some technical aspects and meta aspects. The meta aspects can be 
> addressed in the blog comments itself instead of here.
> 
> Mike

Mike, 

I asked ChatGPT 4.0 to summarize your extensive blog post for me.

Summary:

The blog post discusses concerns related to DMARC, ARC, and DKIM Replays in the 
context of email security and the working group's efforts to address these 
issues. The author expresses confusion and skepticism about the necessity and 
effectiveness of the proposed solutions.

Top concerns and conflicts:

1. Unclear motivations and politics behind DMARC: The author questions the 
reasons behind DMARC's creation and its differences from ADSP, as well as the 
intentions of the working group members involved.

2. ARC's purpose and necessity: The author doubts the need for ARC, which 
recreates DKIM and Authentication-Results with minor tweaks, and its ability to 
solve mailing list traversal problems.

3. DKIM Replay problem and lack of clear solutions: The blog post raises 
concerns about the lack of consensus on how to address the issue of DKIM 
Replays, as well as the opacity of mailbox providers' practices.

4. Insufficient information and secrecy: The author argues that the lack of 
transparency from mailbox providers and the closed nature of industry groups 
like M3AAWG hinder the working group's ability to develop effective solutions.

5. Ineffective proposed solutions: The blog post criticizes the solutions 
proposed so far, arguing that they do not seem practical or likely to
work.

6. Unclear definition of success: The author points out that there is no clear 
goal for the working group to achieve, as the spam issue is not a matter of 
absolutes but rather probabilities.

7. Passive-aggressive working group chairs: The author criticizes the behavior 
of the working group chairs, suggesting that they may have
their own agendas or be uninterested in finding solutions.

8. Doubtful effectiveness of the rechartered working group: The author believes 
that the working group's track record, combined with the lack
of available tools and knowledge within the IETF community, makes success 
unlikely.


—
HLS



___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Hector Santos]

> On Mar 26, 2023, at 1:11 PM, Michael Thomas  wrote:
> My contention is that documenting what has failed in the problem statement 
> saves time eventually in the solution space as you can reference it when 
> somebody brings it up as to why it doesn't work. It would be just a cut and 
> paste for (3) along with other discussion of what was also considered and 
> rejected. For (4) it gives a basis of what not to suggest.
> 
Michael,  first, I want to express my thanks and support your stance.

Thank you for expressing the thoughts of the silent majority. I have been 
IETF-style silenced here because of my strong DKIM Policy model position.  It 
has never changed.  And history only continues to prove my concerns correct.

The DKIM and Reputation modeling has been long dreamed, but to this day - we 
have nada.  

The closest thing we have us VBR, It make an Author Domain (ADID) and SDID 
(Signer Domain) association.  So does ATPS.

Since MARID, it has been about associations of two or more identities.

With SPF, an LMAP concept, it was an Return-Path Domain::IP association.

With ADSP is was an Author Domain (ADID) and Signer Domain (SDID) association 
but we could  only work out the 1st party association with ADID equal SDID.  
This is DMARC.

With ATPS, it proposed an 1st party ADID and 3rd party SDID association.  We 
can add this to DMARC.

But someone said it does not scale and we stopped  They said Reputation is 
better!!  No Dependency on ADID!  We have nothing since 2005!!!

—
Has


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

[Hector Santos]

> On Mar 26, 2023, at 6:13 AM, Murray S. Kucherawy  wrote:
> 
> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas  > wrote:
>> On 3/24/23 6:19 PM, Barry Leiba wrote:
>> > I don't agree with the premise.  I think what was tried and didn't
>> > work should be documented in the result that the working group comes
>> > out with, but not in the problem statement.
>> 
>> There isn't a place in the charter/milestones for that.
> 
> The charter identifies these possible outputs in some combination:
> 
> (1) a clear problem statement;


My understanding so far is this an ESP “Email Service Provider” only issue or a 
domain that allows for free sign-ups for email services using their domains. An 
ESP , i.e. example.esp, can be any size, high or low scale, it allows free 
sign-up service.

My understanding so far is the exploitation are free sign-up accounts using the 
domain to create a template message to some spammer box where the example.esp 
is signing the bound message.  The spammer then massages the message without 
damaging the signature and attacks downlink receivers who accepts the signer 
and/or always trust the example.esp domain.  The presumption is (imo erroneous) 
the receivers are using the same DKIM Reputation Lookup Server that example.esp 
is a member of and that these receivers are using the SDID (Signer Domain 
Identity) as input to a trust service there by bypassing spam security checks.

This is the classic “Batteries Required” syndrome that was predicted with the 
DKIM Reputation Model   With no standard, receivers do not have the tools so 
resolve this problem.

But ESP can do more control their users.   ESP can also make sure users can not 
create signed templates.

We can also finish the DKIM Policy Protocol and basically extend DMARC beyond 
its current limits.  A receiver can probably read a tag ‘-enabled.x’ that tell 
receivers to apply the signature expiration.

—
HLS


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Hector Santos]

+1.

ARC is not a solution, but it is a good part of the problem. It’s not hard to 
see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model 
in lieu of Reputation Modeling creating this issue.

Every issue we have today is nearly 100% because of the lob-sided efforts to 
impose a DKIM Reputation Model on receivers when it was predicted during MARID 
and into early DKIM that if we do this, we will have issues related to the 
"Batteries Required" Syndrome.

- No standard Reputation Protocol
- No single repository of GOOD vs BAD domains
- To be somewhat effective, Batteries Requires (paid 3rd party service)
- Exploiters attacking those without Batteries.

This is why the original DKIM Charter tried really hard to focus on 
Deterministic Protocols rather than Heuristic Protocols based on the Author 
Domain. The original DKIM Charter considered “Reputation Modeling” out of scope.

Now it is in scope and we are dealing with issues that can not be solved — not 
without addressing the DKIM Policy Model for 1st and 3rd party signers.

If the group effort is to be able to write a PS for DKIM + Reputation Modeling, 
we should highly note it was all perpetuated by our defocus of DKIM Policy 
Modeling and the lack of will to fix DMARC.


—
HLS

> On Mar 24, 2023, at 1:42 PM, Michael Thomas  wrote:
> 
> 
> 
> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:
>> 
>> 
>> Fine with me, it's far from a showstopper overall.  I just made the 
>> suggestion.
>> 
> This wg should be concerned with DKIM problems, not other wg problems and 
> especially for experimental rfc's of dubious value and complete mysteries as 
> to what they have to do with their actual charter.
> 
> Mike
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Welcome to the rechartered working group

[Hector Santos]

Took a moment to go over this purported problem with replays:

1.1.  The problem

   Since many domains (including those of bad actors) list DKIM records,
   receiving systems track the history of messages using a DKIM-based
   domain name, to formulate a reputation for the name, and then to
   classify incoming emails.  


The way this is phrased suggest it is a common practice for a receiving system 
to “track the history of messages using a DKIM-based domain name.”

I’m not doing any such thing nor is any installation of our package.  What 
domain(s) or package(s) are doing this? 

As I read more, I believe too much stake is put on reputation which causes a 
heighten concern for a self-created problem by an ESP.

While an ESP may be considered “High Value” as an enterprise, i.e. gmail.com, 
by no means, is the domain “reputation” is “good” as “high”.   I don’t consider 
any ESP domain having a level of good reputation purely based their domain 
name. 

I am leaning towards this is not a DKIM issue.  It’s an ESP issue.  They need 
to deal with the potentials of malicious users.

Since day one,  DKIM was about establishing a technical method to prove 
authentication by keeping message integrity intact.  When verification 
deviated, a point of failure and possible actions was considered using a DKIM 
Policy Add-on, not a Reputation Protocol add-on simply because there are none 
(standard method).   

Unfortunately we removed SSP (which was built into DKIM), separated as ADSP and 
replaced with very poor substitute DMARC  and we continue to have issues with 
3rd party signature models.

The concerns about ESP reputation replay abuse is because they have a 
proprietary DKIM domain-based method for reputation.   This can be addressed 
but it requires a greater adoption of a DKIM Policy Protocol that is above and 
beyond what DMARC offers with its limited concepts and crippling alignment 
restraints.

In short, DKIM is fine.  Only a system using a proprietary reputation model 
based on its ESP domain has a higher replay problem. Systems that do not use a 
reputation model do not have this problem.

But, via POLICY if the domain using reputation wishes a verifier to put more 
restrictions on a received signed domain, i.e.  enforce `x=` expiration tag, I 
am all for it.

Thanks

Hector Santos CEO/CTO
Santronics Software, Inc.

 

> On Mar 7, 2023, at 7:09 AM, Laura Atkins  wrote:
> 
> All
> 
> The DKIM working group is now active again (thanks Murray!).  The chairs 
> wanted to send out a short note to welcome everyone and talk about our next 
> steps.
> 
> Our first deadline is next month - to get a consensus problem statement 
> submitted on the IETF data tracker at https://datatracker.ietf.org/group/dkim/
> 
> There is a current problem statement at 
> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please 
> take a moment to read through it and provide feedback. This chair thinks we 
> should not be providing solutions in the problem statement. We should be 
> primarily describing what the issue is and why we think the issue is with the 
> protocol. We will deal with solutions in the actual document. 
> 
> There was also a DKIM replay session at the most recent M3AAWG meeting. As I 
> understand it, they’re working on a BCP in parallel with the IETF. Many folks 
> are active in both groups. 
> 
> Due to M3AAWG privacy requirements, we are constrained in what we can share 
> from the meeting itself. However, if you were here and were on the panel or 
> part of the discussions, feel free to share with us some of your thoughts on 
> the problem, possible solutions and what your organizations have done to 
> address the issue. 
> 
> One of the panel members has shared the following from what he said at the 
> session:
> 
> * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay.
> * There may only be a best practices solution, and not a protocol solution.
> * DKIM has since the beginning kept itself completely separate from the 
> message transport.  Several of the proposed solutions (including mine) take 
> leaps of varying sizes into the realm of DKIM knowing something about the 
> transport; the lightweight ones connect the message to the envelope somehow, 
> and the more heavyweight ones mean DKIM filters have to learn about MXes and 
> whatnot.  We have to be absolutely certain that we want to break that wall if 
> we go this way, because once we do, there will be no turning back.
> 
> There was also a DKIM replay session at the most recent M3AAWG meeting. As I 
> understand it, they’re working on a BCP in parallel with the IETF. Many folks 
> are active in both groups. 
> 
> Due to M3AAWG privacy requirements, we are constrained in what we can share 
> from the meeting itself. However, if you were here and were on the 

Re: [Ietf-dkim] DKIM update - header tag

[Hector Santos]

-1.  The v= tag description is accurate.

There is no current DKIM design expectation for any other string value.  The 
current spec is `v=DKIM1`.  Any software writing `v=DKIM1.0` is technically 
“broken” and should not be encourage to exist or perpetuate.

IOW, software should not process the record if it’s not literally `v=DKIM1` and 
if the `v=` tag is missing, the default is `v=DKIM1`.

If software want to consider preparing for the future with different v= tag 
string values describing an extended DKIM specification, it is always possible 
to have this. But for the current spec and standard, `v=DKIM1` is the only 
expectation,  not `v=DKIM1.0` — there is no spec for this and the current spec 
is clear DKIM1 and DKIM1.0 are not the same,

Thanks

—
HLS


> On Mar 10, 2023, at 1:46 PM, Jan Dušátko  
> wrote:
> 
> Dear,
> I got recommendation to propose changes in that mailing group.
> My work depend on appropriate protection of our brand, however this tasks 
> require also management of records required for that protection. We have huge 
> problem with identification of selector records required by DKIM and also 
> this make for us problem with compatibility. We would like to strongly follow 
> RFCs, but sometimes v=DKIM1 tag are resolved like issue as well as sometime 
> missing of that tag do the same. This is a reason, why I would like to 
> propose mitigation of problem, caused by word RECOMMENDED in standard RFC 
> 6376:
> 
>v= Version of the DKIM key record (plain-text; RECOMMENDED, default
>   is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
>   (without the quotes).  This tag MUST be the first tag in the
>   record.  Records beginning with a "v=" tag with any other value
>   MUST be discarded.  Note that Verifiers must do a string
>   comparison on this value; for example, "DKIM1" is not the same as
>   "DKIM1.0".
> 
> I would like to recommend change work RECOMMENDED to MANDATORY, where whole 
> article be after change
> 
>v= Version of the DKIM key record (plain-text; MANDATORY, default
>   is "DKIM1").  If specified, this tag MUST be set to "DKIM1"
>   (without the quotes).  This tag MUST be the first tag in the
>   record and this tag must exist.  Records beginning with
>   a "v=" tag with any other valueMUST be discarded.  Note that
>   Verifiers must do a string comparison on this value; for
>   example, "DKIM1" is not the same as "DKIM1.0".
> 
> 
> 

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Hector Santos]

> On Nov 20, 2022, at 6:01 PM, Murray S. Kucherawy  wrote:
> 
> 
> 
> On Sun, Nov 20, 2022, 11:08 Dave Crocker  > wrote:
>> Seriously.  DKIM is intended as a transit-time mechanism.  When delivery 
>> occurs, transit is done.  So DKIM has done its job and can (safely?) be 
>> removed.
> 
> 
> One of the informational RFCs the original working group produced discussed 
> this. A reason (maybe the reason) the envelope was not included in the signed 
> content was so that the signature could survive without an envelope, meaning 
> it could be retrieved from a mailbox and re-verified.
> 
> I don't know, though, if anyone does this regularly, but it's been shown to 
> be useful in some circumstances. 


My input would be since UUCP days, the importer stripped the “From 
return-address“ header (note no colon) once the final destination was 
determined (local user existed, bounce was no longer necessary). 

With SMTP, this evolved to a "Return-Path:”  header and the same plug and play 
stripping action occurred.  It is the reason the MUA could never rely on the 
“From “ or “Return-Path:” header existing when the mail was picked up, and why 
DKIM doe not recommend hash binding the Return-Path header to the signature. 

Side note: early mail systems had a RFC822 to Internal, Proprietary fixed 
header structure mail format transformations, only the minimal headers were 
read like;

From
To
Subject:
Date:

And only for replies:

Reply-to:

In short, when the MDA is reached,  nothing else matters and all else is 
overhead.

With the bigger ESPs now beginning to honor strong SPF and/or DKIM Policy 
protocol models, to resolve the many indirect path mail issues, the 
Receiver/Router needs to be fully aware of the incoming SPF protected and/or 
DKIM-signed message w/o a policy wrapper, i.e. DMARC.  Authorized modifications 
are needed which may include removing/stripping overhead headers that attempt 
to keep mail path processing change history and be a problem at the ESP.  

The Authorized mail processor/router that has one goal - properly deliver the 
mail to the MDA or make it available for pick up (pop) or reading (imap, web) - 
Different MUAs.



—
HLS___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Hector Santos]

> On Nov 11, 2022, at 11:46 AM, Barry Leiba  wrote:
> 
> Indeed...
> The issue here is this:
> 
> 1. I get a (free) account on free-email.com.

Ok 

> 2. I send myself email from my account to my account.  Of course,
> free-email signs it, because it's sent from me to me: why would it
> not?

The wcSMTP router logic will not sign this path because it never reaches the 
remote target outbound queue where it may be signed.  

The router will export a message that targets a locally-hosted domain but it 
goes into the Inbound Import Queue rather than the Remote target outbound 
queue.  I have debated the signing the Export->Local-Queue->Import mail. It is 
a matter of moving the location of wcDKIM signer which is now at the router 
outbound logic.


> 3. I take that signed message and cart it over somewhere else, sending
> it out to 10,000,000 recipients through somewhere else's
> infrastructure.  It's legitimately signed by free-email.com.

Ok

> 4. Of course, it fails SPF validation.  But DKIM verifies and is
> aligned to spam...@free-email.com, because there you go.
> 
> That's the attack.  It's happening all the time.  If between 1 and 2
> we could use x= to cause the signature to time out, we'd be OK.n


For failed SPF validation, I believe we need to honor the handling expected by 
the domain owner, first and foremost.  Meaning Exclusive, Strong policies 
should always be honored.  The weak and partial/soft policies is what has added 
handling unknowns (and unfortunately, we have not focused on leveraging the 
LOOKUP opportunities to extend policies).

> The trouble is that we have to make x= broad enough to deal with
> legitimate delays.  And during that legitimate time, it's trivial for
> a spammer to send out millions of spam messages.  Crap.  So x= doesn't
> help.

I had a 2006 draft to deal with expiration for time-shifted, time delayed 
verification.

Partial DKIM Verifier Support using a DKIM-Received Trace Header
https://datatracker.ietf.org/doc/html/draft-santos-dkim-rcvd-00

I have to review it to see if it can apply here in some manner 16 yrs later.

> 
> We have to look at other options.  We thought of this when we designed
> DKIM, but couldn't come up with anything that would work.  

> We have new
> experience since then, and we want to look at alternatives, and decide
> whether priorities have changed, use cases, have changed, and so on.
> 
> It's entirely possible that we still can't fix it without breaking use
> cases that we're not willing to break.  But we have to try.


I have always been a strong advocate for extended policies for what I believe 
is the new “normal’ for SMTP receiver lookups.  For the most part, related to 
SPF/DKIM/DMARC, we have today lookups:

5321: SPF
5322: DKIM, DMARC

We can leverage the archived PRA/SUBMITTER protocol.

SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail 
Message
https://www.rfc-editor.org/rfc/rfc4405
Purported Responsible Address in E-Mail Messages
https://www.rfc-editor.org/rfc/rfc4407

which passes then 5322 PRA to 5321 via the SUBMITTER ESMTP extension:

MAIL FROM: SUBMITTER=PRA

The PRA is typically the 5322.FROM

This gives ESMTP an optimizer and heads up for the transaction to expected 
DMARC domain handling policy prior to transferring the DATA payload.

ESMTP receivers who enables RFC4405 will immediately see it being used by 
compliant ESMTP senders.

We have used it for SPF lookups over the years.


—
HLS___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

[Hector Santos]

We need to update DMARC or any other DKIM Policy proposal to seriously 
consider  3rd party signature Authorization methods.


We have wasted so much time avoiding it. Sure, it may not apply to 
all, but neither does DMARC and the push to embed a "half-baked" DMARC 
into our mail network has created a market of kludges and new security 
problems with the endorsement of the horrible RFC5322.From rewriting 
and the creation of a super complex, solve nothing, ARC concept.


The DKIM Policy needs additional tags, call it "aim=" if you like, 
thats publishes and publicly exposes the following ideas:


1) Look, I really mean it, p=reject means NO rewriting. Reject!!

2) Eh, we are flexible, please allow following domains; ietf.org,
   resign our mail. If you see "ATPS=1" that means we support
   3rd party signatures from specific and exclusive domains.

3) Please do not bypass 1 and 2 and perform a RFC5322.From destruction
   and rewrite violating our published policy and the intent of having
   DKIM Policy for exclusive mail operations. However, if you see a
   "rewrite=1" tag, then we don't mind if you rewrite the RFC5322.From
   field IFF the resigner has an exclusive policy.

Simple!

Nothing will satisfy everyone. Not DMARC or even a ATPS or TPA or 
even the DKIM Conditional Signature draft proposal.


But we need to offer it to the market to see how it will work.  It has 
already been proven that it
works.  My package does not allow restrictive domains to sign up to 
mailing lists, not can existing subscribers can post into the list. It 
becomes an Read-Only list for them.  I am not going to Rewrite.  I 
want to sleep at night.  But if ATPS or something like is supported, I 
am extremely confident it will give DMARC an immediate security boost.


I am still around here because I have a strong feeling someone more 
important than me, Maybe Valimail or some other, maybe even google, 
will eventually get the "Ah Ha" and say "hmmm, there might be 
something here, let's explore it.  It may not work for all domains, 
but I see where it can have it place with other domains."  If these 
companies, who have such a high investment and product dependency on 
DMARC as a business, I have been scratching my head why their Project 
and/or Product R&D guy is not exploring ATPS which exist today.


Those wishing to explore ATPS, use this wizard and simulator:

https://secure.winserver.com/public/wcDMARC


--
HLS


On 5/11/2020 1:21 PM, Alessandro Vesely wrote:

Hi all,

consider the famous incipit:

DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name [RFC1034] with the message [RFC5322], which
they are authorized to use.

The question is, what responsibility is being claimed?  Some sites allow
authenticated users to use any From:, but are able to find out who the actual
author was, if needed.  Other sites only sign if the From: matches the actual
user, or at least its domain part.  Still others just sign everything.

Discussions about what kind of assurance would a signature imply are rather
frequent.  At least, specifying an aim= tag should shred some light on the
various possibilities.

Tagging keys with aim= would allow senders to choose an appropriate selector
under different circumstances.  Some mail sites use different sending IP
addresses to meet a similar purpose.  Others use different domain names, opaque
chunks of base64 data, or X-Google-DKIM-Signatures.  An aim= would serve a
similar purpose in a more open manner, introducing yet another means to discern
among different mail flows.

Comments?





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Thinking About DKIM and Surveillance

[Hector Santos]

Thanks jon for loading my plate! :)  I plan to finish reading the 
paper later today. Need to recall past discussions and how the paper 
relates.  But with initial reading, it made me recall the proposal I 
wrote in 2006:


https://tools.ietf.org/html/draft-santos-dkim-rcvd-00

related to potential delayed verification timing problems with expired 
and revoked keys. It served as a partial DKIM support as a migration 
method for MDAs who may not yet implemented DKIM verification. Back 
then, deployment was still low.  Basically, a "DKIM-Received:" header 
would added by the MDA.


  DKIM-Received:
   rt=;# Current time msg was received.
   sd=; # Selector DNS record Data.
   [vt=;]  # Current time msg was validated.


--
HLS


On 10/2/2019 3:29 PM, Jon Callas wrote:

I know that I've written about this before, so please bear with me a bit. A 
continuing concern of mine is the way that DKIM contributes to overall 
surveillance smog that the Internet has.

When we designed DKIM, this was something we considered; it was a concern. It 
wasn't so big a concern that we thought it should derail DKIM, and it wasn't 
even a concern when it was taken over by the IETF. Nonetheless, it was an 
issue, is an issue, and becomes a bigger issue nearly every day. The most 
notorious failure here is the Podesta email dump, where the stolen emails were 
verified against the DKIM signatures. This is precisely what we didn't want to 
happen -- that DKIM was used for things beyond fighting inauthentic emails. We 
ought to do something, the question is what.

When I think about how to reduce the tracking and surveillance issues, the 
solution space includes: (1) Better management of the keys (e.g. lifecycle 
management of some sort); (2) Better management of the emails (e.g. strip out 
surveillance-friendly headers in an MDA between the MTA and MUA -- think 
procmail filter that removes information leaks); (3) Better crypto. If I wave 
my magic wand and can cause software to appear and be deployed, I'd do them 
all. None of them are perfect. A crawler that would collect all DKIM keys would 
blunt the benefits of better key management; building and deploying better 
header handling is a huge task; better crypto needs an addendum to the DKIM 
standard.

Nonetheless, I recently came across an interesting article, "KeyForge: Mitigating Email Breaches 
with Forward-Forgeable Signatures". It's on the IACR eprint archive at 
. I think that everyone here should look at it. The TL;DR is 
that they have a signing mechanism that blunts attributable signatures and introduces some interesting 
new concepts. They call it, "Delayed universal forgeability." Yes, that's vague, and it's my 
point; consider that an advert for the paper. It's an interesting way to look at better crypto that 
allows for spam-fighting without open-ended tracking.

I don't know that their solution is the answer, but I do know that it's asking 
the right questions. In 2005-7, we were concerned about surveillance smog, but 
we didn't have a good answer (or even consensus, but this was pre-Snowden). The 
stated answer of the day was proper key management of keys, but it's not clear 
that anyone has ever deleted a DKIM key out of DNS. (Okay, I'm exaggerating for 
effect.) They have very good comments about that; I'm not sure I agree, but I 
really like what they're saying. We also briefly considered some sort of ring 
or group signature to blunt attribution. That a mediocre mitigation at best, 
and one of our core goals was to boil the crypto down to essentials, using bare 
keys rather than certs or any other uniforms for the keys. It's DKIM, not DCIM.

I think their signatures take that *intent* -- a mix of math and operation -- 
and creates something really worth considering. Even if it's not the answer, 
the questions that we punted on in 2005 are vital for 2020 and beyond.

Thus, any discussion of it is good. I really liked it. Please read it.

Jon




___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

[Hector Santos]

On 10/24/2018 4:53 PM, Дилян Палаузов wrote:

PS:

Please describe the handling, of the above message by the MLM, if the
original message contained in addition
   DKIM-Signature: v=1; d=isdg.net; r=y; …

... or something different than r=y, that permits finding faulty DKIM
implementations.


Our DKIM implementation does not support this "r=y" tag.  In general, 
per DKIM specification, all unknown DKIM-signature tags are ignored.



<<< 554 REJECTED BY SYSTEM POLICY FILTER
Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT


Off hand, it appears your IP address was filtered by a Geo IP Location 
database.  This is done immediately at the connection level so we have 
limited SMTP session logs to look at.


I'm contacting you off list.

--
HLS


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] [dmarc-ietf] DKIM-Signature: r=y and MLM

[Hector Santos]

On 10/24/2018 5:18 PM, Kurt Andersen wrote:


On Mon, Oct 15, 2018 at 7:30 AM Hector Santos

What it should do is:

1) It should use a 1st party signature using d=dmarc.ietf.org
   to  match the new author domain dmarc.ietf.org

2) It should has hash bind the X-Original-From header to the
   signature.  Since DKIM recommends not to bind "X-" headers,
   a non "X-" header should be used, i.e. "Original-From:".  This
   means adding the header to the 'h=" field to avoid potential
   mail resend exploits using different unprotected Original-from:
   fields.

3) and finally, the dmarc.ietf.org domain should have its own
   DMARC p=reject policy to effectively replace the one it
   circumvented with the submission.

I don't understand why it is necessarily a bad thing to fall back to
the org domain (ietf.org <http://ietf.org>) as this example shows.


Because DKIM policy security was lost with the rewrite transaction.

Since the list agent took responsibility by performing a rewrite on a 
protected domain, it is reasonable to assume it would can restore the 
protection using its own secured list agent domain.  Without it, it 
leaves a security hole with the unprotected "X-Original-From" which it 
does not hash bind to the new signature.



I also don't understand how your suggestion would work to handle a
mixture of restrictive policies (some quarantine, some reject) with a
single _dmarc.dmarc.ietf.org <http://dmarc.dmarc.ietf.org> record
unless there is some trick DNS responder magic going on (and that
won't work well for cached responses anyway).


If I follow your comment, the specific rewrite list agent domain can 
have its own strong p=reject or quarantine.  I don't see that as a 
problem.  It would not matter what the original author domain 
restrictive policy was. It doesn't have to match.


The original domain was protected with a strong  policy. The MLM 
rather than reject the submission, ignored the policy and rewrote the 
5322.From. It does this only for p=reject policies. I have not check 
if it does it for p=quarantine.   The rewrite should be done with a 
strong policy of its own to restore the original submission and author 
domain protection. The should also be a new first party signature 
(aligned).  At a minimum, the distributed message should bind the the 
altered header so that replays can be avoided.


--
HLS


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

[Hector Santos]

On 10/10/2018 5:11 AM, Дилян Палаузов wrote:

Hello,

no feedbach means either everyboby agrees, nobody understands, or
nobody cares.


Generally, a bit of everything.

I'm providing some comments because I am currently updating my DKIM 
ADSP/ATPS/DMARC implementation and need to take into account the MLM 
rewrite issue.



I suggested introducing
* fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3
] for sending reports on failed DKIM-Signatures, only when they align,
and
* introducing r=a in DKIM-Signature [
https://tools.ietf.org/html/rfc6651#section-3.2] that only sends
reports, when From: aligns.

This way, once an email is intenionally modifed, the modifying software
is aware that DMARC will trigger and rewrite From: so no distracting
reports will be sent.


I don't think we need a new DKIM-BASE DKIM-signature tag for what you 
want.  This all starts with DKIM Policy (ADSP/DMARC) restrictive 
policies and receivers finally honoring them.  This could be better 
done as a DMARC tag extension where it provides the MLM more DMARC 
mail handling information.


For example, new DMARC tag extensions "rewrite=" and "fo="

  rewrite=no default, rewriting SHOULD be avoided.
  rewrite=allow  allow rewriting by domain with a p=none or no policy
  rewrite=strict allow rewriting by domain with a p=reject|quarantine 
policy


  fo=da  send reports when rewriting is done

Keep in mind that not every system will send reports.  It is 
considered a high overhead with a high redundancy.  Our implementation 
does not generate reports.  Reporting adds a high barrier and 
technical implementation requirement.  Reporting should be optional 
for implementation.


Also keep in mind that the idea of "Rewriting" is not a "standard" 
concept.  It is actually a long time mail engineering taboo to be 
destroying the originating author field for any mail platform, 
including RFC5322. Its a very sensitive design idea. Our MLM package 
does not rewrite.


However, I am considering it now as a means to resolve the problem of 
errant DMARC/ADSP domains submitting public mailings using restrictive 
policies.   I personally believe the DMARC/ADSP receiver can implement 
ATPS "Authorized Third-Party Signers" (RFC6541) but that didn't gain 
traction, so rewrite appears to be the only recourse.With more 
receivers now honoring the policies, it can cause a major havoc in a 
list subscription group.


Since there are more MLM systems performing DMARC-based rewrites, I 
believe a better way to deal with this is for the MLM to reject the 
restrictive domain submission with an email response:


   "Sorry, your submission was prohibited due to a protected domain
restrictive DMARC|ADSP policy."

In fact, the MLM should stop all new subscriptions from domains using 
a restrictive policy.


The rewrite should be the last thing to consider, and if it does 
rewrite, it should replace the original author domain strong policy 
with its own strong policy.


For example, the ietf.org mailing list has begun to rewrite and it 
replaces the 5322.From with a dmarc.ietf.org domain, adds a new 
X-Original-From header and resigns the message using an ietf.org 
signer domain:


  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; 
s=ietf1;

 t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=;
 h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe:
 List-Archive:List-Post:List-Help:List-Subscribe:From;
 b=.
   X-Original-From: Hector Santos 
   From: Hector Santos 

What it should do is:

  1) It should use a 1st party signature using d=dmarc.ietf.org to
 match the new author domain dmarc.ietf.org.

  2) It should has hash bind the X-Original-From header to the
 signature.  Since DKIM recommends not to bind "X-" headers,
 a non "X-" header should be used, i.e. "Original-From:".  This
 means adding the header to the 'h=" field to avoid potential
 mail resend exploits using different unprotected Original-from:
 fields.

  3) and finally, the dmarc.ietf.org domain should have its own
 DMARC p=reject policy to effectively replace the one it
 circumvented with the submission.

With these measures, the original author domain will still be 
protected with a DMARC policy when the MLM rewrites.


That's my idea of a better approach to it as oppose to a blind, 
unprotected rewrite.



I am looking for a way to get reports only when somebody
unintentionally modifies an email.  The reason for this is
to have a system without unexplainable  failures that makes it
easy to fix broken DKIM signing/validating software.


Remember, not all systems will send a report.   I personally think a 
MLM should be playing an more active role to protect against DMARC -- 
who can subscribe, who can submit mail.  If the domain is restrictive, 
it i

[Ietf-dkim] Test Msg to ietf-dk...@ietf.org

[Hector Santos]

Ignore

--
HLS


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim