[Ietf-dkim] Re: DKIM with body length

[Scott Kitterman]

On May 23, 2024 6:13:07 PM UTC, John Levine  wrote:
>It appears that Murray S. Kucherawy   said:
>>I've read the middle part a few times and I don't understand either the
>>attack or the proposed mitigation, so I think some examples might help.
>
>The attack requires l= and an unsigned Content-Type header.
>
>If Content-Type isn't signed, the bad guy can change the part boundary
>string and then add new parts with the new boundary at the end. The
>entire original message, which is all that the l= covers, is ignored
>as junk before the first boundary.
>
>I guess this isn't as obvious as the authors of 6376 thought since we still
>have at least one person on this list insisting that you don't need to sign 
>C-T.
>
>On the other hand, I see that the perl and python DKIM modules sign
>the MIME Content-* headers by default. Do you remember what opendkim
>does? A quick look at the code wasn't too enlightening.
>
>Requiring that the l= cover some minimum percentage of the message is
>helpful but not that helpful, since you could add a short part with a
>phish URL to a long message and probably still pass the percent rule.
>
>On the third hand, I'm looking at mail in the IETF archives from
>Verisign which has had DKIM signatures the l= tag since shortly after
>the time they switched from Google to Ironport in late 2016. The set
>of headers it signs is inconsistent. It always includes MIME-Version,
>sometimes Content-Transfer-Encoding, and never Content-Type. So we do
>have at least some examples where this bug exists.
>
For the Python module, my recollection is that I stared at RFC 6376, Section 
5.4.1 and made the default set of header fields what it looked to me like the 
document recommended.  I assume that since defaults are set before we know 
anything about the message to be signed, I included Content-Type since there's 
no way to know at that point if there will be an l= in the signature or not.

I'm confident I considered it enough of a corner case not to be worth adding 
complexity for.



Honestly, I think l= is an idea whose time has passed (if it ever existed at 
all).  We ought to just kill it using the simplest procedural mechanism 
available.

Scott K

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

[Ietf-dkim] Re: RFC 8463: errata needed?

[Scott Kitterman]

On May 8, 2024 11:25:11 PM UTC, Steffen Nurpmeso  wrote:
>Hello.
>
>So i have had a problem with the little DKIM sign milter i had
>written in that users (receivers, actually) reported back that the
>ED25519 signature produces verification failures (i saw result
>headers of two, and got informed of a third).
>And some of the publically accessible DKIM test sites that were
>announced here also fail, as timely as last Saturday night.
>
>Now, that i did not understand since the RSA is waved through by
>any counterpart i have ever seen, and the code path is the very
>same, and then also i am doing nothing, it is all OpenSSL.
>(Having said that, my published public key was not "raw" but of
>ASN.1 format which Hanno Böck informed me of, back in April
>i think.)
>
>Therefore i took RFC 8032 from Simon Josefsson, which is
>a fantastic thing (beyond my mathematical and cryptographical
>understanding) that includes a complete default implementation of
>the algorithm as such!  (And it needs nothing external but SHA-512
>from the standard python hashlib in addition.)
>
>So i took that code and modified the actual driver a litte bit for
>my purpose, and it occurred to me that my sofware generates
>correct signatures.  (There is one test outstanding that beats
>onto the canonicalization, but since that works for RSA; anyway
>i want to integrate the outcome in the unit test, thus.)
>
>Anyhow, i had a look around the DKIM implementations, and most of
>them have near-nil ed25519 tests.  Some exactly one.  Anyhow.
>But that is not why i come here, yet, except that possibly you who
>read this and whose software verification fails the signature of
>this email should possibly have a look again.
>
>I come here because alongside the above i had a look at RFC 8463
>again, and its example in "A.3.  Signed Message".
>And if i use its "A.1.  Secret Keys", and (manually) normalize the
>example message header of A.3 via "relaxed" from/to 
>
>   From: Joe SixPack 
>   from:Joe SixPack ^M$
>   To: Suzie Q 
>   to:Suzie Q ^M$
>   Subject: Is dinner ready?
>   subject:Is dinner ready?^M$
>   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
>   date:Fri, 11 Jul 2003 21:00:37 -0700 (PDT)^M$
>   Message-ID: <20030712040037.46341.5...@football.example.com>
>   message-id:<20030712040037.46341.5...@football.example.com>^M$
>
>plus
>
>   dkim-signature:v=1; a=ed25519-sha256; c=relaxed/relaxed; 
> d=football.example.com; i=@football.example.com; q=dns/txt; s=brisbane; 
> t=1528637909; h=from : to : subject : date : message-id : from : subject : 
> date; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=
>
>which seems correct to me, and pass that through RFC 8032 code:
>
>  privkey: b'nWGxne/9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A=\n'
>  pubkey : b'11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=\n'
>  The message is:
>  >>>b'from:Joe SixPack \r\nto:Suzie Q 
> \r\nsubject:Is dinner ready?\r\ndate:Fri, 11 Jul 
> 2003 21:00:37 -0700 
> (PDT)\r\nmessage-id:<20030712040037.46341.5...@football.example.com>\r\ndkim-signature:v=1;
>  a=ed25519-sha256; c=relaxed/relaxed; d=football.example.com; 
> i=@football.example.com; q=dns/txt; s=brisbane; t=1528637909; h=from : to : 
> subject : date : message-id : from : subject : date; 
> bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b='<<<
>
>then i get
>
>  Signature: 
> b'QGeDV9CRdXSybek0z54GoycZ4/kl1PsNnGoOsCZ0ZOOwiGYFE8Ft0SZpy1XLW/fwlwNFC1k6VaxsnQAH8+9cAA==\n'
>  Signature verifies: True
>
>instead of the
>
>  
> /gCrinpcQOoIfuHNQIbq4pgh9kyIK3AQUdt9OdqQehSwhEIug4D11BusFa3bT3FY5OsU7ZbnKELq+eXdp1Q1Dw==
>
>of RFC 8463.  So either i am totally confused and "have tomatoes
>on my eyes", or this is an errata (and it seems other
>implementation(s) have a problem).

There are multiple implementations that are interoperable with each other and 
match the values in the RFC.  My first guess would not be a specification error.

Scott K

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

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

[Scott Kitterman]

On April 14, 2024 7:13:55 PM UTC, Steffen Nurpmeso  wrote:
>Scott Kitterman wrote in
> <2c92eb24-3332-436c-a0bb-d4bac3322...@kitterman.com>:
> |On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso  \
> |wrote:
> |>Scott Kitterman wrote in
> |> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>:
> |>|On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso  \
> |>|>Thanks to Hanno Böck (known from ossec and more) i was pointed to
> |>|>my falsely published ED25519 DKIM key.
> |>|>Until now that simply was the complete ED25519 public key, just
> |>|>like for RSA, instead of extracting the actual "bitstring data"
> |>|>from the standardized ASN.1 container, which starts at offset 16
> |>|>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka
> |>|>the binary blob).
> |>|>
> |>|>I realize that RFC 8463 says repeatedly that the base64-encoded
> |>|>representation of an ED25519 key is 44 bytes, and that the
> |>|>examples go for this.  Still there is no wording that the entire
> |>|>ASN.1 structure shall be thrown away.
> |>|
> |>|At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \
> |>|specified yet.  Openssl didn't support ED25119 either.  I'm not sure \
> |>|what you think we should have put in that we didn't.
> |>|
> |>|It seems to me that you are saying that the RFC is correct and clear, \
> |>|but that you were certain you knew better than the RFC.  That's not \
> |>|a thing an RFC can fix.
> |>
> |>There *is* RFC 8410 to which 8463 refers, around the same time.
> |>It defines exactly this, no?  It says there are no further
> |>parameters, but it does not say "hey so you can go and just leave
> |>that niche container off".
> |>Sure it is 44 bytes, but the entire thing is 64.
> |>It is de-facto only the single example in A.2 which reveals the
> |>total ignorance of ASN.1, and it is about brisbane and football,
> |>which i cannot glue together (letting aside it is written by an
> |>american, and who knows what kind of "football" that is?, as
> |>i seem to know they say "soccer" for what i would think, but it is
> |>4am so i do not truly think anyhow.  Saturday night all right for
> |>fighting, ah.)  (OpenSSL in mid 2017, at least a bit.)
> |>Thus: smart, very smart.  Is always too smart for some.
> |>Just leave them behind.
> |
> |I don't see it?  Where is the reference to 8410?
>
>Yes you are right.  8463 only refers to 8032, and does not mention
>8410 at all.  This is a complete misunderstanding.  I have 8410
>since February 2023, and 8032 since 31st of January this year,
>coming from a completely different background, having read 5480
>(Elliptic Curve Cryptography Subject Public Key Information) and
>more in the past, and am a CMS and x.509 "fanatic".
>
>I think now that i understand that 8463 just "invents its own
>protocol" instead of embedding itself into the CMS / X509 / PKI
>infrastructure i no longer like it at all.  What a mess.  It is
>Wireguard VPN / SSH etc raw algorithm logic!

Since nothing else existed at the time we did the work, I'm not sure what else 
we could have done instead.  B64 of the public key isn't that hard to do.  
Honestly, it was much easier to deal with implementing it than RSA shoved into 
ASN.1.

Ultimately, DKIM stuff is for DKIM and I don't think it's a huge problem if 
it's slightly different than other things.  In dkimpy I included tools to 
generate keys correctly.  I think that as long as library providers do that, 
this is a non-issue.

Scott K

Scott K

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

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

[Scott Kitterman]

On April 14, 2024 1:53:07 AM UTC, Steffen Nurpmeso  wrote:
>Scott Kitterman wrote in
> <5368ac9a-51d5-4aec-ab19-613dbead7...@kitterman.com>:
> |On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso  \
> |wrote:
> |>Hello.
> |>
> |>Thanks to Hanno Böck (known from ossec and more) i was pointed to
> |>my falsely published ED25519 DKIM key.
> |>Until now that simply was the complete ED25519 public key, just
> |>like for RSA, instead of extracting the actual "bitstring data"
> |>from the standardized ASN.1 container, which starts at offset 16
> |>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka
> |>the binary blob).
> |>
> |>I realize that RFC 8463 says repeatedly that the base64-encoded
> |>representation of an ED25519 key is 44 bytes, and that the
> |>examples go for this.  Still there is no wording that the entire
> |>ASN.1 structure shall be thrown away.
> |
> |At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not \
> |specified yet.  Openssl didn't support ED25119 either.  I'm not sure \
> |what you think we should have put in that we didn't.
> |
> |It seems to me that you are saying that the RFC is correct and clear, \
> |but that you were certain you knew better than the RFC.  That's not \
> |a thing an RFC can fix.
>
>There *is* RFC 8410 to which 8463 refers, around the same time.
>It defines exactly this, no?  It says there are no further
>parameters, but it does not say "hey so you can go and just leave
>that niche container off".
>Sure it is 44 bytes, but the entire thing is 64.
>It is de-facto only the single example in A.2 which reveals the
>total ignorance of ASN.1, and it is about brisbane and football,
>which i cannot glue together (letting aside it is written by an
>american, and who knows what kind of "football" that is?, as
>i seem to know they say "soccer" for what i would think, but it is
>4am so i do not truly think anyhow.  Saturday night all right for
>fighting, ah.)  (OpenSSL in mid 2017, at least a bit.)
>Thus: smart, very smart.  Is always too smart for some.
>Just leave them behind.

I don't see it?  Where is the reference to 8410?

Scott K

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

Re: [Ietf-dkim] RFC 8463: DNS textual form underspecified

[Scott Kitterman]

On April 14, 2024 12:51:26 AM UTC, Steffen Nurpmeso  wrote:
>Hello.
>
>Thanks to Hanno Böck (known from ossec and more) i was pointed to
>my falsely published ED25519 DKIM key.
>Until now that simply was the complete ED25519 public key, just
>like for RSA, instead of extracting the actual "bitstring data"
>from the standardized ASN.1 container, which starts at offset 16
>(or -offset=12 if you use "openssl asn1parse -noout -out -" aka
>the binary blob).
>
>I realize that RFC 8463 says repeatedly that the base64-encoded
>representation of an ED25519 key is 44 bytes, and that the
>examples go for this.  Still there is no wording that the entire
>ASN.1 structure shall be thrown away.


At the time we wrote what became RFC 8463, ASN.1 for ED25519 was not specified 
yet.  Openssl didn't support ED25119 either.  I'm not sure what you think we 
should have put in that we didn't.

It seems to me that you are saying that the RFC is correct and clear, but that 
you were certain you knew better than the RFC.  That's not a thing an RFC can 
fix.

Scott K

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

Re: [Ietf-dkim] Testing a DKIM implementation

[Scott Kitterman]

On March 22, 2024 11:31:16 PM UTC, Steffen Nurpmeso  wrote:
>David Harris wrote in
> <65fd789c.26406.50826...@david.harris.pmail.gen.nz>:
> |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.
>
>I can quote a mail of mine from March 6th:
>
>  I am thankful i could contact https://www.appmaildev.com/de/dkim
>  for testing purposes.  (If you read this: your service is
>  broken, it does not support continuation lines in DKIM
>  signatures *at*all*.  But thank you!)
>
>It also does not support Ed25519.
>(Maybe they fixed it.  Apologies for when i am wrong.)
>
> |Thanks in advance for any assistance.

If someone wants to test Ed25519, contact me off list.

Scott K

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

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

[Scott Kitterman]

On March 6, 2024 11:12:38 PM UTC, Jeremy Harris  wrote:
>On 06/03/2024 22:41, Steffen Nurpmeso wrote:
>> exam i do not know
>
>exim, possibly?

Yes.  Sorry.  It looks like autocorrect got me.

Scott K

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

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

[Scott Kitterman]

On March 6, 2024 10:41:51 PM UTC, Steffen Nurpmeso  wrote:
>Scott Kitterman wrote in
> :
> |On March 6, 2024 9:56:50 PM UTC, Steffen Nurpmeso  \
> |wrote:
> |>--- Forwarded from Steffen Nurpmeso  ---
> |>Date: Wed, 06 Mar 2024 22:49:48 +0100
> |>Author: Steffen Nurpmeso 
> |>From: Steffen Nurpmeso 
> |>...
> |>Subject: Re: [pfx] Recommendation for dkim signing
> |>Message-ID: <20240306214948.V5gSjSiU@steffen%sdaoden.eu>
> |>...
> |>
> |>...
> |>So now that i have DKIM myself i tested.
> |>And *no* verification software i can reach actually supports
> |>Ed25519-sha256 as of RFC 8463 from September 2018!
> |
> |In addition to my dkimpy-milter, exam supports it and believe opendkim \
>
>Yes, you do support it.  I know of no endpoint i could reach out
>to test this, however.  But yes, of course your software
>thankfully supports it.
>
> |does as well.  Their combined market share no doubt rounds to zero, \
> |but the software does exist.
>
>exam i do not know, and OpenDKIM i am pretty sure does not support
>it, at least the Sourceforge.net thing; i have a local copy and
>the last change was in 2015.
>
> |This isn't horrible.  The main reason for RFC 8463 was, in my view, \
> |as a hedge for some discovery that suddenly made RSA obsolete, which \
> |hasn't happened yet.  From a standards perspective, it is there if needed.
>
>It greatly reduces the size of the headers, too.  And of the DNS
>entries, and the DNS traffic as such, in UDP.
>
>I would speak contra and say it is a terrible picture.
>And one mail i would have written right now in the queue.

For opendkim, you need to look on GitHub.  There has been some further 
development there.

Scott K

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

Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing

[Scott Kitterman]

On March 6, 2024 9:56:50 PM UTC, Steffen Nurpmeso  wrote:
>--- Forwarded from Steffen Nurpmeso  ---
>Date: Wed, 06 Mar 2024 22:49:48 +0100
>Author: Steffen Nurpmeso 
>From: Steffen Nurpmeso 
>...
>Subject: Re: [pfx] Recommendation for dkim signing
>Message-ID: <20240306214948.V5gSjSiU@steffen%sdaoden.eu>
>...
>
>...
>So now that i have DKIM myself i tested.
>And *no* verification software i can reach actually supports
>Ed25519-sha256 as of RFC 8463 from September 2018!

In addition to my dkimpy-milter, exam supports it and believe opendkim does as 
well.  Their combined market share no doubt rounds to zero, but the software 
does exist.

This isn't horrible.  The main reason for RFC 8463 was, in my view, as a hedge 
for some discovery that suddenly made RSA obsolete, which hasn't happened yet.  
From a standards perspective, it is there if needed.

Scott K

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

Re: [Ietf-dkim] DKIM Signature

[Scott Kitterman]

How many algorithms do you think is enough and why?

Scott K

On October 28, 2023 10:54:42 PM UTC, Thomas Vincent  
wrote:
>Future proofing? The history of encryption is riddled with examples of
>overconfidence.
>
>On Fri, Oct 27, 2023 at 2:02 PM John Levine  wrote:
>
>> It appears that Scott Kitterman   said:
>> >On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy" <
>> superu...@gmail.com> wrote:
>> >>On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko > 40dusatko@dmarc.ietf.org>
>> >>wrote:
>> >>
>> >>> I would like to ask to consider the possibility of defining a DKIM
>> >>> signature using Ed448. [...]
>>
>> >My view is that more encryption algorithms are bad for interoperability.
>> For DKIM signing/verifying to work, senders
>> >and verifiers need a common algorithm.  More choices make this more
>> complex to achieve.
>> >
>> >We standardized ed25119 as a hedge against unknown vulnerability in RSA.
>> ...
>>
>> Since we already have ed25519, why would we want ed448?  If ed25519 is a
>> ten ton steel
>> door on our cardboard box, ed448 is a fifteen ton steel door.
>>
>> 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] DKIM Signature

[Scott Kitterman]

On October 27, 2023 2:56:30 PM UTC, "Murray S. Kucherawy"  
wrote:
>On Sun, Oct 1, 2023 at 1:50 AM Jan Dušátko 
>wrote:
>
>> I would like to ask to consider the possibility of defining a DKIM
>> signature using Ed448. [...]
>
>
>Which DKIM implementations are known to be willing to support this if it
>were added?
>
>ED25519 support was added by a working group called DCRUP.  Although that
>WG has since closed, the list is still open and you could try posting there
>to see if there's interest.
>
>I don't think there are any working groups currently operating whose
>charters include taking up work like this.  The registry rules require an
>RFC with IETF Consensus, which would mean either a working group or
>sponsorship of an Area Director.  You would just need to produce a short
>document like RFC 8463 to get this done.

My view is that more encryption algorithms are bad for interoperability.  For 
DKIM signing/verifying to work, senders and verifiers need a common algorithm.  
More choices make this more complex to achieve.

We standardized ed25119 as a hedge against unknown vulnerability in RSA.  Given 
the small uptake in ed25119, I'm very unlikely to invest time in implementing 
yet another crypto algorithm unless it's needed because of known RSA/ed25119 
issues.  We don't need to hedge the hedge while the primary algorithm (RSA) is 
fine.

Maybe someday, but almost certainly not something I'd implement in the 
foreseeable future.

Scott K

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

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Scott Kitterman]

On August 9, 2023 3:15:36 AM UTC, Jesse Thompson  wrote:
>On Tue, Aug 8, 2023, at 6:37 AM, Scott Kitterman wrote:
>> On August 8, 2023 10:18:58 AM UTC, Laura Atkins  
>> wrote:
>> >> On 6 Aug 2023, at 19:07, Jesse Thompson  wrote:
>> >> 
>> >> On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
>> >>>> On 5 Aug 2023, at 02:43, Jesse Thompson > >>>> <mailto:z...@fastmail.com>> wrote:
>> >>>> 
>> >>>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
>> ...
>> >>> 
>> >>> A big driver of the work is actually Google. As I understand it, they 
>> >>> are having issues because the replay attackers are successfully stealing 
>> >>> reputation of otherwise good senders in order to bypass some spam 
>> >>> filtering. The replay attackers aren’t sending what we commonly think of 
>> >>> as spam through the signers - as the message is sent to one recipient 
>> >>> (not bulk) and it is opt-in (that recipient wants and has asked for the 
>> >>> mail). 
>> >> 
>> >> This is accurate from my observation. It takes only a single message 
>> >> which evades content filters, and the attacker is the first recipient, 
>> >> who will not report it as abuse. 
>> >> 
>> >> Which is why an earlier "just don't send spam" comment seemed to be 
>> >> borderline FUSSP rhetoric. If the message isn't detected by the receiver 
>> >> (who has the most visibility into the type of mail its users want to 
>> >> receive) then how can a sender be held to a higher standard of detection 
>> >> with less visibility?
>> >
>> >I agree wholeheartedly. I just wanted to make it clear for the record that 
>> >this isn’t an issue of the signer knowingly signing spam and “deserving” 
>> >any reputation problems. 
>> ...
>> 
>> Intent has nothing to do with it.  Reputation is what you do, not what you 
>> intend.
>
>I think we can agree that spammers will always exist because they are a 
>societal problem. Societal problems can't be completely solved with 
>technology. Spammers will find ways to leverage the technologies we build to 
>leverage in their ill will. DKIM didn't intend to give a haven for spammers to 
>hide behind DKIM signers, but that's what it does. DKIM replay is a problem 
>that is going to persist as long as society has spammers. Yet, DKIM isn't 
>designed to solve spam problems. It conveys identifiable and verifiable 
>information. DKIM signers will not be able to identify 100% of what a receiver 
>will consider spam, but they can provide additional verifiable information for 
>receivers to interpret into their disposition.
>

I think that very much depends on the type of sender.  For a corporate domain 
with good security practices, spam sending can and should be extraordinarily 
rare.  A premium service provider will probably not be able to do as well, even 
if they invest in knowing their customers.  A low cost/free provider will 
probably do less well yet.  I would expect each of these types of domains to 
have (appropriately) different reputations.

Yes, probably no one is 100% on this over an extended period of time, but that 
doesn't mean that it's hopeless.  I very much disagree with the idea that DKIM 
provides a haven for spammers.  It may be that receivers are over-valuing a 
good DKIM signature, but I expect they will adjust (recent discussions on this 
list point in that direction).

Scott K

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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On August 8, 2023 2:08:05 PM UTC, "Murray S. Kucherawy"  
wrote:
>On Tue, Aug 8, 2023 at 2:16 AM Alessandro Vesely  wrote:
>
>> On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote:
>> > On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:
>> >>
>> >> I think the document does describe the attack.  An instance of the
>> attack
>> >> is when a replayed message lands someplace it wasn't originally
>> intended to
>> >> land, assuming normal usage.
>>
>> That's ambiguous.  Obviously, since the attack was planned, it may well be
>> that the potential victims were originally intended.  The meaning is
>> tweaked by the "normal usage" assumption, which could be interpreted as
>> trying to pretend that the message author wasn't aware that the message
>> was
>> going to be replayed...?
>>
>
>I don't understand what ambiguity you're talking about.
>
>The document lays out how the attack is accomplished.  It also indicates
>that the only difference between typical DKIM operation (the original
>recipient set is the only recipient set) and the attack (the final
>recipient set is not the same).
...

That's true of all indirect mail flows.  It's not a distinguishing feature of 
the attack.

Scott K

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

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Scott Kitterman]

On August 8, 2023 10:18:58 AM UTC, Laura Atkins  wrote:
>
>
>> On 6 Aug 2023, at 19:07, Jesse Thompson  wrote:
>> 
>> On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
 On 5 Aug 2023, at 02:43, Jesse Thompson >>> > wrote:
 
 On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
...
>>> 
>>> A big driver of the work is actually Google. As I understand it, they are 
>>> having issues because the replay attackers are successfully stealing 
>>> reputation of otherwise good senders in order to bypass some spam 
>>> filtering. The replay attackers aren’t sending what we commonly think of as 
>>> spam through the signers - as the message is sent to one recipient (not 
>>> bulk) and it is opt-in (that recipient wants and has asked for the mail). 
>> 
>> This is accurate from my observation. It takes only a single message which 
>> evades content filters, and the attacker is the first recipient, who will 
>> not report it as abuse. 
>> 
>> Which is why an earlier "just don't send spam" comment seemed to be 
>> borderline FUSSP rhetoric. If the message isn't detected by the receiver 
>> (who has the most visibility into the type of mail its users want to 
>> receive) then how can a sender be held to a higher standard of detection 
>> with less visibility?
>
>I agree wholeheartedly. I just wanted to make it clear for the record that 
>this isn’t an issue of the signer knowingly signing spam and “deserving” any 
>reputation problems. 
...

Intent has nothing to do with it.  Reputation is what you do, not what you 
intend.

Scott K

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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman 
> 
> wrote:
> > On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> > ...
> > 
> > > (2) Throughout the document, the proper term "Replay Attack" (and
> > 
> > sometimes
> > 
> > > "Replay") is used, but it's never directly defined.  I don't think you
> > 
> > need
> > 
> > > it to be formal, but if you really want to do it that way, please add a
> > > definition for it.
> > 
> > ...
> > 
> > I think a definition that describes a condition that's technically
> > distinguishable from normal DKIM operations is essential if we are going
> > to
> > make any progress.  "I know it when I see it" may work for the US Supreme
> > Court, but it's not adequate here.
> 
> I think the document does describe the attack.  An instance of the attack
> is when a replayed message lands someplace it wasn't originally intended to
> land, assuming normal usage.
> 
> The document also describes that the payload itself in normal usage is
> indistinguishable from an instance of the attack; the obvious implication
> is that there's no solution based solely on the payload format.
> 
> Your point that we possibly can't go much further than that is one for the
> WG to deliberate, to be sure.  And I suggest that that's one possible
> outcome of this WG.
> 
> But my point above is simpler: "Replay Attack", when capitalized that way,
> has me going to look for a formal definition of that term someplace.  That
> is, if we're going to use it that way, we should define it that way.  So,
> just add it to the Glossary at least, or say in Section 1.1 that this term,
> in this document, means the attack described by that section.  Or something.

I see your point.  Thanks,

It will be interesting to see what develops.  It's not a mystery that I'm 
skeptical of a protocol solution to the issue.

Scott k


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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On August 7, 2023 11:10:07 PM UTC, Dave Crocker  wrote:
>On 8/7/2023 3:58 PM, Scott Kitterman wrote:
>> I think a definition that describes a condition that's technically
>> distinguishable from normal DKIM operations is essential if we are going to
>> make any progress.
>
>Except that the draft notes that isn't possible.
>
>There's a fair amount of text in 1.1 that seeks to describe the nature of a 
>Replay attack, and distinguish it from 'normal' behavior as best as we can.
>
>A better, more objective and precise definition would be great. Please also 
>provide one for spam.
>
>If someone has actual substance to offer, to improve 1.1, please, please, 
>please do offer it.
>
>d/
>
>ps.  Unless it isn't clear what existing draft text I'm referring to:
>
>> During development of the DKIM specification, DKIM Replay was identified as 
>> only of hypothetical concern. However, that attack has become commonplace, 
>> particularly for systems:
>> 
>>  *
>> 
>> Attackers create, obtain access, or compromise an account at some
>> Originator that signs messages with DKIM
>> 
>>   * Attackers locate a Receiver that consumes DKIM to make a delivery
>> decision. If the Receiver uses a reputation system with DKIM for
>> delivery decisions, the attacker finds an Originator with a high
>> reputation.
>>   * They send an email from that account to an external account also
>> under their control.
>>   * This single message is delivered to the attacker's mailbox, giving
>> them an email with a valid DKIM signature, for a domain with high
>> reputation.
>>   * They then post the message to a new and large set of additional
>> recipients at the Receiver.
>> 
>> Internet Mail permits sending a message to addresses that are not listed in 
>> the content To:, Cc: or Bcc: header fields. Although DKIM covers portions of 
>> the message content, and can cover these header fields, it does not cover 
>> the envelope addresses, used by the email transport service, for determining 
>> handling behaviors. So this message can then be replayed to arbitrary 
>> thousands or millions of other recipients, none of whom were specified by 
>> the original author.That is, DKIM Replay takes a message with a valid DKIM 
>> signature, and distributes it widely to many additional recipients, without 
>> breaking the signature.
>> 
>>   * Further, a message used in a Replay Attack has the same attributes
>> as some types of legitimate mail. That is, an individual, replayed
>> message has no observable differences from a legitimate message.

Then I guess I don't know what we're doing.

Solve a problem with a protocol change when the protocol can't tell the 
problematic case from normal usage seems like either the shortest working group 
ever or the longest.

I would agree that there's a description of what's happening that is considered 
bad, but that's not the same thing as a technically distinct definition.

Scott K

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

Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments

[Scott Kitterman]

On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
...
> (2) Throughout the document, the proper term "Replay Attack" (and sometimes
> "Replay") is used, but it's never directly defined.  I don't think you need
> it to be formal, but if you really want to do it that way, please add a
> definition for it.
...

I think a definition that describes a condition that's technically 
distinguishable from normal DKIM operations is essential if we are going to 
make any progress.  "I know it when I see it" may work for the US Supreme 
Court, but it's not adequate here.

Scott K


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

Re: [Ietf-dkim] Moving forward - from the chairs

[Scott Kitterman]

On April 10, 2023 7:16:41 PM UTC, Laura Atkins  wrote:
>
>
>> On 10 Apr 2023, at 19:38, Murray S. Kucherawy  wrote:
>> 
>> On Mon, Apr 10, 2023 at 11:24 AM Scott Kitterman > <mailto:ietf-d...@kitterman.com>> wrote:
>>> On Monday, April 10, 2023 2:05:28 PM EDT Laura Atkins wrote:
>>> ...
>>> > There is currently an active Call for Adoption for a draft.
>>> ...
>>> 
>>> What's the plan for closing this out?  I haven't seen any objections to the 
>>> idea and as of tomorrow it will have been over a week since the formal call 
>>> for adoption.  This happens rarely enough in my experience that I don't 
>>> recall 
>>> how long these normally run.
>> 
>> Usually a week or two.  The original post wasn't specific, so at this point 
>> I think the chairs could call consensus at their discretion unless someone 
>> wants to argue it should stay open longer.
>> 
>> The datatracker normally asks what the CFA duration is, but in the "History" 
>> tab for this document it doesn't look like one was recorded.  Might be 
>> something for the tools team to look at.
>
>I set it for 3 weeks when I set it up in the datatracker.
>
>I think it’s worthwhile to give folks a chance to weigh in. 

Thanks.  It wasn't clear to me what the duration of the call is.  I'm less 
interested in when it ends than that the end date be defined and known to the 
working group.


Scott K

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

Re: [Ietf-dkim] Moving forward - from the chairs

[Scott Kitterman]

On Monday, April 10, 2023 2:05:28 PM EDT Laura Atkins wrote:
...
> There is currently an active Call for Adoption for a draft.
...

What's the plan for closing this out?  I haven't seen any objections to the 
idea and as of tomorrow it will have been over a week since the formal call 
for adoption.  This happens rarely enough in my experience that I don't recall 
how long these normally run.

Scott K


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

Re: [Ietf-dkim] The DKIM WG has placed draft-chuang-dkim-replay-problem in state "Call For Adoption By WG Issued"

[Scott Kitterman]

On Tuesday, April 4, 2023 12:52:51 PM EDT Michael Thomas wrote:
> While a good start, this document is far too vague about what the
> current state of the problem actually is for those who of us who are not
> part of industry groups privy to more information.

To this specific point, I think any lack of crispness about the problem in the 
draft is reflective of uncertainty about how to describe it and we need to work 
on improving it.

As it happens, I was present at the industry group meeting in question (which 
is highly unusual for me, I was there for something unrelated) and as far as I 
can recall, everything that was discussed regarding the scope of the problem 
in that meeting has also been discussed here.  I don't think there's a 
reservoir of insider data that only some people know about.  I'm sure there 
are people in the working group who have access to more data as a result of 
their day job, but that's always true.

I think the fact that this work originated out of some private discussions is 
not material to where we go from here.

Scott K


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

Re: [Ietf-dkim] Call for adoption

[Scott Kitterman]

My view as well.  +1 for adoption.

Scott K

On April 4, 2023 4:10:41 PM UTC, Barry Leiba  wrote:
>I do not object to using this as a starting point (which is how I
>think "adoption" should generally be framed).
>
>Barry
>
>On Tue, Apr 4, 2023 at 11:50 AM Laura Atkins  wrote:
>>
>> I want to thank everyone for their patience as I learn IETF processes and 
>> tools. Tim and I are working on a statement for the group from us as chairs. 
>>  While we’re doing that, though, I would like to get the group moving 
>> forward and get some text adopted.
>>
>> I have issued a Call for Adoption for Wei’s draft so that we have text to 
>> work with and on. The list is still on moderation status but we will be 
>> approving posts.
>>
>> laura
>>
>>
>>
>>
>>
>>
>> --
>> The Delivery Experts
>>
>> Laura Atkins
>> Word to the Wise
>> la...@wordtothewise.com
>>
>> Email Delivery Blog: http://wordtothewise.com/blog
>>
>>
>>
>>
>>
>>
>> ___
>> 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] Comments on draft-chuang-dkim-replay-problem

[Scott Kitterman]

On Sunday, April 2, 2023 4:56:16 PM EDT Wei Chuang wrote:
> A -03 draft is available at
> https://www.ietf.org/archive/id/draft-chuang-dkim-replay-problem-03.html.

Thanks.  While I haven't given it a thorough review, based on a quick read, I 
think this should serve as the basis for further work in the group on our 
problem statement.  I think it should be adopted as a WG draft and then we 
should move forward from there.

Scott K


___
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

[Scott Kitterman]

I am attempting to tread carefully here.  My success in doing so is 
historically quite mixed, so if I fail, apologies in advance.

In my view Micheal has challenged your approach to some of your decisions in a 
very sharp manner (which I don't support).  In general, I think if a working 
group chair is party to a dispute, it's better for the other chair to address 
it.  When you are both a party to the dispute and use your authority to 
address it, it (at the very least) creates a potential perception of 
impropriety.

If we imagine a world where Michael's accusation is literally true and you 
were trying to shut down any discussion of alternatives to some pre-conceived 
result you've already decided on, this is precisely what the next step would 
be.

My request is that you withdraw this and ask Tim to send it instead if he 
thinks it's appropriate.

Personally, I found your response to him in Message-Id: 
<86ff4071-0720-4cde-9815-f7c472171...@wordtothewise.com> pretty harsh, 
particularly when two days later in Message-Id:  you agreed with me that it was reasonable 
to wait for the next revision of draft-chuang-dkim-replay-problem before 
working on it further.

Based on what you've said in those two messages, I understand your direction 
to the working group is to only talk about specific text changes to the non-WG 
draft, but you also agree there's really not much point in doing so.

Rather than take steps to push a contributor with a lot of relevant domain 
knowledge out of the group (which is precisely what this is, intended or not), 
I would encourage the chairs to work towards reducing the emotional energy in 
the group.  I think that would be more useful than process threats.

I am honestly wondering if I want to keep doing this.

Scott K

On Tuesday, March 28, 2023 5:31:07 AM EDT Laura Atkins wrote:
> Dear Michael,
> 
> Your message of 27 March quoted in its entirety below, included _ad hominem_
> attacks against another participant.  _Ad hominem_ is a fallacious form of
> argument wherein the person arguing attacks the person holding an opposing
> position, rather than attacking the position itself.  This is not
> acceptable, and you have been warned before.  I contacted you off-list on
> behalf of the chairs, under the procedures in BCP 25, but you have refused
> to take what we regard as rectifying action.
> 
> Accordingly, please understand this message as a formal warning under the
> procedures of BCP 25 that, if we observe continued behaviour of the sort
> you have exhibited, we shall suspend your posting privileges to the
> dkim-ietf mailing list for 30 days.  Behaviour of the sort includes
> anything that we believe to be needlessly personalized, and especially
> includes _ad hominem_ forms of argument.  We will also treat returning to
> points that have been closed without raising new arguments as attempts to
> disrput the functioning of the Working Group.
> 
> We will act without further warning in such an event.
> 
> If we take that action, and, after restoration of your privileges, we
> observe you to return to disrupting the work of the group, we shall
> undertake action under BCP 25.
> 
> Sincerely,
> 
> Laura (for the chairs)
> 
> > On 27 Mar 2023, at 17:04, Michael Thomas  wrote:
> > 
> > On 3/27/23 8:46 AM, Scott Kitterman wrote:
> >> On March 27, 2023 3:10:40 PM UTC, Laura Atkins  
wrote:
> >>> It seems to me a history of what did work / didn’t will go into document
> >>> 4 or the reasoning for document 3. My current preference is for the
> >>> discussion to not be in the problem statement. My reasoning is that
> >>> there will be discussion about what didn’t work and why it didn’t work.
> >>> I expect that there will be quite a bit of back and forth to capture
> >>> the details of why something didn’t work - including the adaptations
> >>> that the attackers made to the changes. This, to my mind, is the job of
> >>> the working group: to look at the current status, discuss where the
> >>> holes are and if they are protocol holes or if they are best practice /
> >>> implementation holes.
> >>> 
> >>> On a more practical point, we have a month to finalize the problem
> >>> statement. No one has proposed language to include in the problem
> >>> statement about what has worked and what hasn’t worked. Given the
> >>> current state of the group, I simply don’t think we have the time to
> >>> put this into the problem statement and get it out in time.
> >>> 
> >>> I do think we have the time and space to discuss techniques after the
> >>> problem statement is done and include it in one of the WG output
> >>> documents.>> 

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

[Scott Kitterman]

On Monday, March 27, 2023 12:42:25 PM EDT Laura Atkins wrote:
> > On 27 Mar 2023, at 16:46, Scott Kitterman  wrote:
> > 
> > On March 27, 2023 3:10:40 PM UTC, Laura Atkins  
wrote:
> >>> On 26 Mar 2023, at 11:13, Murray S. Kucherawy 
> >>> wrote:
> >>> 
> >>> On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas mailto:m...@mtcc.com>> 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;
> >>> 
> >>> (2) one or more protocol update document(s);
> >>> 
> >>> (3) a statement of some kind that the WG determined no feasible protocol
> >>> solution exists (and, one would hope, how it reached this conclusion);
> >>> 
> >>> (4) an update to current DKIM operational advice with respect to the
> >>> stated problem.
> >>> 
> >>> The only constraint in the charter is that (2) and (3) are mutually
> >>> exclusive.>> 
> >> Agreed with all of this.
> >> 
> >>> I believe that a history of what techniques were previously tried and
> >>> failed could arguably go into any of them.  The charter is neither
> >>> prescriptive or proscriptive on this point.>> 
> >> It seems to me a history of what did work / didn’t will go into document
> >> 4 or the reasoning for document 3. My current preference is for the
> >> discussion to not be in the problem statement. My reasoning is that
> >> there will be discussion about what didn’t work and why it didn’t work.
> >> I expect that there will be quite a bit of back and forth to capture the
> >> details of why something didn’t work - including the adaptations that
> >> the attackers made to the changes. This, to my mind, is the job of the
> >> working group: to look at the current status, discuss where the holes
> >> are and if they are protocol holes or if they are best practice /
> >> implementation holes.
> >> 
> >> On a more practical point, we have a month to finalize the problem
> >> statement. No one has proposed language to include in the problem
> >> statement about what has worked and what hasn’t worked. Given the
> >> current state of the group, I simply don’t think we have the time to put
> >> this into the problem statement and get it out in time.
> >> 
> >> I do think we have the time and space to discuss techniques after the
> >> problem statement is done and include it in one of the WG output
> >> documents.> 
> > So far, unless I was napping when it happened, we don't have a working
> > group draft of the problem statement.
> We have two documents that are up for debate as the working group draft.
> Anyone else is welcome to provide an alternative for consideration as well
> - as Dave did and that is now being wrapped into Wei’s draft.
> > Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before
> > investing any more time on the problem statement.  I think it would make
> > sense for the group to do a quick assessment of it, when it is available
> > and see if we want to adopt it as a working group draft (I strongly
> > suspect we do).
> That’s my feeling as well, particularly given no one else is stepping up to
> write a draft of the problem statement on behalf of the working group. If
> someone does have an alternative in progress please let me know.

Do you plan adopt it as a working group draft?  That's a critical step in the 
process.  Anything before that step needn't reflect anything other than the 
author's opinion (and that's optional).

Scott K



___
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

[Scott Kitterman]

On March 27, 2023 3:10:40 PM UTC, Laura Atkins  wrote:
>
>
>> On 26 Mar 2023, at 11:13, 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;
>> 
>> (2) one or more protocol update document(s);
>> 
>> (3) a statement of some kind that the WG determined no feasible protocol 
>> solution exists (and, one would hope, how it reached this conclusion);
>> 
>> (4) an update to current DKIM operational advice with respect to the stated 
>> problem.
>> 
>> The only constraint in the charter is that (2) and (3) are mutually 
>> exclusive.
>
>Agreed with all of this. 
>
>> I believe that a history of what techniques were previously tried and failed 
>> could arguably go into any of them.  The charter is neither prescriptive or 
>> proscriptive on this point.
>
>
>It seems to me a history of what did work / didn’t will go into document 4 or 
>the reasoning for document 3. My current preference is for the discussion to 
>not be in the problem statement. My reasoning is that there will be discussion 
>about what didn’t work and why it didn’t work. I expect that there will be 
>quite a bit of back and forth to capture the details of why something didn’t 
>work - including the adaptations that the attackers made to the changes. This, 
>to my mind, is the job of the working group: to look at the current status, 
>discuss where the holes are and if they are protocol holes or if they are best 
>practice / implementation holes. 
>
>On a more practical point, we have a month to finalize the problem statement. 
>No one has proposed language to include in the problem statement about what 
>has worked and what hasn’t worked. Given the current state of the group, I 
>simply don’t think we have the time to put this into the problem statement and 
>get it out in time. 
>
>I do think we have the time and space to discuss techniques after the problem 
>statement is done and include it in one of the WG output documents. 
>
So far, unless I was napping when it happened, we don't have a working group 
draft of the problem statement.

Personally, I'm waiting for draft-chuang-dkim-replay-problem-02 before 
investing any more time on the problem statement.  I think it would make sense 
for the group to do a quick assessment of it, when it is available and see if 
we want to adopt it as a working group draft (I strongly suspect we do).

Once that's done, I think there will be a solid basis for progress towards the 
milestone.  

In the meantime, if someone wants to write up a section on what's been tried, I 
don't think it's on the critical path for the milestone until there's agreement 
to add it to the document.  It certainly doesn't delay anything now while we're 
waiting for the -02 of the problem statement.  If the text can be developed in 
parallel, it might not affect the schedule significantly.  Myself, if we can, I 
think we should (I will volunteer to review and provide feedback on this but 
not to write it - I don't have the time).

Scott K

___
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

[Scott Kitterman]

On March 25, 2023 3:13:11 PM UTC, Michael Thomas  wrote:
>
>On 3/24/23 9:10 PM, Jim Fenton wrote:
>> On 25 Mar 2023, at 8:57, Michael Thomas wrote:
>> 
>>> Somebody brought up that this could turn into a research project. Frankly I 
>>> think that is highly likely the case and is why rechartering was so 
>>> problematic. Since M3AAWG can't figure it out with lots of inside the 
>>> industry information, what makes anybody think the wider community would 
>>> have better insight which is not speculative because it has been tested and 
>>> known to work? It speaks volumes that they didn't have a solution in mind 
>>> and bring it to IETF to vet in the wider community. That sure sounds like a 
>>> research project to me.
>> It may indeed be a research project, but I’d rather see that happen in IETF 
>> or some similarly open venue rather than to have it happen in a closed forum 
>> like M3AAWG, which brings the risk that the proposed solution will meet the 
>> needs of only the large domains that are M3AAWG members, and not the small 
>> ones that aren’t.
>
>The chair is now unilaterally making it clear that nobody is allowed to 
>question the scope of non-working group drafts beyond wordsmithing, IETF 
>process be damned. Consensus calls are not needed, apparently. "Politely", 
>indeed.
>
>I would have rather they actually had a proposal in hand so we could actually 
>know what their agenda was. If it were on the strength of the current set of 
>proposals, this wg should have never been rechartered because none of them 
>work.


So far, I don't think anyone has any better ideas, which is why it was 
important that a non-protocol result be in scope for the WG.

Scott K

___
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

[Scott Kitterman]

On March 24, 2023 5:42:41 PM UTC, 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.

As long as you include integration of DKIM into the overall email architecture 
and broader impacts of DKIM changes as part of 'concerned with DKIM problems', 
I agree.

Scott K

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

Re: [Ietf-dkim] Replay Attack vs. something else

[Scott Kitterman]

On Wednesday, March 22, 2023 8:21:55 PM EDT Dave Crocker wrote:
> My understanding is that the term DKI MReplay Attack refers to a very
> specific scenario.
> 
> The scenario is re-posting a message such that the original DKIM
> signature remains valid.
> 
> Any other sort of re-posting does not qualify, under this definition.
> 
> So, for example, anything depending on 're-signing' is not a DKIM Replay
> Attack.
> 
> Yes?

That's my understanding, however that scenario also describes a normal mailing 
list if it doesn't make modifications that break an existing DKIM signature or 
any kind of forwarding with similar characteristics.

Scott K


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

Re: [Ietf-dkim] Clarifying the problem

[Scott Kitterman]

On March 22, 2023 3:01:40 AM UTC, "Murray S. Kucherawy"  
wrote:
>There was one prior answer to this.  Here's another.
>
>There's a claim here that the problem statement(s) is/are too vague.  I'm a
>little worried that tightening up the problem definition along these 20
>vectors will give us such a tight problem statement that any solution is so
>targeted as to be of limited value.  The sweet spot we're looking for
>probably lies somewhere in between.
>
>Gmail's auto-formatting made a mess of the numbers as I went through this,
>so sorry if that confuses things.
>
>On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas  wrote:
>
>> I've said in multiple threads that the current problem both in the charter
>> and the problem draft are far too vague for us to address. Here are some
>> from me at least:
>>
>>1. Who are the victims? Just bulk senders? Are the bulk senders
>>signing using their domain?
>>
>> In my view, there are two: The receiver of the unwanted spam (that might
>not otherwise have been delivered), and the owner of the domain whose
>signature got replayed as it might now suffer a degraded reputation.
>
>>
>>1. If there are different types of senders who suffer from replay
>>attack reputation, are the attacks using the same or different techniques
>>to create the signed spam?
>>
>> I haven't heard much variance in the attack technique.  It's always
>something close to this:
>
>* send something that gets signed by a large operator to a single recipient
>I control
>* capture that signed message, assuming the signature still validates
>* replay it all I want from other servers
>
>>
>>1. Do senders filter outbound traffic for spam?
>>
>> I think it's safe to assume that the case we're most interested in does do
>this, but it seems to me that irrespective of the answer, the attack is
>working.
>
>>
>>1. Do spammers who get a piece of email signed by a sender also send
>>mail to target domains to see if it passes their filters?
>>
>> I would guess "yes", though perhaps not specifically as part of a replay
>campaign.  That is, they were doing this long before anyone claimed replay
>was a rising problem.
>
>>
>>1. What are the characteristics of the spammer wrt to the sending
>>domain? Are they brand new accounts or established ones?
>>
>> This one I don't have a guess about.  I would say "either".  Does this
>need to be known, or does it need to constrain the problem definition?
>
>>
>>1. Do sending domains keep track of users who are sending spam in the
>>eyes of their filters? Do they correlate that with other characteristics 
>> of
>>their users such as freshness?
>>
>> Also "either".
>
>>
>>1. Do senders pay any attention to the To domain?
>>
>> I can't imagine this being valuable signal, given the additional use of
>various other address fields.
>
>>
>>1. Do receivers pay attention to the To domain(s)?
>>
>> Same.
>
>>
>>1. Does the To domain spammers use remain more or less static, or do
>>they mutate at a high rate?
>>
>> The "To" field, or the RCPT TO(s) in the envelope?  It seems like the To
>field (if signed) never changes, or it's whatever the spammer wants it to
>be if it's not signed.  In the latter case, it's easy to make "To" and RCPT
>TO match, thwarting that check.
>
>>
>>1. Can we quantify the reputation bump (or hit) on the receiver from
>>these spam bursts? (I'm sure the spammers know the answer to this)
>>
>> I imagine this is a property of the spam campaign itself and the response
>it draws, and probably varies from one receiver to the next as reputation
>is their varying secret sauce.
>
>>
>>1. Do spammers with a replay server sign and/or set up SPF records for
>>their spam sending domain?
>>
>> Also "either".
>
>>
>>1. Do spammers provide an unsubscribe link which is typical on normal
>>email blasts? If not, is that unusual and/or against the rules of the bulk
>>provider? If so can the sender keep track of that?
>>
>> Do we need to know this to define the problem space?
>
>>
>>1. Can senders verify that opt-out links actually work especially for
>>new accounts?
>>
>> Same question.
>
>>
>>1. Can filters be adjusted at a more fine grain in the face of
>>different conditions? That is, accept a higher false positive rate in
>>certain conditions?
>>
>> This seems to me to be part of the answer we might provide rather than
>part of the problem definition.
>
>>
>>1. Are there receivers out there that treat an x= expired message
>>different than a missing or broken signature? It's ambiguous in the DKIM
>>text about that, I think.
>>
>> Right, DKIM doesn't require enforcement or even checking of "x=", other
>than if present it must be greater than the "t=" value.  OpenDKIM's library
>will consider the signature invalid and tell you this was the reason; the
>consumer is free to make whatever handling decision it wants based on
>that.  The filter is configurable.
>

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

[Scott Kitterman]

On March 19, 2023 6:57:13 PM UTC, Wei Chuang 
 wrote:
>On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins  wrote:
>
>> ...
>> 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.
>>
>
>Agreed for the most part.  While we can get mileage with the existing
>RFC6376 based tools such as header oversigning, "x=" expiry, and the other
>techniques mentioned, at some point the spammers will adapt.  And as
>Michael and the panelist have pointed out, RFC6376 inherently permits DKIM
>replay as a feature due to that separation between envelope and message.
>The main thing I would quibble with the panelist is the distinct break if
>we start validating parts of the envelope or interacting with transport, as
>whatever technique to be adopted will have to consider participation by
>unaware forwarders i.e. some sort of gradual adoption process likely with
>some sort of experiment.  Also I would argue we should break that wall
>between the message and the envelope and transport.  From where I sit, I
>see mail forwarding bit by bit breaking as spammers use forwarding as a
>general technique, and the mitigations put in place using the existing
>protocols are insufficient for the challenge.  The evidence is anecdotal
>since there aren't great tools to look at this at scale.

If we're going to deprecate indirect mail flows we should be explicit about it. 
 Standardizing protocol changes that make them look inherently suspicious while 
pretending that they are still supported is disingenuous and not the way to go 
about it.

As far as I have seen, none of the proposals that break the boundary between 
envelope and the message body can distinguish between 'good' and 'bad' indirect 
mail.

I do think we should, for the moment, continue to focus on the problem 
statement to see if we can come up with a technically distinct definition of 
the problem.

Scott K

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

Re: [Ietf-dkim] DKIM signature algorithms

[Scott Kitterman]

On Friday, March 10, 2023 2:32:36 PM EST Jan Dušátko wrote:
> Dear,
> I would like to recommend change/extend support of algorithms for DKIM
> signage. Last update of algorithms are in RFC 8463, still not widely
> supported.  Right now we facing issues with the long DKIM key
> distribution and lack of support, allowing the ECC signature can solve
> problem with key size.
> 
> Elliptic curve signatures:
> I would like to recommend not only Ed25519, but also Ed448. Thanks to
> clever design, signatures based on on that algorithms can avoid of nonce
> collisions. But this could be real risk for the DSS standard curve
> implementation.
> 
>| Key size |   Curve |Nonce | Security Equivalent
> 
> | Hash |
> 
> --+--+-+--+-+---
> ---+ Ed25519   | 255b | Twisted Edwards | Text+Key | 125b |   SHA256
> | Ed448 | 448b | Twisted Edwards | Text+Key | 224b | SHAKE256 |
> NIST P256 | 256b | Weierstrass |   Random | 128b |   SHA256 | NIST
> P384 | 384b | Weierstrass |   Random | 192b |   SHA384 | NIST P521
> | 521b | Weierstrass |   Random | 230b |   SHA512 |
> 
> RSA signatures:
> But the RSA signature, require extremely long private keys. To assure
> similar security equivalent, need to be at the least 12 times longer.
> But RSA have sub-exponential complexity.
> 
> Key size | Security Equivalent |
> -+-+
> 1024b | 96b |
> 2048b |112b |
> 3072b |128b |
> 4096b |160b |
> 
> The signature based on RSA has some issues, but based on key properties
> nobody will be able to decide between them. In case of change required,
> need to be mentioned i DKIM key. Use of k=rsa for PKCS#1 v 1.5 as
> default value or k=rsa-pss for PKCS#1 v 2.2 RSA-PSS are probably the
> only solution.
> PKCS#1 v 1.0, obsolete, has not been supported
> PKCS#1 v 1.5, obsolete, vulnerable by Bleichenbacher family of attacks
> PKCS#1 v 2.2 RSA-PSS (DSS standard), described in NIST FIPS 186-5
> 
> Support:
> EU directive eIDAS and ETSI standard ETSI TS 119312 support signatures
> based on RSA PKCS#1 v 1.5, RSA-PSS, ED25519, ED448, NIST P-256, NIST
> P-384, NIST P-521
> NIST FIPS 186-5 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS,
> ED25519, ED448, NIST P-256, NIST P-384, NIST P-521
> RFC 8446 TLS 1.3 support signatures based on RSA PKCS#1 v 1.5, RSA-PSS,
> ED25519, ED448, NIST P-256, NIST P-384, NIST P-521

Specifying more algorithms than we need is a hindrance to interoperability.  
We added ed25519 so that we would have a specified alternative if RSA suddenly 
became unusable.  In order to be interoperable, the signer and receiver both 
need to support the same algorithms.  

Today that common algorithm is RSA.  I've dual signed email with both RSA and 
ed25119 since even before the DCRUP working group published RFC 8463, but I 
don't recall having ever noticed receiving an ed25119 based DKIM signature.  
As you note, it's deployment has been sparse.  The solution to the lack of 
sufficient deployment for interoperability of an alternative to RSA is to push 
for ed25119 deployment, not to add more choices.

Scott K



___
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

[Scott Kitterman]

On Friday, March 10, 2023 9:14:05 AM EST Laura Atkins wrote:
> > On 9 Mar 2023, at 22:47, Michael Thomas  wrote:
> > 
> > On 3/7/23 4:09 AM, Laura Atkins wrote:
> >> 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.> 
> > What about solutions that have been tried but have drawbacks or are
> > ineffective? It would be nice to know what the current baseline is.
> In some respects that depends on what form the final document takes. If we
> do decide that the underlying problem is something that can be addressed
> with a protocol change, then we probably won’t mention mitigation steps
> that have been tried and either have drawbacks or are ineffective. If the
> outcome is a document that we looked at the problem and decided that the
> issue isn’t with the protocol and we recommend no protocol changes then I
> can see the work product being a discussion of non-protocol solution space.
> That would include different things folks have tried what works and what
> doesn’t work.

My suggestion is plan on both.

My takeaway from the rechartering discussions is that if there is a protocol 
solution to this problem, it will not be simple and will take quite some time 
to be effective since wide deployment would be needed.  As a result, there will 
be, at best, a significant period of time where whatever mitigations/work-
arounds that are available will be needed.  I think we should plan on 
documenting them regardless of the outcome of the protocol solution work.

Scott K


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

100% agree.  If this is the path we decide to go down, we can't really change 
the protocol for this.  It's advice on when/why to deal with X in a particular 
way.  Perhaps I was overly subtle, but that's why I described it as the 
practical effect.  I didn't mean to suggest a protocol change.

Scott K

On February 18, 2023 7:52:42 PM UTC, Barry Leiba  
wrote:
>I think that changing this to SHOULD is the wrong approach.  An
>Applicability Statement might well give advice, possibly at the SHOULD
>level, that goes beyond this and discusses use cases, but the base
>protocol uses MAY for a good reason, and at the protocol level it
>should stay that way.
>
>Barry
>
>On Fri, Feb 17, 2023 at 8:02 PM Murray S. Kucherawy  
>wrote:
>>
>> On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman  
>> wrote:
>>>
>>> Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think 
>>> the practical effect as described in protocol terms would be to change the 
>>> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions.  Not 
>>> that I'd expect to see this appear in a protocol document (maybe some kind 
>>> of applicability statement).
>>
>>
>> Beyond this SHOULD, I think we need to consider whether the caller needs to 
>> be told specifically when a failure occurs for this reason.  Right now an 
>> implementation might return just a PERMFAIL without noting that it's because 
>> of "x=" versus the signature failing for some other reason.  Should the 
>> caller be given this extra detail to enhance the decision tree, or will this 
>> just complicate things?
>>
>> I think, for instance, libopendkim does identify the reason for the failure, 
>> but I'm not sure whether any consumers of that API make use of that detail 
>> beyond maybe logging it.
>>
>> -MSK
>
>___
>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] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think the 
practical effect as described in protocol terms would be to change the MAY to 
SHOULD under X conditions and SHOULD NOT under !X conditions.  Not that I'd 
expect to see this appear in a protocol document (maybe some kind of 
applicability statement).

It does create a circumstance where indirect mail flows look inherently less 
good (since they take longer), which I don't like.  On the other hand, if X is 
set more than a minute or so in the future, mostly what is affected is mail 
that is delayed in transit, direct or indirect and maybe that's okay.

Scott K

On February 17, 2023 5:22:37 PM UTC, "Murray S. Kucherawy" 
 wrote:
>On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba  wrote:
>
>> I like this approach: if the issue is that an "expired" signature is
>> treated as unsigned, I think we have an unacceptable level of false
>> positives.  But if the fact that a signature is valid but expired is
>> simply another factor in the decision, I think we might be OK, keeping
>> in mind that "x=" is purely advice to the validator.  To *really*
>> expire a signature, one has to stop publishing the key associated with
>> the selector.
>>
>
>One thing that would impede the success of this approach is whether current
>implementations make the distinction between "invalid" and "valid but
>expired", and for those that do not, how much churn and for how long it
>would take to make that change to the ecosystem.
>
>-MSK

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

This could apply to other things like over some rate limit threshold or the 
reputation based approach I suggested as well.  The key thing that's relevant 
to the problem statement is that the problem is how the reputation impact of 
the signature is applied, not signature continues to validate after replay.

Scott K

On February 16, 2023 10:13:03 PM UTC, Barry Leiba  
wrote:
>I like this approach: if the issue is that an "expired" signature is
>treated as unsigned, I think we have an unacceptable level of false
>positives.  But if the fact that a signature is valid but expired is
>simply another factor in the decision, I think we might be OK, keeping
>in mind that "x=" is purely advice to the validator.  To *really*
>expire a signature, one has to stop publishing the key associated with
>the selector.
>
>Barry
>
>On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman  
>wrote:
>>
>>
>>
>> On February 16, 2023 9:21:51 PM UTC, Michael Thomas  wrote:
>> >
>> >On 2/16/23 12:56 PM, Barry Leiba wrote:
>> >>>> Okay.  What's the value for X - T that prevents this problem, but 
>> >>>> doesn't cause DKIM signatures of "normal" mail to fail?
>> >>> There's not one "right" value; we're talking about distributions
>> >>> of timings for normal mail vs. replay, and yes, there's some
>> >>> overlap there. In practice I've seen many signers choose
>> >>> expirations in the range of 1hr to a few days.  1hr can be very
>> >>> good at limiting the opportunity for high volume replay, but I
>> >>> estimate "normal" signature breakage at that level is on the
>> >>> order of 0.1%. 24hr is probably effectively zero breakage, but
>> >>> with greater opportunity for replay.
>> >> I think you're way off on these numbers, especially for the 1-hour
>> >> case.  While normal circumstances get mail delivery in less than an
>> >> hour, I have seen *many* cases of legitimate mail delayed by hours --
>> >> sometimes quite a few hours.  I would consider anything less than two
>> >> days to be unacceptable, and with that sort of gap you don't do much
>> >> to prevent a spam blast.
>> >
>> >I dunno, I would think it has to do with how much of a boost reputation is 
>> >actually giving deliverability. For typical marketing email that's not too 
>> >spammy maybe it doesn't make much difference? Adding signatures and a SPF 
>> >record is pretty easy to do these days, so it's sort of a no-brainer to 
>> >just do it. But if some small percentage with slow delivery fall through 
>> >the cracks, how adverse is that to delivery, assuming they don't have a 
>> >p=reject policy? That seems like it should be a pretty measurable thing for 
>> >an ESP.
>> >
>> >Sounds like something that Evan might know. Actually it might well be worth 
>> >adding that kind of estimate to the problem statement to judge how much of 
>> >a problem it is. What we have now is very hand waving and makes it 
>> >impossible to judge about how heroic we need to be.
>>
>> I think this highlights a key consideration that's easy to forget.  
>> Ultimately the issue is not that a 'bad' message was delivered, but that a 
>> 'bad' message got the benefit of whatever positive reputation was provided 
>> by the signature.  If one decides under X circumstances we will ignore a 
>> DKIM signature for Y purposes, then the negative impact of that is far less 
>> than that associated with rejecting the message, so we can probably tolerate 
>> more false positives.
>>
>> Scott K
>>
>> ___
>> 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] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 16, 2023 9:21:51 PM UTC, Michael Thomas  wrote:
>
>On 2/16/23 12:56 PM, Barry Leiba wrote:
 Okay.  What's the value for X - T that prevents this problem, but doesn't 
 cause DKIM signatures of "normal" mail to fail?
>>> There's not one "right" value; we're talking about distributions
>>> of timings for normal mail vs. replay, and yes, there's some
>>> overlap there. In practice I've seen many signers choose
>>> expirations in the range of 1hr to a few days.  1hr can be very
>>> good at limiting the opportunity for high volume replay, but I
>>> estimate "normal" signature breakage at that level is on the
>>> order of 0.1%. 24hr is probably effectively zero breakage, but
>>> with greater opportunity for replay.
>> I think you're way off on these numbers, especially for the 1-hour
>> case.  While normal circumstances get mail delivery in less than an
>> hour, I have seen *many* cases of legitimate mail delayed by hours --
>> sometimes quite a few hours.  I would consider anything less than two
>> days to be unacceptable, and with that sort of gap you don't do much
>> to prevent a spam blast.
>
>I dunno, I would think it has to do with how much of a boost reputation is 
>actually giving deliverability. For typical marketing email that's not too 
>spammy maybe it doesn't make much difference? Adding signatures and a SPF 
>record is pretty easy to do these days, so it's sort of a no-brainer to just 
>do it. But if some small percentage with slow delivery fall through the 
>cracks, how adverse is that to delivery, assuming they don't have a p=reject 
>policy? That seems like it should be a pretty measurable thing for an ESP.
>
>Sounds like something that Evan might know. Actually it might well be worth 
>adding that kind of estimate to the problem statement to judge how much of a 
>problem it is. What we have now is very hand waving and makes it impossible to 
>judge about how heroic we need to be.

I think this highlights a key consideration that's easy to forget.  Ultimately 
the issue is not that a 'bad' message was delivered, but that a 'bad' message 
got the benefit of whatever positive reputation was provided by the signature.  
If one decides under X circumstances we will ignore a DKIM signature for Y 
purposes, then the negative impact of that is far less than that associated 
with rejecting the message, so we can probably tolerate more false positives.

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 16, 2023 8:03:01 PM UTC, Evan Burke  
wrote:
>On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman 
>wrote:
>
>>
>> On February 16, 2023 6:10:39 PM UTC, Evan Burke > 40mailchimp@dmarc.ietf.org> wrote:
>> >The biggest current problem with replay is that it happens in bulk, at
>> >substantial scale. x= is effective against that because it takes time to
>> >send millions of messages.  Is it perfect? No. But it's not difficult to
>> >choose between 10,000 replays using my domain vs. millions.
>>
>> Okay.  What's the value for X - T that prevents this problem, but doesn't
>> cause DKIM signatures of "normal" mail to fail?
>>
>>
>There's not one "right" value; we're talking about distributions of timings
>for normal mail vs. replay, and yes, there's some overlap there. In
>practice I've seen many signers choose expirations in the range of 1hr to a
>few days.  1hr can be very good at limiting the opportunity for high volume
>replay, but I estimate "normal" signature breakage at that level is on the
>order of 0.1%. 24hr is probably effectively zero breakage, but with greater
>opportunity for replay.
>
>I understand the pushback; this is a list to talk about a standard, and
>standards tend to be a lot more binary in their functionality, so to speak.
>Maybe you're not receptive to a more practical solution - that's fine, I
>respect that - but I think there may be others here who are more open to
>that kind of approach.

I'm not necessarily opposed to going down this kind of path, but it should be 
with eyes open on the side effects.  I'm all about practical, but in my book 
that includes not creating an attractive nuisance that causes more problems 
than it solves (not saying that X= is that, I don't have much of an opinion 
yet).

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 16, 2023 6:10:39 PM UTC, Evan Burke 
 wrote:
>On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy 
>wrote:
>
>>
>> If my prior formulation is right, i.e., that the attack only takes a few
>> seconds to complete, what "x=" value are we proposing that will work here
>> without also bringing undesirable side effects?
>>
>>
>The biggest current problem with replay is that it happens in bulk, at
>substantial scale. x= is effective against that because it takes time to
>send millions of messages.  Is it perfect? No. But it's not difficult to
>choose between 10,000 replays using my domain vs. millions.

Okay.  What's the value for X - T that prevents this problem, but doesn't cause 
DKIM signatures of "normal" mail to fail?

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On February 15, 2023 10:18:50 PM UTC, "Murray S. Kucherawy" 
 wrote:
>On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman 
>wrote:
>
>> Any reputation based solution does have down scale limits.  Small mail
>> sources
>> (such as your random Nebraska forwarder) generally will have no reputation
>> vice a negative one and so wouldn't get penalized in a scheme like the one
>> I
>> suggested.  This does, however, highlight where the performance challenge
>> is.
>> We've moved it from duplicate detection to rapid assessment of reputation
>> for
>> hosts that have sudden volume increases.
>>
>
>I wonder if this could be separated into "reputation" and "hosts that have
>sudden volume increases".
>
>Reputation is hard.  Large operators spend a lot of R time coming up with
>algorithms that accurately (for some value thereof) compute the reputation
>it should associate with an identity.  That investment means they're not
>inclined to share that secret sauce.  Small operators without those
>resources long for an open source solution, or a cheap or free service from
>which they can reliably get reputation data.  Companies that offer
>reputation data for public consumption have been sued out of existence by
>people that get marked as suspect, so really good ones don't seem to abound
>last I checked.
>
>There's a lot less secret sauce involved in the latter.  It would be
>interesting to see if some simple recordkeeping of this nature could make a
>dent in the problem space we're discussing.  But that might just encourage
>further distribution of the attack to avoid detection.

I think it could, but it has its own scaling problems.

Further distribution has two sides:

If I have multiple hosts (for any of the many reasons one does) and the 
attacker hits all of them with some fraction of the attack volume, that doesn't 
materially increase the cost of the attack.

If I can rapidly share rate data among my hosts so that distributing volume 
among them doesn't help avoid volume detection, then that either raises the 
cost of the attack (need more IP addresses to send from) or reduces it's 
effectiveness (messages blocked due to being over rate).  Either of those 
results are good things, but whatever the process is, it's no longer simple.

This is the flip side of reputation in a way.  Technically easy for small 
domains, but hugely harder at any significant scale.

Scott K

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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On Wednesday, February 15, 2023 5:23:34 AM EST Alessandro Vesely wrote:
> On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote:
> > On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:
> >> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:
> >>> On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:
> >>>> Have you considered something like rate limiting on the receiver side
> >>>> for
> >>>> things with duplicate msg-id's? Aka, a tar pit, iirc?
> >> 
> >> I believe Yahoo does currently use some sort of count-based approach to
> >> detect replay, though I'm not clear on the details.
> >> 
> >>>> As I recall that technique is sometimes not suggested because (a) we
> >>>> can't
> >>>> come up with good advice about how long you need to cache message IDs
> >>>> to
> >>>> watch for duplicates, and (b) the longer that cache needs to live, the
> >>>> larger of a resource burden the technique imposes, and small operators
> >>>> might not be able to do it well.
> >>> 
> >>> At maximum, isn't it just the x= value? It seems to me that if you don't
> >>> specify an x= value, or it's essentially infinite, they are saying they
> >>> don't care about "replays". Which is fine in most cases and you can just
> >>> ignore it. Something that really throttles down x= should be a tractable
> >>> problem, right?
> 
> The ration between duplicate count and x= is the spamming speed.
> 
> >>> But even at scale it seems like a pretty small database in comparison to
> >>> the overall volume. It's would be easy for a receiver to just prune it
> >>> after a day or so, say.
> >> 
> >> I think count-based approaches can be made even simpler than that, in
> >> fact.
> >> I'm halfway inclined to submit a draft using that approach, as time
> >> permits.> 
> > I suppose if the thresholds are high enough, it won't hit much in the way
> > of legitimate mail (as an example, I anticipate this message will hit at
> > least hundreds of mail boxes at Gmail, but not millions), but of course
> > letting the first X through isn't ideal.
> 
> Scott's message hit my server exactly once.  Counting is a no-op for small
> operators.
> 
> > If I had access to a database of numerically scored IP reputation values
> > (I
> > don't currently, but I have in the past, so I can imagine this at least),
> > I
> > think I'd be more inclined to look at the reputation of the domain as a
> > whole (something like average score of messages from an SPF validated
> > Mail From, DKIM validated d=, or DMARC pass domain) and the reputation of
> > the IP for a message from that domain and then if there was sufficient
> > statistical confidence that the reputation of the IP was "bad" compared
> > to the domain's reputation I would infer it was likely being replayed and
> > ignore the signature.
> Some random forwarder in Nebraska can be easily mistaken for a spammer that
> way.  Reputation is affected by email volume.  Even large operators have
> little knowledge of almost silent MTAs.
> 
> Having senders' signatures transmit the perceived risk of an author would
> contribute an additional evaluation factor here.  Rather than discard
> validated signatures, have an indication to weight them.  (In that respect,
> let me note the usage of ARC as a sort of second class DKIM, when the
> signer knows nothing about the author.)

Any reputation based solution does have down scale limits.  Small mail sources 
(such as your random Nebraska forwarder) generally will have no reputation 
vice a negative one and so wouldn't get penalized in a scheme like the one I 
suggested.  This does, however, highlight where the performance challenge is.  
We've moved it from duplicate detection to rapid assessment of reputation for 
hosts that have sudden volume increases.

I think that's fine as that's not at all a problem that's unique to this 
challenge and ultimately, I think if replay attacks end up more complicated 
because instead of blasting 1,000,000 messages from one host they have to 
trickle 1.000 messages from 1,000 hosts it's a win.

I don't think this is a problem that's going to have a singular mechanical 
solution to that makes it go away.  This is substantially about making this 
particular technique less effective so maybe they move on to something else or 
at least less bad stuff gets delivered.

> > I think that approaches the same effect as a "too many dupes" approach
> > without the threshold problem.  It does require reputation data, but I
> > assume any entity of a non-trivial size either has access to their own or
> > can buy it from someone else.
> 
> DNSWLs exist.

I'm not sure how that's relevant.  Please expand on this if you think it's 
important.

Scott K


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

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Scott Kitterman]

On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:
> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas  wrote:
> > On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas  wrote:
> >> Have you considered something like rate limiting on the receiver side for
> >> things with duplicate msg-id's? Aka, a tar pit, iirc?
> 
> I believe Yahoo does currently use some sort of count-based approach to
> detect replay, though I'm not clear on the details.
> 
> > As I recall that technique is sometimes not suggested because (a) we can't
> > come up with good advice about how long you need to cache message IDs to
> > watch for duplicates, and (b) the longer that cache needs to live, the
> > larger of a resource burden the technique imposes, and small operators
> > might not be able to do it well.
> > 
> > At maximum, isn't it just the x= value? It seems to me that if you don't
> > specify an x= value, or it's essentially infinite, they are saying they
> > don't care about "replays". Which is fine in most cases and you can just
> > ignore it. Something that really throttles down x= should be a tractable
> > problem, right?
> > 
> > But even at scale it seems like a pretty small database in comparison to
> > the overall volume. It's would be easy for a receiver to just prune it
> > after a day or so, say.
> 
> I think count-based approaches can be made even simpler than that, in fact.
> I'm halfway inclined to submit a draft using that approach, as time permits.

I suppose if the thresholds are high enough, it won't hit much in the way of 
legitimate mail (as an example, I anticipate this message will hit at least 
hundreds of mail boxes at Gmail, but not millions), but of course letting the 
first X through isn't ideal.

If I had access to a database of numerically scored IP reputation values (I 
don't currently, but I have in the past, so I can imagine this at least), I 
think I'd be more inclined to look at the reputation of the domain as a whole 
(something like average score of messages from an SPF validated Mail From, 
DKIM validated d=, or DMARC pass domain) and the reputation of the IP for a 
message from that domain and then if there was sufficient statistical 
confidence 
that the reputation of the IP was "bad" compared to the domain's reputation I 
would infer it was likely being replayed and ignore the signature.

I think that approaches the same effect as a "too many dupes" approach without 
the threshold problem.  It does require reputation data, but I assume any 
entity of a non-trivial size either has access to their own or can buy it from 
someone else.

Scott K


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

Re: [Ietf-dkim] replay clues

[Scott Kitterman]

On February 11, 2023 5:23:39 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas  wrote:
>
>> I've always thought that the likelihood of a protocol level solution for
>> this issue is pretty close to zero if not zero. The various proposed
>> solutions in the problem draft haven't given me any reason to dissuade
>> me of that notion.
>>
>> That said, I think that we might be able to catalog some clues that
>> something is suspicious which taken with many other clues can be used to
>> by a receiver to make an ultimate decision of spamminess. A good example
>> is the unsigned To: and Subject: lines. Even if it's strictly allowed by
>> the spec, that doesn't mean it's not suspect. It could be really useful
>> to collect this clues as input signals to a larger preponderance of
>> evidence.
>>
>
>Authentication-Results already noted the idea that a signature, even a
>valid one, might still be considered not acceptable to the verifier and
>reported differently for one reason or another.  An unsigned Subject was
>the classic example.
>
>Dealing with this in A-R nicely removes it from being dealt with at the
>protocol level, where I would argue this sort of logic doesn't belong.

This is pretty close to the example in RFC 8601, section 2.4 for a 'policy' 
ptype result.

Scott K

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

Re: [Ietf-dkim] Chartering update

[Scott Kitterman]

On February 4, 2023 5:20:27 PM UTC, Evan Burke  wrote:
>On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker  wrote:
>
>> On 2/4/2023 8:41 AM, Scott Kitterman wrote:
>> > I've yet to see a description of the problem that's distinguishable from
>> a mailing list that preserves DKIM signatures.
>>
>> That seems like an especially healthy discussion to have. Focusing on,
>> and seeking convergence about, the nature of the differences, could help
>> consideration of the ways to counteract replay.
>>
>
>In a word? Scale.  Are there any mailing lists in existence that send tens
>of millions of messages a day, or more, in a way that preserves the
>original DKIM sig?

How does that attribute relate to DKIM protocol changes?

Scott K

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

Re: [Ietf-dkim] Chartering update

[Scott Kitterman]

On February 4, 2023 8:38:46 AM UTC, "Murray S. Kucherawy"  
wrote:
>On Thu, Feb 2, 2023 at 3:26 PM Michael Thomas  wrote:
>
>> I guess my concern is more along the lines of what solutions *aren't*.
>> There are a bunch of drafts trying to tie the envelope to the email and I
>> think there needs to be a meta discussion of whether that is a good idea or
>> not in general. Frankly that seems like an email architecture question not
>> just a DKIM question. It would be nice to know if there is precedent for
>> that in the larger community and what the implications are. Fwiw, I don't
>> really consider the DMARC "alignment" as tickling the larger question
>> because all it is doing is reporting on it, but a case could certainly be
>> made that it is.
>>
>
>For what it's worth, the proposals that seek to offer a binding between the
>envelope and the message aren't making any sort of mandatory change to
>DKIM.  It's entirely optional to the signer whether to make that connection
>using one of those proposals; conventional DKIM isn't being taken off the
>table.  For instance, the idea I put forward suggests using two signatures,
>one that makes the binding and a typical one that does not.  Such a tactic
>would leave the original signal about a message intact while possibly
>providing more, which seems to me to be strictly an improvement.

While literally true, I don't think it's accurate (if you assume the proposal 
gets significant uptake).

If such a proposal gets a lot of traction, then the lack of such an additional 
signature becomes a negative sign about the message, which damages a lot of 
indirect mail flows.  If this isn't the case, then there's no value in the 
additional signature.

Without some way to distinguish 'good' replay, from 'bad', there will 
inevitably by negative side effects.

I've yet to see a description of the problem that's distinguishable from a 
mailing list that preserves DKIM signatures.

Scott K

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

Re: [Ietf-dkim] Chartering update

[Scott Kitterman]

There is an existing draft of a problem statement, so there's at least a 
starting point to consider.  I think discussion about what's needed is probably 
more useful relative to a specific draft than in the abstract:

https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/

Scott K

On February 2, 2023 11:26:36 PM UTC, Michael Thomas  wrote:
>
>On 2/2/23 3:18 PM, Tim Wicinski wrote:
>> the problem statement should just bang out the problems in all their ugly 
>> glory.
>> it should not attempt to suggest solutions, as that would be up to the 
>> working group
>> to hammer out.
>> 
>> (this is my opinion and of course am probably totally off base)
>
>I guess my concern is more along the lines of what solutions *aren't*. There 
>are a bunch of drafts trying to tie the envelope to the email and I think 
>there needs to be a meta discussion of whether that is a good idea or not in 
>general. Frankly that seems like an email architecture question not just a 
>DKIM question. It would be nice to know if there is precedent for that in the 
>larger community and what the implications are. Fwiw, I don't really consider 
>the DMARC "alignment" as tickling the larger question because all it is doing 
>is reporting on it, but a case could certainly be made that it is.
>
>Mike
>
>> 
>> 
>> On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas  wrote:
>> 
>> 
>> On 2/2/23 2:16 PM, Tim Wicinski wrote:
>>> 
>>> 
>>> On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas  wrote:
>>> 
>>> 
>>> So here is what sticks in my craw. I think I brought up the
>>> problem
>>> statement, but maybe somebody else did before me. It's easy
>>> to say "here
>>> is the problem, fix it!" without any context to what any
>>> proposed fixes
>>> might break. It would be really bad imo to slap out a minimal
>>> problem
>>> statement and then proceed to solutions without any analysis
>>> of what any
>>> solution space should and should not do at a protocol level.
>>> I guess
>>> that's a little bit more requirement-y, but I'm not exactly
>>> sure what
>>> process-wise I'm asking for. DKIM is extremely widely
>>> deployed so we
>>> need to be really careful about not breaking existing
>>> practices or doing
>>> unnatural acts that have implications to the wider email
>>> community.
>>> 
>>> 
>>> My feeling part of the problem statement will be to document
>>> various solutions
>>> and how testing should be done and what to look for (breaking
>>> existing practice would
>>> be key).
>>> 
>>> It may be that one solution is protocol rev which works outside
>>> of current dkim.
>>> We wrestled with this in the early days of DPRIVE - adding
>>> additional encryption onto
>>> DNS was viewed in a similar manner.
>>> 
>>> 
>> I don't know if there is a formal IETF definitely of what
>> constitutes a problem statement but it's easy to imagine a problem
>> statement that... just states the problem. I don't think we have
>> discussed what should actually be in scope for this problem
>> statement. I guess we could suss that out before there are chairs,
>> but obviously we'd need them to make consensus calls.
>> 
>> Mike
>> 

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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On December 24, 2022 8:22:45 PM UTC, Michael Thomas  wrote:
>
>On 12/23/22 10:25 PM, Murray S. Kucherawy wrote:
>> On Fri, Dec 23, 2022 at 1:17 PM Michael Thomas  wrote:
>> 
>> Shouldn't the problem statement explore whether there is a
>> plausible tractable solution before it moves on to protocol work?
>> That is, if there isn't a tractable solution the wg should go into
>> hibernation again. I'm pretty sure that I brought this quite a
>> while ago. Of if not the problem statement, afterward just
>> evaluating for a go-no go decision before starting any work.
>> 
>> 
>> A working group is implicitly allowed to admit defeat if it decides it can't 
>> solve the problem it thought it was supposed to solve.  DBOUND comes to 
>> mind; it deadlocked on whether the problem was tractable, or even well 
>> enough understood, to advance a consensus protocol solution, and closed 
>> without producing anything.
>> 
>> I don't think the charter has to say that expressly. It's part of the 
>> process.  The charter stipulates an ordering, and I think that's sufficient.
>> 
>I think it's worthwhile for the charter to have a step which is to determine 
>whether the problem is 1) tractable and 2) requires IETF to do something. If 
>either of those are false, the charter should say that it is completed. There 
>has been quite a bit of skepticism expressed (and not just by me) about both 
>of those points so it would be good to have a checkpoint before doing 
>something to do something.


+1.  I think it's a mistake to assume deciding not to make protocol changes by 
the group is a failure. A reasoned decision that additional protocol changes 
would not be helpful would be a success, if that's where the facts lead us (I 
have opinions on this, but have reached no definitive conclusions).

Scott K

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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On December 8, 2022 12:26:45 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker  wrote:
>
>> As appealing as the AS concept is, I've never been clear how operationally
>> useful they are.
>>
>> More to the current point, if the anti-replay work to be done benefits
>> from a position on transit vs. non-transit, then including it directly in
>> an anti-replay specification would be more helpful than in a separate AS.
>>
>Fair enough.  Does the charter need to say that a revision to best
>practices, relative to the replay problem, might be a possible output?
>It's within the realm of possibility that no protocol work comes out of
>this, but a "checkpoint" about current realities might be good to publish
>in that case.

Yes.  It's not a given that protocol changes are the only non-failure outcomes.

Scott K

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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Saturday, December 3, 2022 2:35:55 PM EST Jon Callas wrote:
> > On Dec 3, 2022, at 11:01, Stephen Farrell 
> > wrote:
> > 
> > One nit though, that you should feel free to ignore if it
> > was discussed already - the phrase "in a secure way" doesn't
> > quite capture what the DKIM WG was trying to produce, e.g.
> > we consider unsigned DNS fine for DKIM public keys, even
> > though that'd not be described as "secure."
> > 
> > Maybe s/in a secure way/using a lightweight cryptographic
> > mechanism/ would be better? But again, it's a nit.
> 
> Agreed, and we need some other weasel word than "lightweight" because there
> are lots of people working on "lightweight" symmetric ciphers. Something
> like "appropriate"?
> 
> Y'all know this is one of the many bees in my bonnet -- DKIM doesn't need a
> signature that is secure for a year (or more), it needs one that is secure
> for somewhere between a minute and a week.
> 
> Moreover, one of the ways that we could deal with some of the knock-on
> issues of not wanting DKIM to be a non-repudiation system (the Podesta
> Problem) is to use signatures that could be  forged by someone who put a
> CPU(s)-week's effort into it after the fact.
> 
> Even if we never get around to the actual issues, we don't want to cut off
> someone in the future at the knees.

If you want to avoid such problems, you can do so already.  Script your mail 
server/DNS to publish a new key at a new selector weekly and then at the end 
of the second week, replace the public key with the private key.  That will 
guarantee that any signatures more than two weeks old can be repudiated, but 
still work for normal email transit times.

IETF doesn't need to do anything for domains which which to create DKIM 
signatures with a very limited temporal validity.

Scott K


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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Saturday, December 3, 2022 5:33:27 AM EST Alessandro Vesely wrote:
> On Sat 03/Dec/2022 07:38:24 +0100 Murray S. Kucherawy wrote:
> > I've placed what I believe is the text that is closest to consensus in the
> > datatracker:
> > 
> > https://datatracker.ietf.org/doc/charter-ietf-dkim/
> > 
> > Please provide comments or criticism soon.
> 
> Please add the other Wei's I-D:
> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/

I agree.

I still think limiting the backward compatibility language to DKIM is too 
narrow.

Scott K 


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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On November 28, 2022 8:17:21 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
>wrote:
>
>> I would add mention of the problem statement draft.  I think it may turn
>> out
>> to be the most important of the ones we have now.
>>
>
>Do you mean: Mention it as a mandatory deliverable?
>
>Should we still produce that document even if we conclude replay can't be
>solved?

I had been thinking about it as an input, since that document more fully 
describes the problem.
>
>> I still think "compatible with DKIM's broad deployment" is too narrow.
>> Also,
>> I think it's one reasonable conclusion the group might reach is that the
>> cure
>> is worse than the disease and a resolution along the lines of "remove
>> signatures during delivery" and "be more careful about what you sign
>> because
>> signing bad things will hurt your domain's reputation" may be the most
>> appropriate approach.
>>
>
>Yes, I think it's always implied that a working group can throw in the
>towel if consensus is to do that.  I've never seen it spelled out in a
>charter that this is an available option, but we can make it explicit if
>people feel doing so would help set the scope.

As long as there's a consensus in the group for a solution, even if it's not 
new protocol, I don't think that's giving up.  If we quit because we can't 
reach rough consensus on a way forward, I think that could reasonably be 
characterized as throwing in the towel.
>
>> How about instead of "The DKIM working group will produce one or more
>> technical specifications that describe the abuse and propose
>> replay-resistant
>> mechanisms that are compatible with DKIM's broad deployment" we say "The
>> DKIM
>> working group will evaluate potential mechanisms to mitigate this attack
>> and
>> produce one or more technical specifications that describe the abuse and
>> propose improvements which, consistent with compatibility with DKIM's
>> broad
>> deployment and general email protocols, will reduce the impact of replay
>> attacks".
>>
>
>I think those say approximately the same thing, so I'm fine with either.
>
I agree it's not a large difference, but I'd prefer to be more explicit about 
general email compatibility.

Thanks,

Scott K

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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On November 28, 2022 7:22:33 AM UTC, Wei Chuang 
 wrote:
>On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
>wrote:
>
>> On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote:
>> > Hi folks,
>> >
>> > Area Director hat on here:
>> >
>> > The discussion Barry kicked off has been interesting, but it has strayed
>> > (and mea culpa, in part, because the material is interesting) from the
>> work
>> > of discussing a charter.
>> >
>> > I've set the stage for re-chartering in the system, and now we need some
>> > charter text.  Dave and Barry submitted text, which I've synthesized into
>> > what's below.  Let's keep this thread just to discussion the charter
>> text;
>> > if you want to continue to debate the technical solutions or problem
>> space,
>> > please start other threads or reply to the other existing ones.
>> >
>> > Here's my run at a charter; please provide suggestions or comments, or
>> tell
>> > us if you think it's ready to go.  It's a variant of Barry's version with
>> > parts of Dave's merged in.  I've kept the list of candidate documents as
>> a
>> > starting point; the WG doesn't actually have to use any of them if that's
>> > where consensus lands.
>> >
>> > But let's figure out consensus on a charter before we try to hammer out
>> > consensus on solutions.
>> >
>> > -MSK
>> >
>> > --
>> >
>> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
>> > using a digital signature to associate a domain identity with an email
>> > message in a secure way, and to assure receiving domains that the message
>> > has
>> > not been altered since the signature was created.  Receiving systems
>> > can use this information as part of their message-handling decision.
>> > This can help reduce spam, phishing, and other unwanted or malicious
>> > email.
>> >
>> > A DKIM-signed message can be re-posted, to a different set of recipients,
>> > without
>> > disturbing the signature's validity.  This can be used to confound the
>> > engines that
>> > identify abusive content.  RFC 6376 identified a risk of these "replay"
>> > attacks, but
>> > at the time did not consider this to be a problem in need of a solution.
>> > Recently,
>> > the community has decided that it has become enough of a problem to
>> warrant
>> > being revisited.
>> >
>> > The DKIM working group will produce one or more technical specifications
>> > that
>> > describe the abuse and propose replay-resistant mechanisms that are
>> > compatible
>> > with DKIM's broad deployment.  The working group may produce documents
>> > describing
>> > relevant experimental trials first.
>> >
>> > Current proposals include the following drafts:
>> >
>> >  - draft-bradshaw-envelope-validation-extension-dkim
>> >  - draft-chuang-replay-resistant-arc
>> >  - draft-gondwana-email-mailpath
>> >  - draft-kucherawy-dkim-anti-replay
>> >
>> > The working group may adopt or ignore these as it sees fit.
>>
>> I would add mention of the problem statement draft.  I think it may turn
>> out
>> to be the most important of the ones we have now.
>
>
>+1 (granted my partiality).  Hopefully it can provide helpful context and
>framing device.
>
>
>> I still think "compatible with DKIM's broad deployment" is too narrow.
>> Also,
>> I think it's one reasonable conclusion the group might reach is that the
>> cure
>> is worse than the disease and a resolution along the lines of "remove
>> signatures during delivery" and "be more careful about what you sign
>> because
>> signing bad things will hurt your domain's reputation" may be the most
>> appropriate approach.
>
>
>> How about instead of "The DKIM working group will produce one or more
>> technical specifications that describe the abuse and propose
>> replay-resistant
>> mechanisms that are compatible with DKIM's broad deployment" we say "The
>> DKIM
>> working group will evaluate potential mechanisms to mitigate this attack
>> and
>> produce one or more technical specifications that describe the abuse and
>> propose improvements which, consistent with compatibility with DKIM's
>> broad
>> deployment and general email protocols, will reduce the impact of replay
>> attacks".
>>
>>
>On this I'm more with the MSK version, that we ought to create a
>specification.  To me at least, the problem with DKIM replay is that it is
>indistinguishable to a receiver from other benign forwarding flows.  I
>believe the proposed drafts help us do this though different approaches.

My proposal doesn't preclude that.  I'm not convinced that the problem is 
reasonably solvable and a new specification may not be appropriate.  Let's not 
assume we know more than we do at this point.

I am, however, more worried about the compatibility language, so I could live 
with that.

Scott K

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

Re: [Ietf-dkim] Rechartering

[Scott Kitterman]

On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote:
> Hi folks,
> 
> Area Director hat on here:
> 
> The discussion Barry kicked off has been interesting, but it has strayed
> (and mea culpa, in part, because the material is interesting) from the work
> of discussing a charter.
> 
> I've set the stage for re-chartering in the system, and now we need some
> charter text.  Dave and Barry submitted text, which I've synthesized into
> what's below.  Let's keep this thread just to discussion the charter text;
> if you want to continue to debate the technical solutions or problem space,
> please start other threads or reply to the other existing ones.
> 
> Here's my run at a charter; please provide suggestions or comments, or tell
> us if you think it's ready to go.  It's a variant of Barry's version with
> parts of Dave's merged in.  I've kept the list of candidate documents as a
> starting point; the WG doesn't actually have to use any of them if that's
> where consensus lands.
> 
> But let's figure out consensus on a charter before we try to hammer out
> consensus on solutions.
> 
> -MSK
> 
> --
> 
> Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> using a digital signature to associate a domain identity with an email
> message in a secure way, and to assure receiving domains that the message
> has
> not been altered since the signature was created.  Receiving systems
> can use this information as part of their message-handling decision.
> This can help reduce spam, phishing, and other unwanted or malicious
> email.
> 
> A DKIM-signed message can be re-posted, to a different set of recipients,
> without
> disturbing the signature's validity.  This can be used to confound the
> engines that
> identify abusive content.  RFC 6376 identified a risk of these "replay"
> attacks, but
> at the time did not consider this to be a problem in need of a solution.
> Recently,
> the community has decided that it has become enough of a problem to warrant
> being revisited.
> 
> The DKIM working group will produce one or more technical specifications
> that
> describe the abuse and propose replay-resistant mechanisms that are
> compatible
> with DKIM's broad deployment.  The working group may produce documents
> describing
> relevant experimental trials first.
> 
> Current proposals include the following drafts:
> 
>  - draft-bradshaw-envelope-validation-extension-dkim
>  - draft-chuang-replay-resistant-arc
>  - draft-gondwana-email-mailpath
>  - draft-kucherawy-dkim-anti-replay
> 
> The working group may adopt or ignore these as it sees fit.

I would add mention of the problem statement draft.  I think it may turn out 
to be the most important of the ones we have now.  

I still think "compatible with DKIM's broad deployment" is too narrow.  Also, 
I think it's one reasonable conclusion the group might reach is that the cure 
is worse than the disease and a resolution along the lines of "remove 
signatures during delivery" and "be more careful about what you sign because 
signing bad things will hurt your domain's reputation" may be the most 
appropriate approach.

How about instead of "The DKIM working group will produce one or more 
technical specifications that describe the abuse and propose replay-resistant 
mechanisms that are compatible with DKIM's broad deployment" we say "The DKIM 
working group will evaluate potential mechanisms to mitigate this attack and 
produce one or more technical specifications that describe the abuse and 
propose improvements which, consistent with compatibility with DKIM's broad 
deployment and general email protocols, will reduce the impact of replay 
attacks".

Scott K



___
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)

[Scott Kitterman]

And it also doesn't solve the problem in any meaningful way.

This highlights my concern with the originally proposed charter language.  As 
drafted, since this doesn't break DKIM, it's fine.  We don't actually need to 
get that far in this case, but I still think we need broader language about 
not breaking things.  The cure needs to be less bad than the disease.

Scott K

On Saturday, November 26, 2022 6:20:09 PM EST Barry Leiba wrote:
> I will say that the use case that is broken by removing the signature
> is the "re-send" case, where the MUA or some other post-delivery agent
> (perhaps a sieve script) re-introduces the message with a different
> RCPT TO but the same MAIL FROM and "From:".  I don't know how often
> this happens nowadays, but I do know that I use it often in filters of
> my own, where mail sent to one of my addresses gets re-sent to another
> of my addresses -- sometimes in the same domain and sometimes in a
> different domain.
> 
> It works perfectly now, because the signature header is still there
> and everything still verifies, so the new delivery thinks everything
> is fine.  But if the first MDA removes the signature, the re-send will
> be unsigned and will get a DMARC failure.
> 
> We have to decide whether it's worth breaking that use case in order
> to address the replay situation.  My opinion is that it's not --
> because, as I say, I rely on that use case extensively.  My system
> would have to change *significantly* in order to work around that.
> 
> Barry
> 
> On Sat, Nov 26, 2022 at 11:36 AM Dave Crocker  wrote:
> > On 11/25/2022 2:26 AM, Laura Atkins wrote:
> > > What’s stopping large providers from removing DKIM now if they wanted
> > > to?
> > 
> > Nothing at all.  That they can choose to, if they wish, is one of the
> > appealing aspects to this.  It permits unilateral adoption.
> > 
> > > Or have they actually made the choice to keep the signatures in?
> > 
> > No idea.  And yes, it would be good to ask them.  I wonder what venue
> > there might be to float such a question...?
> > 
> > (time-passing jingle plays...)  Venue found.  So now let's see how they
> > respond...
> > 
> > > If they have made that choice, do we know why? If they haven’t made
> > > the choice, how complicated will it be to change the inbound MTA to
> > > strip headers?
> > 
> > To quibble, I'd hope it is some form of MDA, so the step is part of
> > delivery and not relaying.
> > 
> > > Will this have knockon effects for their internal systems? Is there a
> > > risk that stripping the DKIM header will cause authentication failures
> > > if the messages are forwarded internally or externally? (I’m reminded
> > > of the time Microsoft changed some internal systems around and ended
> > > up having everything fail SPF because they were picking the wrong IP
> > > out of their mess of headers to do SPF authentication with).
> > 
> > The essence of the questions you ask is to press for serious due
> > diligence among a range of sizeable email receiving platforms. That is
> > certainly an useful step before having the working group assert the
> > recommendation to remove the signature.
> > 
> > > And, I think most importantly: will this recommendation by the IETF
> > > have any impact whatsoever on the groups currently using DKIM replay
> > > as a way to get past (some) filters?
> > 
> > There are never any guarantees about adoption.   Once upon a time, the
> > IETF made some effort to get an indication of industry interest in
> > adoption.
> > 
> > These days, not so much.  Personally, I think that checking for adoption
> > interest is another kind of due diligence that ought to be required.
> > 
> > > I don’t see how it will, most of them are using their own email
> > > addresses / servers to collect the replayed messages and then sending
> > > the messages out through their own systems.
> > 
> > I don't understand.
> > 
> > > Even if Google and Microsoft and Yahoo and the other top 20 mailbox
> > > providers start stripping DKIM headers, the attackers will be able to
> > > find some service somewhere that doesn’t. Worst comes to worst, they
> > > stand up a MX on an EC2 instance and run their own code to collect the
> > > mail.
> > 
> > There seems to be some appeal in discounting the resulting requirement
> > to move to special receivers, but I don't understand that appeal.
> > Making things more expensive for attackers is pretty much the essence of
> > security protections.
> > 
> > That the added expense isn't all that high seems ok to me, since the
> > expense of imposing that expense isn't that high either.
> > 
> > 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
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> 

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

[Scott Kitterman]

On Tuesday, November 22, 2022 8:48:48 AM EST Alessandro Vesely wrote:
> On Tue 22/Nov/2022 01:21:00 +0100 Murray S. Kucherawy wrote:
> > Just for the sake of being complete, we should probably come up with
> > something to say about this, which is in RFC 4686, the DKIM "threats"
> > 
> > document:
> > DKIM operates entirely on the content (body and selected header
> > fields) of the message, as defined in RFC 2822 [RFC2822].  The
> > transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and
> > such elements as the envelope-from and envelope-to addresses and the
> > HELO domain are not relevant to DKIM verification.  This is an
> > intentional decision made to allow verification of messages via
> > protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
> > which an MUA acting as a verifier might use.
> > 
> > We actually seemed to like the idea, at least back then, that the
> > signature
> > survives delivery so that it can be validated at any point later.
> 
> Indeed, there are products, like Lieser's DKIM verifier plugin for
> Thunderbird[*], which verify DKIM on the MUA.

My desktop MUA of choice (kmail) includes the capability too.

The initial recipient in the replay scheme is part of the hostile effort, so I 
don't think anything that requires their cooperation addresses the question in 
any meaningful way.

Scott K


___
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

[Scott Kitterman]

On November 16, 2022 4:11:27 AM UTC, Roland Turner 
 wrote:
>On 15/11/22 23:29, Murray S. Kucherawy wrote:
>
>> Wei might argue that their signature means "We attest that this passed 
>> through us, and we did our best to make sure it was legitimate before it 
>> went out", than the more absolute "We claim this is legitimate and we are 
>> willing to stake our reputation on it" that some seem to infer.  The latter 
>> might even be incentive to consider not signing anymore.
>
>+1

That incentive would be a feature in my opinion.

Similar things have been done in the past in related contexts.  I'm aware that 
at one point one major provider focused their low quality (might be spam, but 
not obviously enough so we can decline to send it) through specific IP 
addresses so that the bulk of the higher quality traffic wouldn't be impacted 
(the reputation scores were substantially different).  This may still be going 
on, but it's been a very long time since I've had access to appropriate data to 
check.

Scott K

___
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

[Scott Kitterman]

On November 15, 2022 3:12:22 PM UTC, Barry Leiba  
wrote:
>On Mon, Nov 14, 2022 at 11:03 AM Alessandro Vesely  wrote:
>>
>> On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote:
>> > I'd point out that all but one of those things is either redundant (vs. say
>> > ARC), unacceptably harmful (we use DKIM *in the first place* to facilitate
>> > forwarding outside of the domain-registrant/sender's control), or both.
>>
>> +1, Scott is right when he says DKIM is working as designed.
>
>Well, yes and no.  It is working as designed in that it was not
>explicitly designed to prevent replay other than through the x= tag.
>
>But as one of several people in this discussion who took part in the
>design, I can tell you that replay was absolutely considered, that we
>*wanted* to do more to prevent replay, and that *allowing* replay is
>definitely not "working as designed".  We spent quite a bit of time
>looking at how we could deal with replay, but given what we knew and
>what our constraints were at the time (and the importance we thought
>replay attacks would have), we couldn't come up with something we
>thought was workable.  We hoped that the problem would be minimal and
>that x= would be enough.
>
>We now have more experience, a better sense of which use cases and
>features are more important and which are less so, more awareness of
>how serious the problem is, different people with new ideas, and so
>on.  I'm on the fence about the current proposals and have to think
>about and consider them more.  I am NOT on the fence about the need to
>consider them -- and other possible solutions -- and to discuss and
>decide on a way forward.
>
>That's what this proposed working group is for.  If you think that
>nothing should be changed and every proposed solution breaks more than
>it fixes, that's a perfectly reasonable view and one that needs to be
>part of the working group's consideration.  I DON'T think that means
>that we shouldn't have the working group and have the discussion.

This seems right to me.  We should see if we can do better, but one possible 
outcome has to be that the likely side effects of fixing the replay problem 
outweigh the benefits.

My concern with the charter is currently, the way I read it, the side effects 
to worry about are limited to impact on DKIM and I think that's too narrow.  
I'm still ruminating over specifically what to suggest.

Scott K

___
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

[Scott Kitterman]

On November 12, 2022 6:46:13 PM UTC, Wei Chuang 
 wrote:
>On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman 
>wrote:
>
>> On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
>> > Sorry I'm late to this thread.
>> >
>> > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman 
>> >
>> > wrote:
>> > > I agree that we don't want too much detail in the charter about the
>> > > technical
>> > > nature of the problem, but I would like to understand it in more
>> detail in
>> > > order to better assess the appropriateness of what is there.
>> > >
>> > > If a domain is signing spam and their reputation suffers as a result,
>> > > isn't
>> > > that the system working as designed?
>> > >
>> > > I would like to understand what is the technical characteristic of
>> these
>> > > messages that is distinct from the non-bad ones.  As far as I can tell
>> > > (and
>> > > this isn't the first time I've run across these discussions), there
>> isn't
>> > > one.
>> > > If that's the case, then I don't think there's an actual technical
>> > > solution to
>> > > this problem.
>> >
>> > The slides
>> > <
>> https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim
>> > -replay-problem-and-possible-solutions> at Dispatch and the problem
>> > statement draft
>> > <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/>
>> help
>> > describe the DKIM replay problem.
>>
>> I think this draft is very useful.  I think it supports my contention that
>> this problem is not technically distinguishable from legitimate mail flows.
>>
>> > There are some things that we could target at a technical level.  We
>> > probably would look for characteristics in the typical attack flow i.e.
>> > After having a spammy message signed, the spammer typically copies a
>> > message from the inbox, and then broadcasts it with a high degree of
>> > amplification.  We could look for
>> >
>> >- Messages that are sent to recipients that are not intended by the
>> >original sender or the forwarder
>> >- Messages may be viewed as traversing a path defined by the original
>> >sender and forwarder.   Messages taken from that intended path could
>> be
>> >replay
>> >- A variation is: messages that are taken from the inbox and then
>> resent
>> >- Count the signatures seen and filter by count
>>
>> I think that between the draft and the discussion so far there are a few
>> classes of potential solutions:
>>
>> 1.  Signers have taken responsibility for the message when they signed it,
>> so
>> they get to live with the consequences of having done so (for this
>> purpose, I
>> think the "message" is the signed content of the message).  No standards
>> action or changes required to DKIM, except maybe modernizing header field
>> signing/over-signing recommendations to make replay at least a little more
>> difficult.
>>
>> 2.  Introduce changes that break existing indirect mail flows.  Standards
>> actions needed.  Senders and receivers both need to make changes.
>> Standards
>> actions needed.  If we go down this path, would it be more honest just to
>> declare indirect mail flows obsolete/deprecated (based on the prevalence
>> of
>> >From re-writing on mailing lists, common practice may be headed this way
>> already due to DMARC).
>>
>> 3.  Changes that modify expectations for legitimate indirect mail flows
>> that
>> illegitimate indirect mail flows such as replay attacks will have
>> difficulty
>> copying.  These require changes by senders, indirect mail processors (e.g.
>> mailing list providers and forwarders), and receivers.  Unlikely to be
>> effective until widely implemented.
>
>
>> Are there more?
>>
>
>A way of bridging this, particularly for approach 3, is to use legacy
>authentication in addition to the replay resistant technique.  Use the
>replay resistant technique when available in preference to DKIM for DMARC
>and reputation systems, but have it available to fall back to.  A follow on
>consideration then is why would anyone adopt the new replay resistant
>technique.  Presumably there would be deliverability incentives for senders
>and forwarders to adopt the replay resistant technique (due to the negative
>reputation effects DKIM replay has) and for re

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

[Scott Kitterman]

On Friday, November 11, 2022 12:27:38 PM EST Scott Kitterman wrote:
> On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote:
> > On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman 
> > wrote:
...
> > > I can imagine the market solving this.  If there are two ESPs and one is
> > > careful about who is allowed to send mail signed by their domain and the
> > > other
> > > is not, I suspect that eventually superior reputation will result in
> > > superior
> > > deliverability, which should result in being able to charge more for a
> > > premium
> > > service.
> > 
> > I think that clearly this approach could work.  It's not a massive leap to
> > conclude that senders shouldn't sign spam, but it's also well established
> > that spam filters are not perfect.  All an attacker needs to do is
> > identify
> > some pattern the filters don't detect, and get that signed, and this
> > attack
> > works despite the best efforts of the sender.
> > 
> > More concerning to me: The IETF has previously taken the position that the
> > market will figure out spam and phishing, and therefore consideration of
> > protocol solutions should be deflected.  DMARC was the result.   I feel
> > that we leave this to the market, and that industry, at our own peril.  I
> > think we should give this a serious look before rejecting it outright.
> 
> I agree with this.  The challenge is finding a technically tractable way to
> distinguish this problematic case from normal usage.  I still owe the
> authors of the proposed solutions a more detailed study of the proposals,
> which I won't have bandwidth to do until at least Sunday.

OK.  I've re-read the drafts with an eye to what we might want to consider for 
the charter (I have comments/feedback on all of them, but I'll save that for 
later).

Three of the four proposed solutions (as I read them) require capturing the 
contents of SMTP comments in some variant of a DKIM like signature.  As I've 
mentioned before, I think this class of solution is architecturally 
challenging at best.  Since MTAs may have their own rules about address 
rewriting, I don't think a 5322 oriented process such as DKIM signing can be 
assumed to know specifics of 5321 identities.  As a result, you would have to 
defer these new signature types and do them between RCPT TO and DATA.

As I read the proposed charter, this is fine since the only backwards 
compatibility that's required is with DKIM:

> Because of DKIM’s broad deployment, compatibility with existing
> deployments will be a critical factor, and it is unlikely that proposals
> that lack compatibility will proceed to publication.

Is compatibility with DKIM sufficient for  the charter or should there be 
broader language about compatibility with existing email architecture?  I'm 
inclined to say "Yes", but I'm unsure about wording.  

Similarly, at least one of them could lead to normal indirect mail flows being 
identified as replay attacks.  Is something specific needed about being 
compatible with existing email deployments more generally (beyond DKIM 
deployment compatibility) needed?  Once agian, I'd say "Yes", but am not sure 
how to word it.

Do these make sense?  Does anyone have specific suggestions?

Scott K



___
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

[Scott Kitterman]

On November 13, 2022 9:07:21 PM UTC, Jim Fenton  wrote:
>On 9 Nov 2022, at 13:08, Barry Leiba wrote:
>
>> Murray is looking at re-opening the DKIM working group, chartering it
>> to work on replay mitigation.
>
>IIRC the result from Monday’s dispatch session was to go ahead and charter the 
>working group without a BOF. It seems to me that the discussion on this thread 
>in the last few days points to the need for a BOF prior to chartering.
>
>Given that IETF 115 just ended, it probably ought to be an interim BOF before 
>IETF 116.


I'd suggest waiting a bit to see how this discussion goes before deciding we 
need additional process.

Scott K

___
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

[Scott Kitterman]

On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
> Sorry I'm late to this thread.
> 
> On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman 
> 
> wrote:
> > I agree that we don't want too much detail in the charter about the
> > technical
> > nature of the problem, but I would like to understand it in more detail in
> > order to better assess the appropriateness of what is there.
> > 
> > If a domain is signing spam and their reputation suffers as a result,
> > isn't
> > that the system working as designed?
> > 
> > I would like to understand what is the technical characteristic of these
> > messages that is distinct from the non-bad ones.  As far as I can tell
> > (and
> > this isn't the first time I've run across these discussions), there isn't
> > one.
> > If that's the case, then I don't think there's an actual technical
> > solution to
> > this problem.
> 
> The slides
> <https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim
> -replay-problem-and-possible-solutions> at Dispatch and the problem
> statement draft
> <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/> help
> describe the DKIM replay problem.

I think this draft is very useful.  I think it supports my contention that 
this problem is not technically distinguishable from legitimate mail flows.

> There are some things that we could target at a technical level.  We
> probably would look for characteristics in the typical attack flow i.e.
> After having a spammy message signed, the spammer typically copies a
> message from the inbox, and then broadcasts it with a high degree of
> amplification.  We could look for
> 
>- Messages that are sent to recipients that are not intended by the
>original sender or the forwarder
>- Messages may be viewed as traversing a path defined by the original
>sender and forwarder.   Messages taken from that intended path could be
>replay
>- A variation is: messages that are taken from the inbox and then resent
>- Count the signatures seen and filter by count

I think that between the draft and the discussion so far there are a few 
classes of potential solutions:

1.  Signers have taken responsibility for the message when they signed it, so 
they get to live with the consequences of having done so (for this purpose, I 
think the "message" is the signed content of the message).  No standards 
action or changes required to DKIM, except maybe modernizing header field 
signing/over-signing recommendations to make replay at least a little more 
difficult.

2.  Introduce changes that break existing indirect mail flows.  Standards 
actions needed.  Senders and receivers both need to make changes.  Standards 
actions needed.  If we go down this path, would it be more honest just to 
declare indirect mail flows obsolete/deprecated (based on the prevalence of 
>From re-writing on mailing lists, common practice may be headed this way 
already due to DMARC).

3.  Changes that modify expectations for legitimate indirect mail flows that 
illegitimate indirect mail flows such as replay attacks will have difficulty 
copying.  These require changes by senders, indirect mail processors (e.g. 
mailing list providers and forwarders), and receivers.  Unlikely to be 
effective until widely implemented.

Are there more?
 
> > Once work is chartered in the IETF, it tends to get a certain momentum
> > toward
> > producing a result.  Before agreeing that we have a charter to solve a
> > problem, I'd like to understand we have a problem that can be solved, even
> > though that requires a bit of discussion at a more detailed level than
> > what
> > eventually goes in the charter.
> > 
> > Leaving aside algorithms and processes for a moment, could someone
> > describe
> > how an technically proficient human would examine one of these messages
> > and
> > determine they are "bad"?
> 
> What I've seen is that the Received header shows the delivery of the
> message to the initial recipient, followed by a new set of Received headers
> that shows that the message has been resent.  Sometimes the spammer leaves
> behind other clues like duplicate headers like multiple Date, Message-id or
> Subject headers.

None of these other clues need anything from DKIM to detect, although over 
signing such fields may help (no RFC is needed for this, senders can just do 
it, if it's useful).

Scott K


___
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

[Scott Kitterman]

OK.  Let's alter your scenario slightly.

In step 2, instead of sending to yourself, you send it to an email list which 
(as we have been begging them to do for 15 years) does not make any changes in 
the message to invalidate that DKIM signature.

So in step 3, the message goes to X thousands (probably not millions, so the 
scale is slightly less) of recipients through somewhere else's infrastructure.  
It's legitimately signed by free-email.com.

Step 4 is identical.

How do we distinguish your scenario from this version at a technical level?

Scott K

On Friday, November 11, 2022 11:46:13 AM EST Barry Leiba wrote:
> Indeed...
> The issue here is this:
> 
> 1. I get a (free) account on free-email.com.
> 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?
> 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.
> 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.
> 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.
> 
> 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.
> 
> Barry
> 
> On Fri, Nov 11, 2022 at 3:19 PM 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.
> > 
> > -MSK
> > ___
> > 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] DKIM reply mitigations: re-opening the DKIM working group

[Scott Kitterman]

On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote:
> On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman 
> 
> 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”.
> > 
> > Which is a fancy way of making DKIM only work for direct mail flows.
> 
> That's part of at least one of the proposals on deck.  But that same
> proposal talks about adding to the signal available to the receiver, not
> changing or removing it.
> 
> > I've been thinking some more about this and mentally I'm swinging back
> > more
> > towards the system is working as designed, don't mess with it.
> > 
> > If an ESP is willing to take on a trial customer they know nothing about
> > and
> > let them send email leveraging the reputation of the ESP's domain, why is
> > it
> > wrong that it suffers when that does not end well.
> 
> It's not always a commercial ESP.  The identified attack works today if you
> are a private user using a public mailbox service provider.
> 
> > I've yet to see any proposed problem that can be resolved without
> > disrupting
> > legitimate mail flows or standing the 5321/5322 architectural division on
> > its
> > head.  I know it when I see it isn't a sufficient definition.
> 
> Repeating what I said above, I think there are some ideas on the table that
> seek to provide incremental information for receivers to use in these
> cases.  The disruption should be minimal, unless the receivers broadly get
> it wrong.

The challenge is if that added information also applies equally to legitimate 
mail, it's merely an attractive nuisance we'd be better off not creating.

> > I can imagine the market solving this.  If there are two ESPs and one is
> > careful about who is allowed to send mail signed by their domain and the
> > other
> > is not, I suspect that eventually superior reputation will result in
> > superior
> > deliverability, which should result in being able to charge more for a
> > premium
> > service.
> 
> I think that clearly this approach could work.  It's not a massive leap to
> conclude that senders shouldn't sign spam, but it's also well established
> that spam filters are not perfect.  All an attacker needs to do is identify
> some pattern the filters don't detect, and get that signed, and this attack
> works despite the best efforts of the sender.
> 
> More concerning to me: The IETF has previously taken the position that the
> market will figure out spam and phishing, and therefore consideration of
> protocol solutions should be deflected.  DMARC was the result.   I feel
> that we leave this to the market, and that industry, at our own peril.  I
> think we should give this a serious look before rejecting it outright.

I agree with this.  The challenge is finding a technically tractable way to 
distinguish this problematic case from normal usage.  I still owe the authors 
of the proposed solutions a more detailed study of the proposals, which I 
won't have bandwidth to do until at least Sunday.

Scott K



___
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

[Scott Kitterman]

On Friday, November 11, 2022 4:23:44 AM EST Laura Atkins wrote:
> Snipping a bunch.
> 
> > On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:
> >>> 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”.
> > 
> > Which is a fancy way of making DKIM only work for direct mail flows.
> 
> I don’t understand this.

Typically for email forwarding the forwarder doesn't change the To:/Cc: in the 
message body.  They relay the message to the appropriate Rcpt To:.  As a 
result, for these indirect mail flows To:/Cc: will never match Rcpt To: at 
delivery.

> > I've been thinking some more about this and mentally I'm swinging back
> > more
> > towards the system is working as designed, don't mess with it.
> > 
> > If an ESP is willing to take on a trial customer they know nothing about
> > and let them send email leveraging the reputation of the ESP's domain,
> > why is it wrong that it suffers when that does not end well.
> 
> It’s One Message - sent to an address that has given permission to receive
> that message. What I hear you saying is tha ESPs that allow single messages
> sent to opt-in addresses deserve to have their domain reputation abused. Is
> this a correct summary of your argument?
> 
> If it is, I guess we are at a standoff because I don’t think ESPs who are
> mostly doing the right thing (ie, letting folks send opt-in messages)
> deserve to have their reputation trashed by senders who are actually
> unwelcome (and know they’re unwelcome) on the ESPs platform.

Your phrasing is harsher than I would put it, but not really wrong.  The 
problem is that there's no way to distinguish this case from many legitimate 
cases.  ESPs are probably going to need to step up their efforts to know their 
customers or push them to use their own domains (which aren't that hard to 
get).

> > It is a fundamental precept of DKIM that when a domain signs an email,
> > they
> > are taking responsibility for it (See the RFC 6376 introduction and more
> > specifically 2.5 and 2.6).  It's further reinforced by a note in 5.1 that
> > 
> > begins:
> >>  INFORMATIVE NOTE: A Signer can be implemented as part of any
> >>  portion of the mail system as deemed appropriate, including an
> >>  MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
> >>  Signers should beware of signing (and thereby asserting
> >>  responsibility for) messages that may be problematic.
> > 
> > I've yet to see any proposed problem that can be resolved without
> > disrupting legitimate mail flows or standing the 5321/5322 architectural
> > division on its head.  I know it when I see it isn't a sufficient
> > definition.
> 
> Isn’t that what the whole working group is exploring? Can we address this in
> any meaningful manner? You seem to want to have the discussion before we
> charter it, rather thn

Yes.  I think before we charter work to solve a problem, we should understand 
the problem well enough to determine that there is a technically tractable 
problem to solve.  I'm increasingly convinced there is not.

> > My more cynical side sees this issue as senders trying to offload more
> > work on receivers even though it's work that the sender is explicitly
> > responsible for.
> The senders are doing their work. They are not permitting the mail to go
> through their systems. They’re only sending opt-in mail through their
> systems. T

The definition of "doing their work" may need to be expanded.

> > For those that have been around for awhile this reminds me of the now long
> > dead controversy about closing open relays.  It's not identical, but I
> > think it rhymes.
> > 
> > Back in the mists of the early Internet we didn't have submission services
> > because any client could send email via (most) any MTA, so they weren't
> > needed.  

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

[Scott Kitterman]

On Thursday, November 10, 2022 8:32:16 AM EST Steve Atkins wrote:
> > 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”.

Which is a fancy way of making DKIM only work for direct mail flows.

I've been thinking some more about this and mentally I'm swinging back more 
towards the system is working as designed, don't mess with it.

If an ESP is willing to take on a trial customer they know nothing about and 
let them send email leveraging the reputation of the ESP's domain, why is it 
wrong that it suffers when that does not end well.

It is a fundamental precept of DKIM that when a domain signs an email, they 
are taking responsibility for it (See the RFC 6376 introduction and more 
specifically 2.5 and 2.6).  It's further reinforced by a note in 5.1 that 
begins:

>   INFORMATIVE NOTE: A Signer can be implemented as part of any
>   portion of the mail system as deemed appropriate, including an
>   MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
>   Signers should beware of signing (and thereby asserting
>   responsibility for) messages that may be problematic.

I've yet to see any proposed problem that can be resolved without disrupting 
legitimate mail flows or standing the 5321/5322 architectural division on its 
head.  I know it when I see it isn't a sufficient definition.

My more cynical side sees this issue as senders trying to offload more work on 
receivers even though it's work that the sender is explicitly responsible for.

For those that have been around for awhile this reminds me of the now long 
dead controversy about closing open relays.  It's not identical, but I think 
it rhymes.

Back in the mists of the early Internet we didn't have submission services 
because any client could send email via (most) any MTA, so they weren't 
needed.  As you can imagine, spamming was incredibly easy and the community 
gradually came around to the point that you can't just relay email for anyone, 
an MTA should serve authorized users (I oversimplify here).  As this consensus 
was being developed, a substantial number of MTA operators objected.  
Eventually, being an open relay meant no one would take mail from you.

This seems similar.

I can imagine the market solving this.  If there are two ESPs and one is 
careful about who is allowed to send mail signed by their domain and the other 
is not, I suspect that eventually superior reputation will result in superior 
deliverability, which should result in being able to charge more for a premium 
service.

As a receiver, if I have access to a quantitative reputation scoring system 
for IP addresses and domains, I might counter this, in the meantime, by 
looking for mail from IP addresses with statistically significantly worse 
reputation than the reputation of the domain and treat those messages more 
suspiciously.  I don't know that I would spend effort on special signature 
decoding mechanisms that are inherently risky for false positives.

Although not in scope for this discussion, SPF can have similar issues when 
ESPs are not sufficiently careful about what email they let out from their 
servers with their domain in Mail From, so this isn't a DKIM unique issue.

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.

Scott K


___
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

[Scott Kitterman]

On Thursday, November 10, 2022 7:54:25 AM EST Murray S. Kucherawy wrote:
> On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman 
> 
> wrote:
> > I agree that we don't want too much detail in the charter about the
> > technical
> > nature of the problem, but I would like to understand it in more detail in
> > order to better assess the appropriateness of what is there.
> > 
> > If a domain is signing spam and their reputation suffers as a result,
> > isn't
> > that the system working as designed?
> 
> For cases of very large operators, like Gmail, their reputation doesn't
> suffer to the extent that their mail becomes untrusted.  The abuser thus
> has a very long runway before something like that could start to happen.
> 
> > I would like to understand what is the technical characteristic of these
> > messages that is distinct from the non-bad ones.  As far as I can tell
> > (and
> > this isn't the first time I've run across these discussions), there isn't
> > one.
> > If that's the case, then I don't think there's an actual technical
> > solution to
> > this problem.
> 
> It may or may not be possible to reduce it to a technical characteristic.
> However, the attack amounts to a Trojan horse whose distribution is enabled
> or increased by DKIM; who's to say malware can't be sent this way?  In my
> view, that makes it something worth attention.

I agree it's worth attention, but let's make sure we understand the problem 
precisely enough to determine if we've succeeded.

> > Once work is chartered in the IETF, it tends to get a certain momentum 
> > toward
> > producing a result.  Before agreeing that we have a charter to solve a
> > problem, I'd like to understand we have a problem that can be solved, even
> > though that requires a bit of discussion at a more detailed level than
> > what
> > eventually goes in the charter.
> 
> I think of the charter as the contract between the working group and the
> IESG that constrains what it will produce.  The questions you're asking
> here tend to be the things we ask in the discussion around the charter,
> particularly during a BoF session to discuss working group formation, but
> not necessarily what goes in the charter directly.
> 
> So I think your question is a legitimate one, but I'm not sure what text
> the charter ought to contain in order to address it directly.

Thanks.  I think this is a useful discussion and we'll probably know the 
answer to the question by the time we get to the end of it.

> > Leaving aside algorithms and processes for a moment, could someone
> > describe
> > how an technically proficient human would examine one of these messages
> > and
> > determine they are "bad"?
> 
> The message itself is usually indistinguishable between its first instance
> (when it's signed) and its second (when it's replayed).  The envelope,
> however, has to vary; that's a key property of the attack.  One possible
> solution is to come up with a scheme that factors that part of the envelope
> into DKIM's operation; another is to pack useful metadata into the message,
> independent of DKIM, so a downstream receiver stands a chance of telling
> the difference between a first instance and a replayed instance.  Which of
> those two approaches should be used, and the exact mechanism of doing so,
> would be the output(s) of this working group.

This is helpful.

It does highlight the architectural concerns I have.  

First, as in the alumni address example I gave, the envelope varying is a part 
of normal, legitimate email flows.  If we are not careful, we'll recreate all 
the architectural limitations of SPF.  You could, in fact, fairly trivially 
solve this problem in DMARC by creating a new alignment type which requires 
both DKIM and SPF to pass.  That would have interoperability problems, but I 
think anything this group might develop ought to be notably more consistent 
with backward compatibility than that would be.  Not for the charter, but it 
might be a reasonable benchmark to consider for determining if we've 
succeeded.

Second, what you're suggesting as a possible class of solution involves taking 
information from the envelope and including it in the body.  Because the Mail 
From, for example, isn't always known prior to submission, you might end up 
having to modify the body of the message somewhere between the Mail From 
command and Data in the SMTP session.  This seems like a risky mixing of 5321 
and 5322 functions.  I have no idea how I would implement it.

Let me think about what charter suggestions I have based on this.

Thanks,

Scott K



___
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

[Scott Kitterman]

I agree that we don't want too much detail in the charter about the technical 
nature of the problem, but I would like to understand it in more detail in 
order to better assess the appropriateness of what is there.

If a domain is signing spam and their reputation suffers as a result, isn't 
that the system working as designed?

I would like to understand what is the technical characteristic of these 
messages that is distinct from the non-bad ones.  As far as I can tell (and 
this isn't the first time I've run across these discussions), there isn't  one. 
 
If that's the case, then I don't think there's an actual technical solution to 
this problem.

Once work is chartered in the IETF, it tends to get a certain momentum toward 
producing a result.  Before agreeing that we have a charter to solve a 
problem, I'd like to understand we have a problem that can be solved, even 
though that requires a bit of discussion at a more detailed level than what 
eventually goes in the charter.

Leaving aside algorithms and processes for a moment, could someone describe 
how an technically proficient human would examine one of these messages and 
determine they are "bad"?

I'll think about what else needs to be there from a compatibility perspective.  
I need to re-read the drafts and think about it first.

Scott K

On Thursday, November 10, 2022 5:35:08 AM EST Barry Leiba wrote:
> We could add a sentence or two that says we’re seeing increasing spam
> campaigns that use DKIM replay to get their spam sent out, taking advantage
> of — and subsequently damaging — the reputation of the domain that signed
> the original message.  Do you think that would be useful?
> 
> More detail than that doesn’t belong in the charter.  I would expect to put
> more detail in the Introduction section of the document we come up with.
> 
> The “compatibility” part of the charter, and the discussions of what the
> ultimate solution will be, will be what handles the “not breaking email
> architecture” and minimizing damage to legitimate email flows.  I don’t
> think more of that detail needs to be in the charter either, but if you
> disagree please suggest specific text you’d like to see.
> 
> Barry
> 
> On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman  wrote:
> > I think having a precised understanding of the problem that the charter is
> > meant to address is important.  I am having a hard time finding a
> > technical
> > distinction between a "replay attack" and the, by design, nature of DKIM's
> > independence from transport details.
> > 
> > I have not read all the drafts, but the ones I have looked at seem to want
> > to
> > tie some aspect of a DKIM signature to something in the envelope.  I think
> > that would be a 5321/5322 layering violation that would make such
> > proposals
> > difficult for protocol based systems to implement.
> > 
> > I think there needs to be something about not breaking the architecture of
> > email in the charter based on what I've read so far, but I don't think I
> > have
> > a fine enough understanding of the problem yet to propose words.
> > 
> > Understanding and bounding the problem is, I think, an essential
> > prerequisite
> > to the charter.  We've seen efforts fail before due to a lack of consensus
> > on
> > the exact problem (DBOUND comes immediately to mind).
> > 
> > Even if there's no report, I think we should make sure we understand the
> > problem first.
> > 
> > Would someone who's pushing for a solution please describe what's being
> > done
> > that's technically distinguishable from something like traditional email
> > forwarding (e.g. using may alumni.example.edu address and then
> > alumni.example.edu forwards it to my current "real" address).  By design,
> > DKIM
> > has no problem with this behavior, so I'd like to understand how to
> > distinguish good from bad in this space.
> > 
> > Scott K
> > 
> > On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote:
> > > Is this relevant to the charter?  Do you doubt the attacks
> > > sufficiently that you would want to object to chartering a working
> > > group to address the issue?
> > > 
> > > Barry
> > > 
> > > On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely  wrote:
> > > > On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote:
> > > > > [...]
> > > > > 
> > > > > Current proposals include the following drafts:
> > > > >   - draft-bradshaw-envelope-validation-extension-dkim
> > > > >   - draft-chuang-replay-resistant-arc
> > > > >   - draft-gondwana-email-

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

[Scott Kitterman]

I think having a precised understanding of the problem that the charter is 
meant to address is important.  I am having a hard time finding a technical 
distinction between a "replay attack" and the, by design, nature of DKIM's 
independence from transport details.

I have not read all the drafts, but the ones I have looked at seem to want to 
tie some aspect of a DKIM signature to something in the envelope.  I think 
that would be a 5321/5322 layering violation that would make such proposals 
difficult for protocol based systems to implement.

I think there needs to be something about not breaking the architecture of 
email in the charter based on what I've read so far, but I don't think I have 
a fine enough understanding of the problem yet to propose words.

Understanding and bounding the problem is, I think, an essential prerequisite 
to the charter.  We've seen efforts fail before due to a lack of consensus on 
the exact problem (DBOUND comes immediately to mind).

Even if there's no report, I think we should make sure we understand the 
problem first.

Would someone who's pushing for a solution please describe what's being done 
that's technically distinguishable from something like traditional email 
forwarding (e.g. using may alumni.example.edu address and then 
alumni.example.edu forwards it to my current "real" address).  By design, DKIM 
has no problem with this behavior, so I'd like to understand how to 
distinguish good from bad in this space.

Scott K

On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote:
> Is this relevant to the charter?  Do you doubt the attacks
> sufficiently that you would want to object to chartering a working
> group to address the issue?
> 
> Barry
> 
> On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely  wrote:
> > On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote:
> > > [...]
> > > 
> > > Current proposals include the following drafts:
> > >   - draft-bradshaw-envelope-validation-extension-dkim
> > >   - draft-chuang-replay-resistant-arc
> > >   - draft-gondwana-email-mailpath
> > >   - draft-kucherawy-dkim-anti-replay
> > > 
> > > The working group will start by considering those proposals; other
> > > proposals remain welcome.
> > 
> > Isn't there a report on relevant replay attacks?  All the above I-D say
> > that replay attacks are a problem.  Bron adds that the attack was widely
> > seen in early 2022.  However, there's not a panoramic view of the
> > problem, mentioning volume, scope, targets and such.
> > 
> > I know replay attacks are possible, but I never saw one.
> > 
> > 
> > Best
> > Ale
> > --
> > 
> > 
> > 
> > 
> > ___
> > 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] DKIM replay mitigations

[Scott Kitterman]

At least as I read it, I don't think you are describing the same issue as RFC 
8376, Section 8.6.  It describes the concern as "banking on the reputation of 
the signing domain (e.g., a large popular mailbox provider) rather than its 
own".  I believe that's meant to describe an unaligned (in a DMARC sense) 
message, which seems different than what you are describing.

Many normal email operations seem difficult to distinguish from the case you 
are trying to address.  Signing fields in the envelope may be enough to break 
replaying, although it would have other negative consequences.

Scott K

On October 3, 2022 11:40:55 PM UTC, Wei Chuang 
 wrote:
>I've uploaded a draft describing for a specification that tackles the
>concepts listed below:
>
>https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
>
>Feedback welcome.  (Apologies for the formatting in advance as its a first
>draft)
>-Wei
>
>On Mon, Aug 22, 2022 at 2:53 PM Wei Chuang  wrote:
>
>> Hi,
>> One of the known security challenges in DKIM is its vulnerability to
>> replay attacks as already mentioned in Security Considerations section 8.6
>> ,
>> and has been raised at recent M3AAWGs as a significant challenge.  I'd like
>> to propose a couple of concepts for dealing with DKIM replay.  Depending on
>> where the conversation goes, I can get into proposals for technical
>> specification level proposals.
>>
>> DKIM replay typically takes advantage of capturing a DKIM signed message
>> from the inbox and then rebroadcasting it out to many users.  Taking that
>> observation there are a couple of directions for mitigations.
>> 1. We can try to detect and prevent the recipient amplification.  One way
>> may be to specify that the sender must always DKIM sign for the who the
>> intended recipient is including through mailing lists and forwarding
>> scenarios, in such a way that the receiver can check for this.  If the
>> intended recipient verification fails, then it may be an indication of
>> replay.  This must work for multiple forwarding hops and enterprise
>> scenarios, and when forwarders don't participate.
>> 2. Distinguish signed messages in the inbox versus those in transit.  If
>> we see messages that were signed messages meant to be in the inbox,
>> suddenly in transit again, this likely indicates a replayed message.
>> 3. Strengthen message digital signing to be replay resistant.  Currently
>> DKIM signature's identity just says it is associated with a particular
>> sender.  Perhaps we ought to tie the signature back to a particular SMTP
>> transaction by signing for both the sender, receiver and timestamp.  We
>> could add more specification around the timestamp to make it more workable
>> in the email distributed forwarding system for replay detection.  Put this
>> signature in a framework such as ARC that describes forwarding hops
>> better, so that receivers can make use of those identities with
>> forwarding.  Using ARC as the signing framework also helps proposal 1).
>> Again consider when receivers don't participate.  (This is a highly complex
>> scenario and likely I'm missing important details in trying to summarize)
>>
>> All the while, using ARC as a framework may allow future support for
>> another long standing issue, which is working on message modification while
>> forwarding, in particular for mailing lists.  The proposal
>> draft-kucherawy-dkim-list-canon-01
>>  
>> provides
>> a framework for handling common mailing list modifications by identifying
>> those modifications.  Putting it into ARC, may generalize this by
>> identifying who made the modifications and be able to tolerate multiple
>> such modifications such multiple mailing list expansions.
>>
>> Looking forward to your initial thoughts about feasibility and interest.
>> -Wei
>>

___
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

[Scott Kitterman]

On Tuesday, May 12, 2020 2:14:11 PM EDT Alessandro Vesely wrote:
> On Tue 12/May/2020 19:09:55 +0200 Murray S. Kucherawy wrote:
> > On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:
> >> On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> >>> On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely  
wrote:
>  On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > Indeed; why would I believe what any given domain claims in this tag?
>  
>  If you trust the domain, you can as well trust their tagging.
> >>> 
> >>> If you trust the domain, you don't need their tagging.
> >> 
> >> Why not?  I may trust gmail, say.  Yet, in order to learn what
> >> restrictions they apply to the From: I have to create an account and try.
> >> There is no standard location where they declare their policy in a
> >> machine-readable manner, and policies written in legalese are even less
> >> readable...>>
> > 
> > What would you do with that information if you had it?
> 
> I think I'd copy it to comments in the corresponding A-R header field.  That
> would make A-R stanzas more eloquent.

Personally, more eloquent header fields aren't a priority.  I'm confident that 
if there were somehow standardized, I wouldn't implement it.

Scott K


___
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

[Scott Kitterman]

On Tuesday, May 12, 2020 1:09:55 PM EDT Murray S. Kucherawy wrote:
> On Tue, May 12, 2020 at 9:30 AM Alessandro Vesely  wrote:
> > On Tue 12/May/2020 17:48:38 +0200 Murray S. Kucherawy wrote:
> > > On Tue, May 12, 2020 at 1:20 AM Alessandro Vesely 
> > 
> > wrote:
> > >> On Mon 11/May/2020 20:23:12 +0200 Murray S. Kucherawy wrote:
> > >>> Indeed; why would I believe what any given domain claims in this tag?
> > >> 
> > >> If you trust the domain, you can as well trust their tagging.
> > > 
> > > If you trust the domain, you don't need their tagging.
> > 
> > Why not?  I may trust gmail, say.  Yet, in order to learn what
> > restrictions
> > they apply to the From: I have to create an account and try.  There is no
> > standard location where they declare their policy in a machine-readable
> > manner,
> > and policies written in legalese are even less readable...
> 
> What would you do with that information if you had it?
> 
> Maybe you're using a different definition of "trust" than I am.  To me, "I
> trust gmail.com" means "I believe mail signed by gmail.com is legitimate",
> irrespective of how they might handle their mail.
> 
> Put another way: I believe I would only reach the opinion that I "trust"
> mail from a domain when I already know the thing(s) your tag(s) would tell
> me.

The implication is that such tags won't affect a deliver/don't deliver decision 
(which I think is correct - the moment it does, all my mail will be marked 
super duper urgent first class the user really wants this I swear).  

To the extent such information is useful for downstream processing (and I 
don't really know that it is, but if it is), there's no compelling need to 
complicate DKIM with this.  As Dave suggested, this could be a new header 
field.  It could be covered by a DKIM signature with the same security 
properties as if it were a part of DKIM without imposing additional complexity 
on DKIM.

Scott K


___
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

[Scott Kitterman]

On Tuesday, May 12, 2020 5:31:30 AM EDT Steve Atkins wrote:
> 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_Standa
> rd_A_Comprehensive_Policy_and_Technology_Proposal_for_Email_Reform

I looked through it.  It is so 2003 FUSSP.

Scott K


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