[Ietf-dkim] Re: DKIM with body length

[Steve Atkins]

> On 19 May 2024, at 17:32, Jim Fenton  wrote:
> 
> [adding the mailmaint mailing list]
> 
> 
> On 19 May 2024, at 9:26, Wei Chuang wrote:
> 
>> Hi DKIM folks,
>> As many of you know there was a DKIM security vulnerability disclosure
>> Friday around the signature header body length tag "l=". 
> 
> Do people really think that senders that are ignoring Sec. 8.2 of RFC 6376 
> are going to pay attention to a separate RFC that updates that RFC?

+1. Senders, no.

But there are already major mail receivers who treat any DKIM signature 
containing l= to be invalid.

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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Steve Atkins]

> On 30 Aug 2023, at 09:21, Alessandro Vesely  wrote:
> 
> On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote:
>>> On 30 Aug 2023, at 03:38, Grant Taylor 
>>>  wrote:
>>> On 8/29/23 3:15 PM, Steve Atkins wrote:
>>>> Any attempt by senders to filter outbound emails based solely on content 
>>>> is going to have a lot of false negatives and positives, wherever you 
>>>> decide to draw the line.
>>> I find the idea of using different, probably less stringent, filtering on 
>>> outbound than on inbound to be hypocritical.
>> You have much more data for inbound email, and access to a much wider range 
>> of reactions. That’s not “hypocritical”.
>> The only information a sender has that a receiver doesn’t is a broader view 
>> of who the recipients of messages being sent are - and that’s exactly the 
>> information that DKIM replay hides from the sender.
> 
> 
> Large sites should exchange reputation information on each other's accounts. 
> Murray already proposed a standard for doing so.

That doesn’t seem like something that would have any effect on someone sending 
a single message to themselves, which is the perspective a sender is likely to 
have of a DKIM replay.

Cheers,
  Steve

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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Steve Atkins]

> On 30 Aug 2023, at 06:35, Murray S. Kucherawy  wrote:
>> 
> 
> This also presumes that operators currently develop reputation based on (d=, 
> s=) pairs.  Is that so?  I thought it was mostly just the d= that matters.

That some major consumer mailbox providers use s= to track reputation is one of 
the reasons nobody wants to rotate their keys.

I’m not sure whether that’s still true but I wouldn’t want to do anything that 
would dissuade people from doing sensible key management still further.

Cheers,
  Steve


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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Steve Atkins]

Sent from my iPhone

> On 30 Aug 2023, at 03:38, Grant Taylor 
>  wrote:
> 
> On 8/29/23 3:15 PM, Steve Atkins wrote:
>> Any attempt by senders to filter outbound emails based solely on content is 
>> going to have a lot of false negatives and positives, wherever you decide to 
>> draw the line.
> 
> I find the idea of using different, probably less stringent, filtering on 
> outbound than on inbound to be hypocritical.

You have much more data for inbound email, and access to a much wider range of 
reactions. That’s not “hypocritical”.

The only information a sender has that a receiver doesn’t is a broader view of 
who the recipients of messages being sent are - and that’s exactly the 
information that DKIM replay hides from the sender.

> 
> I find it tantamount to someone saying they only accept the most pristine 
> message while sending less pristine, and sometimes really tarnished, email.
> 
> Sure, there are some differences, e.g. lack of user preferences.
> 
> Why the asymmetry?
> 
> Why not apply the same filtering for outbound messages as applied to inbound 
> messages?

Because they’re quite different environments. 

> 
>> Inbound content-based filtering is much easier to get right - not least 
>> because the fallback is “just deliver it to the spam folder” - and we’re not 
>> great at that.
> 
> I guess I'm coming from a different place.  I always was more worried about 
> what I send and not upsetting the rest of the Internet than I am about what I 
> accept in.

That’s not the issue. It’s much easier to filter inbound mail accurately than 
it is outbound mail. And we’re not great at filtering inbound mail.

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

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Steve Atkins]

Sent from my iPhone

> On 29 Aug 2023, at 20:54, Dave Crocker  wrote:
> 
> On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote:
>> For (1), I presume the outbound site did not make a quality assessment that 
>> identified the message as "likely to be replayed".  Does this reduce to the 
>> "don't sign spam" argument?
> 
> I have no idea what the current levels of outbound filtering are, among major 
> platforms.  If it ain't already very high, yeah, seems like it should be and 
> that this is an added incentive why.

Many, many people sign up to receive content that is, by any objective 
content-filtering standard, as spammy as an incredibly spammy thing.

Seriously, people sign up for things you would not believe.

Any attempt by senders to filter outbound emails based solely on content is 
going to have a lot of false negatives and positives, wherever you decide to 
draw the line.

Inbound content-based filtering is much easier to get right - not least because 
the fallback is “just deliver it to the spam folder” - and we’re not great at 
that.

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

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Steve Atkins]

> On 16 May 2023, at 15:16, Steve Atkins  wrote:
> 
> 
> 
>> On 16 May 2023, at 15:00, Jan Dušátko  
>> wrote:
>> 
>> Hi,
>> I would like to ask how you feel about the possibility of changing the 
>> conditions for DKIM keys stored in DNS. Best in some future RFC release 
>> about DKIM itself. I have a practical experience during review and cleaning 
>> of thousands of domain, which is exhausting. And discussion about that keys 
>> also with 3rd party is sometimes hard. In situation that you would like to 
>> discuss that, I can provide kind of examples.

(hit send too soon).

The historical reason for v=DKIM1 not being mandatory, AIUI, is backwards 
compatibility with DomainKeys keys. There are still people out there signing 
with DomainKeys, and there are still people using DomainKeys public keys to 
sign with DKIM.

While it would be nice for it to be used the only way to require it would be to 
make any mail signed with a public key without v=DKIM1 fail it’s DKIM 
signature. That would cause a lot of legitimate, signed mail to suddenly be 
unsigned, and that’s not going to happen.

You can mechanically recognize TXT records as potentially valid DKIM keys, even 
if they’re not published under the _domainkey zone, by looking for a p= field 
that is either empty or contains a base64 encoded value that’s a valid rsa key 
(or other type as defined by the k= field). If it has that then it’s usable as 
a DKIM or DomainKeys key.

Cheers,
  Steve

>> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and if 
>> this tag is used, it must be the first. Unlike, for example, SPF and DMARC, 
>> this is not a REQUIRED (MANDATORY) record. In case of an attempt to identify 
>> DKIM records, then there is a situation where it is not possible to 
>> determine which records are DKIM keys. Often, these keys are in other places 
>> where they allow to create CNAME to the expected location of the selector. 
>> These locations may be application dependent or may be with third parties 
>> configuration. From my perspective, MANDATORY record "v=DKIM1;" could help 
>> to identify DKIM keys much easily.
> 
> A DKIM key will only ever be found in DNS under a name of the form 
> ._domainkey.. If you find a TXT record under a name 
> like that it’s either a valid domain key record, or it’s invalid. No other 
> sort of TXT
> record will live there. See section 3.6.2.1 of RFC 6376.
> 
> If you publish wildcard TXT records then you may end up inadvertently 
> publishing other TXT records underneath the _domainkey record. Don’t do that.
> 
>> 2) Is it possible to specify precisely under which conditions the DKIM key 
>> is valid? Some third party records contain only an empty record "", others 
>> contain only revoked key like "p=" or it is a reference to a non-existent 
>> record. Unfortunately, RFCs do not provide unambiguous information on under 
>> which conditions this record is invalid. From my perspective, use of 
>> non-existing records or empty strings can draw that key useless, but rules 
>> specifying that in RFC or BCP will be welcome.
> 
> It must be a TXT record that lives under the hostname I described above, and 
> it must contain a (possibly empty) p= field. An empty TXT record is not a 
> valid DKIM public key.
> 
> It’s - obviously - possible to create a TXT record of that form that’s 
> unusable. A DKIM validator will return a not signed result in that case.
> 
>> 3) The "p=key" information containing the key material information encoded 
>> by Base64 should occur in the key exactly once. I did not find a condition 
>> in RFC for the existence of this record.
> 
> Section 3.2 of RFC 6376 says “ Tags with duplicate names MUST NOT occur 
> within a single tag-list; if a tag name does occur more than once, the entire 
> tag-list is invalid.”
> 
> Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED.
> 
> So there must be exactly one p= in a valid DKIM public key (in text format, 
> as would be published via DNS, anyway).
> 
>> I found only information on implementation behavior, when "p=", i.e. an 
>> empty key material, is considered revoked. However, it is not unambiguous 
>> whether this approach is acceptable. Also specification of that rules can 
>> make my life much easier.
> 
> Cheers,
>  Steve
> 

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

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

[Steve Atkins]

> On 16 May 2023, at 15:00, Jan Dušátko  
> wrote:
> 
> Hi,
> I would like to ask how you feel about the possibility of changing the 
> conditions for DKIM keys stored in DNS. Best in some future RFC release about 
> DKIM itself. I have a practical experience during review and cleaning of 
> thousands of domain, which is exhausting. And discussion about that keys also 
> with 3rd party is sometimes hard. In situation that you would like to discuss 
> that, I can provide kind of examples.
> 1) At this moment, the use of the tag "v=DKIM1;" is only RECOMMENDED and if 
> this tag is used, it must be the first. Unlike, for example, SPF and DMARC, 
> this is not a REQUIRED (MANDATORY) record. In case of an attempt to identify 
> DKIM records, then there is a situation where it is not possible to determine 
> which records are DKIM keys. Often, these keys are in other places where they 
> allow to create CNAME to the expected location of the selector. These 
> locations may be application dependent or may be with third parties 
> configuration. From my perspective, MANDATORY record "v=DKIM1;" could help to 
> identify DKIM keys much easily.

A DKIM key will only ever be found in DNS under a name of the form 
._domainkey.. If you find a TXT record under a name 
like that it’s either a valid domain key record, or it’s invalid. No other sort 
of TXT
record will live there. See section 3.6.2.1 of RFC 6376.

If you publish wildcard TXT records then you may end up inadvertently 
publishing other TXT records underneath the _domainkey record. Don’t do that.

> 2) Is it possible to specify precisely under which conditions the DKIM key is 
> valid? Some third party records contain only an empty record "", others 
> contain only revoked key like "p=" or it is a reference to a non-existent 
> record. Unfortunately, RFCs do not provide unambiguous information on under 
> which conditions this record is invalid. From my perspective, use of 
> non-existing records or empty strings can draw that key useless, but rules 
> specifying that in RFC or BCP will be welcome.

It must be a TXT record that lives under the hostname I described above, and it 
must contain a (possibly empty) p= field. An empty TXT record is not a valid 
DKIM public key.

It’s - obviously - possible to create a TXT record of that form that’s 
unusable. A DKIM validator will return a not signed result in that case.

> 3) The "p=key" information containing the key material information encoded by 
> Base64 should occur in the key exactly once. I did not find a condition in 
> RFC for the existence of this record.

Section 3.2 of RFC 6376 says “ Tags with duplicate names MUST NOT occur within 
a single tag-list; if a tag name does occur more than once, the entire tag-list 
is invalid.”

Section 3.6.1 of RFC 6376 describes the p= value as REQUIRED.

So there must be exactly one p= in a valid DKIM public key (in text format, as 
would be published via DNS, anyway).

> I found only information on implementation behavior, when "p=", i.e. an empty 
> key material, is considered revoked. However, it is not unambiguous whether 
> this approach is acceptable. Also specification of that rules can make my 
> life much easier.

Cheers,
  Steve

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

Re: [Ietf-dkim] Taking Responsibility

[Steve Atkins]

> On 13 Dec 2022, at 06:02, Evan Burke  wrote:
> 
> 
> On Mon, Dec 12, 2022 at 8:49 PM Murray S. Kucherawy  > wrote:
> At a recent meeting where I heard some mass senders talk about this problem, 
> the use of "x=" as a mitigation technique was raised.  I was curious to know 
> what their experience was in terms of (a) success overall, but also (b) how 
> broadly they found "x=" to have been properly implemented by receivers.  I 
> have to admit that was some months ago and now I forget the answer; maybe 
> someone else who was there can fill in that blank.
> 
> But I'm not sure that "x=" by itself is enough, given that it takes only a 
> matter of seconds for the attack to succeed, and it seems unlikely to me that 
> the "t=" and "x=" values would ever be that close together.
> 
> 
> x= is indeed the most effective single defensive technique for many affected 
> senders whose signatures are getting replayed, but yes - in practice it's 
> still "not quite enough" even when combined with multiple other mitigation 
> techniques. That's why we're here; existing solutions come up short.
> 
> I can't speak to support for x= broadly, but as mentioned earlier these 
> replays were almost exclusively targeted at end recipients at certain large 
> mailbox providers, and I can confirm those have proper support for x=.

If people are seeing DKIM replays we should have data on the delay between the 
mail originally being sent, and it being replayed?

Cheers,
  Steve___
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

[Steve Atkins]

> On 20 Nov 2022, at 21:42, Dave Crocker  wrote:
> 
> On 11/20/2022 1:12 PM, Steve Atkins wrote:
>>> On 20 Nov 2022, at 20:48, Dave Crocker  wrote:
>>> 
>>> Remembering that you kicked this off with a heuristic approach, I'm merely 
>>> noting that a BCC with an addressee listed in it should be just as valid 
>>> (to the heuristic) as having it occur in To: or CC:.  And since you don't 
>>> agree, I am not at all understanding the basis.

>> It’s a reasonable heuristic if Bcc is included in the DKIM signature, I just 
>> don’t think including Bcc in the DKIM signature is a good idea.
> 
> Including Bcc: in the signature is a given, for this topic.

I've no objection if that’s the given. 

> 
> 
>> Handling of Bcc is not terribly well-defined, particularly for forwarders 
>> (which will sometimes strip it, and sometimes
> 
> I have no idea what 'handling' you have in mind.  To: and CC: do not get 
> 'handled' except during a Reply process.
> 
> As for 'forwarders', I'm not sure what you mean.  Certainly not MTA.  That 
> leaves post-delivery behavior, with re-posting, which is entirely outside the 
> scope DKIM.

Smarthosts rewrite or remove Bcc headers in mail that they accept as a 
submission from an MUA before they deliver it to the next MTA, in a way that’s 
implementation (and configuration) defined. Some will do so for mail received 
from another MTA, not as a submission - e.g. postfix, by default, will strip 
any Bcc headers after it receives an email and before it passes it to the 
opendkim milter (I believe, I’ve not tested that.) or forwards it on to the 
next MTA.

One of the ways we’ve tried to make DKIM signing robust across the wild west of 
the email network has been to avoid signing things that might change in 
transit. Bcc headers in particular are definitely one of those things, and are 
special cased as “you should modify or delete this” in quite a lot of places.

But perhaps we don’t care in this particular case? If Bcc modification breaks 
the signature then it’s no worse - for delivery to this single recipient - than 
it would have been otherwise. I don’t think it affects the broader 
identification of mail streams for reputation tracking in a way we’d care about 
either?

>> As far as delivery to the recipient is concerned it’s a reasonable argument 
>> that this only applies to messages where the recipient is not in the To or 
>> Cc header, so signing the Bcc header is going to be no worse, and may even 
>> be better in the rare case where the Bcc header includes the 821 recipient, 
>> and each individual message to each Bcc recipient is signed.
> 
> Sorry I wasn't clear.  The premise is that the address in the BCC is a 
> recipient, listed in an envelope address.



Cheers,
  Steve

___
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

[Steve Atkins]

> On 20 Nov 2022, at 20:48, Dave Crocker  wrote:
> 
> On 11/20/2022 12:31 PM, Steve Atkins wrote:
>>> On 20 Nov 2022, at 16:30, Dave Crocker  wrote:
>>> 
>>> On 11/10/2022 5:32 AM, Steve Atkins wrote:
>>>> A heuristic I’ve suggested previously is “If the recipient’s email address 
>>>> is not in the To: or Cc: header then treat the mail as unsigned”.
>>> Even if it is showing in a (signed) BCC field?
>> Definitely. I wouldn’t want to encourage any use of the Bcc field beyond the 
>> smarthost, let alone any belief that signing it was a good idea.
>> 
>> The content of the Bcc field, or even the existence of it, at the time it’s 
>> received by the MX is at best implementation-defined. Signing it at
>> the smarthost is going to cause DKIM to fail far more often than not.
> 
> I don't understand the basis (or possibly even the meaning) of either of the 
> sentences in the above second paragraph.
> 
> Remembering that you kicked this off with a heuristic approach, I'm merely 
> noting that a BCC with an addressee listed in it should be just as valid (to 
> the heuristic) as having it occur in To: or CC:.  And since you don't agree, 
> I am not at all understanding the basis.

It’s a reasonable heuristic if Bcc is included in the DKIM signature, I just 
don’t think including Bcc in the DKIM signature is a good idea.

Handling of Bcc is not terribly well-defined, particularly for forwarders 
(which will sometimes strip it, and sometimes won’t), so even if your smarthost 
reliably only signs after any Bcc editing or message explosion it’s less likely 
to survive transit than other headers. If it’s signed it’s likely to increase 
the chance of a message that was signed when sent failing to verify when 
received.

As far as delivery to the recipient is concerned it’s a reasonable argument 
that this only applies to messages where the recipient is not in the To or Cc 
header, so signing the Bcc header is going to be no worse, and may even be 
better in the rare case where the Bcc header includes the 821 recipient, and 
each individual message to each Bcc recipient is signed.

¯\_(ツ)_/¯

I still don’t think it’s a good idea, but I’m less convinced of that than I was 
20 minutes ago.

Cheers,
  Steve


> 
> The only variability I know of, for BCC, is what the originating host chooses 
> to put in it, and I believe it is a small range of rather simple choices.
> 
> 
> 
>> 4871 says:
>>>  The following header fields SHOULD NOT be included in the signature:
>>> 
>>>o  Return-Path
>>>o  Received
>>>o  Comments, Keywords
>>>o  Bcc, Resent-Bcc
>>>o  DKIM-Signature
>> 6376 does not. I’m not sure why that changed.
> 
> Perhaps because there was no credible justification for the guidance?
> 
> (I can see that guidance against signing envelope fields is problematic, 
> given the timing, etc., of their creation, and signing DKIM-Signature 
> confuses me.  But guidance against signing 5322 address fields makes no sense 
> to me at all.  (And I don't recall the discussion about this for 4871.)
> 
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social
> 

___
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

[Steve Atkins]

> On 20 Nov 2022, at 16:30, Dave Crocker  wrote:
> 
> On 11/10/2022 5:32 AM, Steve Atkins wrote:
>> A heuristic I’ve suggested previously is “If the recipient’s email address 
>> is not in the To: or Cc: header then treat the mail as unsigned”.
> 
> Even if it is showing in a (signed) BCC field?

Definitely. I wouldn’t want to encourage any use of the Bcc field beyond the 
smarthost, let alone any belief that signing it was a good idea.

The content of the Bcc field, or even the existence of it, at the time it’s 
received by the MX is at best implementation-defined. Signing it at
the smarthost is going to cause DKIM to fail far more often than not.

4871 says:

>  The following header fields SHOULD NOT be included in the signature:
> 
>o  Return-Path
> 
>o  Received
> 
>o  Comments, Keywords
> 
>o  Bcc, Resent-Bcc
> 
>o  DKIM-Signature

6376 does not. I’m not sure why that changed.

Cheers,
  Steve
___
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

[Steve Atkins]

> On 11 Nov 2022, at 15:19, Murray S. Kucherawy  wrote:
> 
> On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins  > wrote:
> 
>> The MP limits the volume of messages that a user can send out.  However, by 
>> signing even one message, it takes the responsibility for its content.  
> 
> This appears to be the disconnect. The MP takes responsibility for the 
> *MESSAGE* - that message, sent to that user. 
> 
> I think you've hit on possibly the most interesting part of this: In RFC 
> 6376, we said "You're taking some responsibility for this message... and oh, 
> by the way, it could get replayed, and your claimed responsibility extends to 
> that case as well".  I don't know that we underscored the latter very much 
> then or since.
> 
> So to me, part of this hinges on whether we feel we need to remedy that, or 
> be comfortable pointing at 6376 and telling people to read it again, properly 
> this time, and seeing if the industry is OK with that.

I would be interested in hearing what a mainstream mailbox provider has to say 
about the issue - is it actually an operational problem for them, how much of 
it they see, if they believe any changes could help them mitigate it - before 
expending much effort.

I’ve heard concern from some ESPs that DKIM replays will impact their domain 
reputation and delivery rates, but no confirmation from mailbox providers that 
it does (and if it does, whether that’s a protocol level problem or just 
something that should be tweaked in their reputation tracking).

Cheers,
  Steve

___
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

[Steve Atkins]

> On 11 Nov 2022, at 09:23, Laura Atkins  wrote:
> 
>> Ultimately, I don't think senders should DKIM sign mail they aren't willing 
>> to 
>> take responsibility for, since that's exactly what a DKIM signature is 
>> supposed to signify.
> 
> They took responsibility for the single opt-in message that was sent through 
> their system. I’m not sure they have any responsibility for the million 
> copies of the message the recipient sends through a different infrastructure. 
> Unless you’re saying that DKIM signatures should only be assigned to mail 
> that has been manually reviewed by the infrastructure host?

Manual review wouldn’t help.

A single email advertising something sent to a single recipient who has 
consented to receive it isn’t problematic, and it looks pretty much like every 
legitimate customer of the ESP.

That same mail, byte-for-byte identical, sent through non-ESP infrastructure to 
a million non-consenting recipients is a problem. And it’s not one that, 
currently, the ESP can do that much to mitigate (there are things they do to 
attempt to, such as breaking redirector links and so on, but that’s not that 
effective and it’s after the incident).

It’s not a new concern - I remember sitting in a Yahoo conference room 
discussing exactly this issue before DomainKeys was launched - but as mailbox 
providers pay more attention to DKIM-keyed reputation of mail streams it’s one 
that’s actively being abused.

The onus is probably on the receivers to mitigate the several related problems, 
as they’re the only responsible party that’s in a position to do so (they’re 
the only ones other than the spammer who sees the email, and they’re the ones 
who are relying on DKIM identified mail streams to help deliver wanted mail and 
reject unwanted mail for their customers). I’m sure that ESPs would be happy to 
make changes that would assist them in doing that, of course.

Cheers,
  Steve

___
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

[Steve Atkins]

> On 10 Nov 2022, at 13:17, Murray S. Kucherawy  wrote:
> 
> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins  > wrote:
> In many cases, the reason the mail isn’t going out through the signing domain 
> is because the signing domain’s anti-spam heuristics are good enough that the 
> sender couldn’t maintain an account there long enough to send out any volume 
> of email. That’s why the domain has a good reputation - because they block 
> spam off their network. This is a way to steal the good reputation from the 
> good ESP. 
> 
> Interesting.  Almost seems like "SPF against the signing domain" could be a 
> win, except for all the usual forwarding concerns.
> 
> 2) The messages often have two different To: lines
> 
> This violates RFC 5322, so it would be easy to filter these out, except that 
> we would need to know how common and tolerated this is today among legitimate 
> messages.


The other (more common?) case is that the original recipient is in the signed 
822.To, while the new recipient is not in the To: or Cc: headers at all. While 
that’s just the same as old-school alias forwarding, and you might not be able 
to spot that on any given single email I’d bet that it’s easy to spot and block 
at a mailbox provider of any size.

A heuristic I’ve suggested previously is “If the recipient’s email address is 
not in the To: or Cc: header then treat the mail as unsigned”.

Cheers,
  Steve


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

Re: [Ietf-dkim] x= and DKIM replay

[Steve Atkins]

> On 2 Mar 2022, at 19:42, Evan Burke  wrote:
> 
> 
> Hi,
> 
> I'm reading the section in rfc6376 on the x= tag, specifically - 
> 
> INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay defense.
> 
> Could anyone shed some light on the reasoning for this, by chance? I note 
> that the spec for x= says "Signatures MAY be considered invalid [if past 
> expiration]", which isn't particularly strong guidance for how verifiers 
> should behave, but from my perspective, signature expiration could in theory 
> be an effective tool (among other defenses) to help reduce the viability of 
> replays.

I think the reasoning was that a malicious replay attack could get a signed 
message and resend it very quickly, much quicker than the 90% bounds of how 
long it takes a typical bulk message to be queued and delivered - so setting 
expiration soon enough to prevent a malicious replay attack would also 
invalidate a lot of normally delivered mail.

So x= can’t be used to defend against competently handled, intentional replay 
attacks.

If I recall correctly (and I may not, it was a long time ago) the sort of lazy 
replays we’re seeing now weren’t really part of the threat modeling. Is x= 
potentially useful there? Could be.

It’d be worth looking at - whether DKIM checkers enforce it, what the spread on 
message sign time vs delivery time is, what the delay between original delivery 
and replay is. And whether the folks currently doing replays are likely to 
modify their behaviour if x= has any effect on them. I’d hate to roll out yet 
another mechanism that damages reliability of legitimate email while being 
trivially avoided by senders of malicious email.

Cheers,
  Steve

___
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

[Steve Atkins]

On 12/05/2020 09:20, Alessandro Vesely wrote:

On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote:

On 5/11/2020 1:33 PM, Jim Fenton wrote:


There might also be the situation where a domain wants to delegate a key

Hence my suggestion that figuring out such details is where discussion could
get interesting, if only because people will raise all sorts of combinatorial
theories, independent of demonstrated need, and this is a space with lots of
combinatorials...


Besides delegated keys, some other obvious classes I'd propose —without
venturing to forge English keywords— are as follows:

* 1st class personal messages (with or without From: restrictions),

* mailing lists (with or without From: rewrite),

* bulk messages (including transactional confirmations, complaints, ...),

* forwarded mail (after severe/loose antispam filtering).

Perhaps, the keywords should be dash-separated jumbles of terms chosen from a
predefined grab bag, to allow for combinations.



Some prior work in this space is TEOS.

https://www.researchgate.net/publication/301324998_Trusted_Email_Open_Standard_A_Comprehensive_Policy_and_Technology_Proposal_for_Email_Reform 



Cheers,
  Steve

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