Re: [Ietf-dkim] DKIM Signature
Laura Atkins wrote in <9a3fef5d-ce9c-4b69-8049-43c62dd3d...@wordtothewise.com>: |> On 31 Oct 2023, at 00:26, Steffen Nurpmeso wrote: |>|4. I don't understand how that is relevant to the current working group |>|topic of a problem statement |> |> (that is what the thread is about) | |There is nothing in the current problem statement that is discussing \ |changing the algorithm or adding another algorithm. | |I am not clear on how changing the algorithm addresses the DKIM replay \ |problem. Can you explain to us how this will address the issue the \ |group is currently chartered to address? No i cannot. I am still thinking that the DKIM-Subsignature: idea, as reiterated in my other email, would be a solution to the problem the statement of which has not yet been accepted. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Alessandro Vesely wrote in : |On Mon 30/Oct/2023 20:44:20 +0100 Steffen Nurpmeso wrote: |> I still think ED25519 is not gracefully supported by all DKIM implementa\ |> tions |> because you cannot use a stream based approach, but must load the \ |> entire data |> "in memory", it is a one-off algorithm. | |Irrespective of what the advantage of simultaneous access the entire \ |data would be, DKIM standardization of ed25519 keeps the same SHA256 \ |hashing algorithms already used for RSA. It signs the hash as if it \ |were the whole data. My point solely was, all the time, practically speaking, that any DKIM software that has been updated to support the DKIM Ed25519-SHA256 RFC 8463 from September 2018, should (MUST), to the best of my knowledge, have been rewritten to load all the message data into memory, because, please let me quote "man Ed25519" (7ssl): NOTES The PureEdDSA algorithm does not support the streaming mechanism of other signature algorithms using, for example, EVP_DigestUpdate(). The message to sign or verify must be passed using the one‐shot EVP_DigestSign() and EVP_DigestVerify() functions. I want to point out that any such software should therefore actually *be* the best possible representation of, like i said in <20230814202928.ufult%stef...@sdaoden.eu>, You save a lot by doing DKIM-only of course. I think you are exaggerating a bit. I for myself think quite the opposite, especially if, say, an actual DKIM implementation simply walks over in-memory objects, and sending out a mail is a matter of dump-to-wire. regarding my idea of DKIM-Backup: to turn DKIM into a cryptographically verifiable sender->receiver chain, as well as, and especially, the work-out of Dave Crocker's idea (that turned out to have possibly been an idea of Mr. Kucherawy, written down in a "stale RFC") to embed SMTP-addressed receivers in emails via DKIM-B?Subsignature: (<20230812193147._esnc%stef...@sdaoden.eu>). The latter of which would, as far as i did think, address the current problem description of the IETF DKIM group, DKIM replay. |Neither I am a cryptographer. Does this usage break collision resistance \ |properties of Schnorr signatures? I asked on stackexchange[*] but \ |got no reply. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
> On 31 Oct 2023, at 00:26, Steffen Nurpmeso wrote: > > > |4. I don't understand how that is relevant to the current working group > |topic of a problem statement > > (that is what the thread is about) There is nothing in the current problem statement that is discussing changing the algorithm or adding another algorithm. I am not clear on how changing the algorithm addresses the DKIM replay problem. Can you explain to us how this will address the issue the group is currently chartered to address? laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On Mon 30/Oct/2023 20:44:20 +0100 Steffen Nurpmeso wrote: I still think ED25519 is not gracefully supported by all DKIM implementations because you cannot use a stream based approach, but must load the entire data "in memory", it is a one-off algorithm. Irrespective of what the advantage of simultaneous access the entire data would be, DKIM standardization of ed25519 keeps the same SHA256 hashing algorithms already used for RSA. It signs the hash as if it were the whole data. Neither I am a cryptographer. Does this usage break collision resistance properties of Schnorr signatures? I asked on stackexchange[*] but got no reply. Best Ale -- [*] https://crypto.stackexchange.com/questions/108206/curious-behavior-of-evp-digestsign-for-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Dave Crocker wrote in <2bdbcfe0-4126-45b5-93a3-51ec4f8cf...@gmail.com>: |On 10/30/2023 12:44 PM, Steffen Nurpmeso wrote: |> Dave Crocker wrote in |> : |>|On 10/29/2023 1:51 PM, Jan Dušátko wrote: |>|> In my opinion, the verifiability of the place and time of origin needs |>|> to be addressed, which is one of the reasons to use DKIM: |>| |>|While I think I understand the basis for thinking that DKIM is relevant |>|to that determination, it isn't. It's semantics have nothing at all to |>|do with authenticating origination, nor certifying content. Note, for |>|example, that there can be (and often is) multiple DKIM signatures, |>|affixed at different time. |> |> This is why it is so important that ARC makes headers directly |> addressable in infrastructures that ignore the stack nature of |> email. | |1. I don't understand what you mean by "headers directly addressable in |infrastructures" dkimpy of Scott Kitterman for example, in March this year: commit 264230308cd5b47cb24f115f9f71d1ac334a6ca6 ... fix correct AMS header selection When we are verifying the ARC seal we need to fetch the raw AMS header from the header list. But it's not enough to return the first one we find, since we may be interested in a different arc seal, we need to search for the correct ARC index. --- dkim/__init__.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dkim/__init__.py b/dkim/__init__.py index 73d095f808..c2e77e9074 100644 --- a/dkim/__init__.py +++ b/dkim/__init__.py @@ -1293,7 +1293,9 @@ class ARC(DomainSigner): # we can't use the AMS provided above, as it's already been canonicalized relaxed # for use in validating the AS. However the AMS is included in the AMS itself, # and this can use simple canonicalization -raw_ams_header = [(x, y) for (x, y) in self.headers if x.lower() == b'arc-message-signature'][0] +raw_ams_header = [ + (x, y) for (x, y) in self.headers if x.lower() == b'arc-message-signature' and b" i="+sig[b'i']+b";" in y.lower() +][0] |2. I am pretty sure ARC doesn't do that See above. |3. I don't understand how your response is relevant to what I wrote. The thread is about addition of another algorithm. I ... |4. I don't understand how that is relevant to the current working group |topic of a problem statement (that is what the thread is about) |>|DKIM says the signer attests to having 'some' responsibility in |>|'handling' the message. That is fundamentally different than what your |>|text means. |> |> Still the sheer size of "good enough" (tm) RSA is consumes space ... |Is your response suppose to have something to do with my statement? ... disagreed with you. *That* 'some' and 'handling' is a cryptographic signature operation. Even if the current non-ARC email stack at times breaks inner envelopes and thus places them and their producers in the twilight zone, to exaggerate that. But this deficite is surely soon addressed by ARC. The new algorithms also require significantly smaller certificates (ie my US-ASCII armored S/MIME RSA public key is 2139 bytes, my OpenSSH ED25519 one is 100 bytes, even though this compares apples and oranges.) And i reiterate what you did not quote, the Ed25519 algorithm with all the benefits is already standardized by the IETF. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On 10/30/2023 12:44 PM, Steffen Nurpmeso wrote: Dave Crocker wrote in : |On 10/29/2023 1:51 PM, Jan Dušátko wrote: |> In my opinion, the verifiability of the place and time of origin needs |> to be addressed, which is one of the reasons to use DKIM: | |While I think I understand the basis for thinking that DKIM is relevant |to that determination, it isn't. It's semantics have nothing at all to |do with authenticating origination, nor certifying content. Note, for |example, that there can be (and often is) multiple DKIM signatures, |affixed at different time. This is why it is so important that ARC makes headers directly addressable in infrastructures that ignore the stack nature of email. 1. I don't understand what you mean by "headers directly addressable in infrastructures" 2. I am pretty sure ARC doesn't do that 3. I don't understand how your response is relevant to what I wrote. 4. I don't understand how that is relevant to the current working group topic of a problem statement |DKIM says the signer attests to having 'some' responsibility in |'handling' the message. That is fundamentally different than what your |text means. Still the sheer size of "good enough" (tm) RSA is consumes space and bandwidth, and, yes (do not laugh), electrical energy. And pushes towards TCP for DNS Is your response suppose to have something to do with my statement? -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Dave Crocker wrote in : |On 10/29/2023 1:51 PM, Jan Dušátko wrote: |> In my opinion, the verifiability of the place and time of origin needs |> to be addressed, which is one of the reasons to use DKIM: | |While I think I understand the basis for thinking that DKIM is relevant |to that determination, it isn't. It's semantics have nothing at all to |do with authenticating origination, nor certifying content. Note, for |example, that there can be (and often is) multiple DKIM signatures, |affixed at different time. This is why it is so important that ARC makes headers directly addressable in infrastructures that ignore the stack nature of email. |DKIM says the signer attests to having 'some' responsibility in |'handling' the message. That is fundamentally different than what your |text means. Still the sheer size of "good enough" (tm) RSA is consumes space and bandwidth, and, yes (do not laugh), electrical energy. And pushes towards TCP for DNS I still think ED25519 is not gracefully supported by all DKIM implementations because you cannot use a stream based approach, but must load the entire data "in memory", it is a one-off algorithm. (As is x448.) And some implementations simply decided it is too hard to implement. But the IETF *did* standardize this what you claim "overkill", no? OpenSSH (i am not a cryptographer; they are not either, i think, but they monitor very closely, what i think) did "also not do 448" but have chosen to experiment with post-quantum sntrup761, saying The sntrup761 implementaion, like sntrup4591761 before it, is public domain code extracted from the SUPERCOP cryptography benchmark suite (https://bench.cr.yp.to/supercop.html). To me the thing is, .. you know .., that even MD5 or the slightly hardened SHA-1 is still "good enough" for signatures, but most people ran away nonetheless, and today you see SHA-256 or SHA-512, or BLAKE (etc). And *if* the entire message has to be "loaded into memory" to be able to support new and modern algorithms, a lot becomes possible. Also i personally think of DKIM like i do for a passport. You do anything possible to make it unforgeable. I want a cryptographically verifiable path through the stack up to the origin. DKIM just never tried to offer the necessary hands to operators of mailing-lists etc to close the cryptographic gap. ARC will now do this, fully automatic. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On 10/29/2023 1:51 PM, Jan Dušátko wrote: In my opinion, the verifiability of the place and time of origin needs to be addressed, which is one of the reasons to use DKIM: While I think I understand the basis for thinking that DKIM is relevant to that determination, it isn't. It's semantics have nothing at all to do with authenticating origination, nor certifying content. Note, for example, that there can be (and often is) multiple DKIM signatures, affixed at different time. DKIM says the signer attests to having 'some' responsibility in 'handling' the message. That is fundamentally different than what your text means. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Jan Dušátko writes: > In my opinion, the verifiability of the place and time of origin needs > to be addressed, which is one of the reasons to use DKIM: > - Ed25519 has a security equivalent of 125b, a little less than the > currently required security equivalent 128b (more-less the same) > - Ed448, like Ed25519, is standardized both within TLS 1.3 and for > digital signature thanks to NIST and ETSI All of those are much stronger than what is needed for authentication of the sender. Attackers will not be wasting that much resources to simply generate fake DKIM signatures. > - RSA should be vulnerable to Shor algorithm (one QFT) in the future > - ECDSA/EDDSA should be vulnerable to modified Shor algorithm (two QFTs) > in the future > - PQC migration will also need to be addressed in the near future > It is not a question of how many algorithms there will be, but what > algorithms will be involved. Again we are talking about authentication, not store and decrypt later. If someone actually generates quantum computer he will not be wasting computing time to break DKIM, there are much higher value targets to attack. Post quantum crypto is needed now when you are encrypting data, and attackers can store that encrypted data and decrypt it later when they have quantum computers. For PQC migration we need to have a algorithm agility, i.e. ability to add new algorithm in a backward compatible way, i.e., without breaking any old implementations. I thnk we can already do that as we can use different algorithms to generate multiple DKIM headers, and new implementations can ignore the old broken algorithms and only verify the ones known to be secure, while old implementations will still be able to verify old algorithms, so there is nothing to be done now for PQC in DKIM. -- kivi...@iki.fi ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Dne 27. 10. 2023 v 23:02 John Levine napsal(a): It appears that Scott Kitterman said: 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. [...] 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 In my opinion, the verifiability of the place and time of origin needs to be addressed, which is one of the reasons to use DKIM: - Ed25519 has a security equivalent of 125b, a little less than the currently required security equivalent 128b (more-less the same) - Ed448, like Ed25519, is standardized both within TLS 1.3 and for digital signature thanks to NIST and ETSI - RSA should be vulnerable to Shor algorithm (one QFT) in the future - ECDSA/EDDSA should be vulnerable to modified Shor algorithm (two QFTs) in the future - PQC migration will also need to be addressed in the near future It is not a question of how many algorithms there will be, but what algorithms will be involved. In my view, RSA has a huge disadvantage with key length (DNS response size) and a lower increase in security due to the increase in key size. In contrast, both Curve25519 and Ed448 fit into one answer and have a significantly higher security equivalent. Question if makes sense to secure that cardboard box of SMTP protocol with a one-ton vault door, my answer is simply yes. Because cryptography has the ability to prove a place of origin while protecting against modification. But is it possible and feasible? Regards Jan ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
I do appreciate the discussion here, but the current issue we’re trying to address is the problem statement. laura > On 29 Oct 2023, at 12:12, John R Levine wrote: > >> Future proofing? The history of encryption is riddled with examples of >> overconfidence. > > Well, sure, and I would not be opposed to revisiting this issue in a decade. > > As Scott noted, approximately nobody handles ed25519 yet, and nobody will > until there is some reason to believe that RSA signatures are too weak. > Adding another five tons of steel to the door won't change that. > > And on the third hand, if something unexpected happens and RSA and ed25519 > both fail, why do you imagine Ed448 wouldn't fail too? If someone figures > out how to make large quantum computers, they're all toast and we'll have to > switch to PQC. > > R's, > John > >> 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 >>> >> > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
Future proofing? The history of encryption is riddled with examples of overconfidence. Well, sure, and I would not be opposed to revisiting this issue in a decade. As Scott noted, approximately nobody handles ed25519 yet, and nobody will until there is some reason to believe that RSA signatures are too weak. Adding another five tons of steel to the door won't change that. And on the third hand, if something unexpected happens and RSA and ed25519 both fail, why do you imagine Ed448 wouldn't fail too? If someone figures out how to make large quantum computers, they're all toast and we'll have to switch to PQC. R's, John 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 Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
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
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
It appears that Scott Kitterman said: >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. [...] >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
Re: [Ietf-dkim] DKIM Signature
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] DKIM Signature
On 27/10/2023 15:56, Murray S. Kucherawy wrote: Which DKIM implementations are known to be willing to support this if it were added? If I saw interest, I'd be willing to add it to Exim. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
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. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] DKIM Signature
Hi, I would like to ask to consider the possibility of defining a DKIM signature using Ed448. The current Ed25519 has a security equivalent of 125b, Ed448 has a security equivalent of 224b, yet their total length is acceptable in terms of the DNS packet size. The load generated by the signature algorithm is higher, but it still works better in relation to the corresponding security equivalent for RSA. Moreover, an RSA algorithm with the corresponding strength will be challenging to transfer within the DNS response. - the key for Ed448 has 56B, after transcoding to Base64 then 76B - the key for Ed25519 has 32B, after transcoding to Base64 then 44B The mechanism for Ed448 is part of the definition of TLS 1.3, FIPS 186-5 as well as eIDAS and ETSI (TS 103523). Regards Jan ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM signature algorithms
I need to agree with Scott here. In the DNS world, we're slow to adopt new DNSSEC crypto algorithms due to speed of deployment. And DNSSEC has been around so long we have been giving guidance telling people to stop using DSA and MD5. ed25119 should be more than fine, and others can be added if there needs in the future. tim (not as a chair) On Sat, Mar 11, 2023 at 12:10 AM Scott Kitterman wrote: > 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 > ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM signature algorithms
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
[Ietf-dkim] DKIM signature algorithms
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 Regards Jan -- -- --- - - Jan Dušátko Tracker number: +420 602 427 840 e-mail: j...@dusatko.org GPG Signature: https://keys.dusatko.org/E535B585.asc GPG Encrypt:https://keys.dusatko.org/B76A1587.asc ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On 10/24/2018 4:53 PM, Дилян Палаузов wrote: PS: Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Our DKIM implementation does not support this "r=y" tag. In general, per DKIM specification, all unknown DKIM-signature tags are ignored. <<< 554 REJECTED BY SYSTEM POLICY FILTER Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT Off hand, it appears your IP address was filtered by a Geo IP Location database. This is done immediately at the connection level so we have limited SMTP session logs to look at. I'm contacting you off list. -- HLS ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
PS: > For example, the ietf.org mailing list has begun to rewrite and it > replaces the 5322.From with a dmarc.ietf.org domain, adds a new > X-Original-From header and resigns the message using an ietf.org > signer domain: > >DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; > s=ietf1; > t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; > h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: > List-Archive:List-Post:List-Help:List-Subscribe:From; > b=. > X-Original-From: Hector Santos > From: Hector Santos > > What it should do is: > >1) It should use a 1st party signature using d=dmarc.ietf.org to > match the new author domain dmarc.ietf.org. > >2) It should has hash bind the X-Original-From header to the > signature. Since DKIM recommends not to bind "X-" headers, > a non "X-" header should be used, i.e. "Original-From:". This > means adding the header to the 'h=" field to avoid potential > mail resend exploits using different unprotected Original-from: > fields. > >3) and finally, the dmarc.ietf.org domain should have its own > DMARC p=reject policy to effectively replace the one it > circumvented with the submission. > Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Apart from this, on the last email I sent “To: Hector Santos < hsan...@isdg.net>, ietf-dkim@ietf.org” , I got: Date: Wed, 24 Oct 2018 20:32:15 GMT From: Mail Delivery Subsystem Message-Id: <201810242032.w9okwfsc027...@mail.aegee.org> Content-Type: multipart/report; report-type=delivery-status; boundary="w9OKWFSc027376.1540413135/mail.aegee.org" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --w9OKWFSc027376.1540413135/mail.aegee.org The original message was received at Wed, 24 Oct 2018 20:32:10 GMT from ipbcc2def0.dynamic.kabel-deutschland.de [188.194.222.240] - The following addresses had permanent fatal errors - (reason: 554 REJECTED BY SYSTEM POLICY FILTER) - Transcript of session follows - ... while talking to mail.isdg.net.: <<< 554 REJECTED BY SYSTEM POLICY FILTER 554 5.0.0 Service unavailable --w9OKWFSc027376.1540413135/mail.aegee.org Content-Type: message/delivery-status Reporting-MTA: dns; mail.aegee.org Received-From-MTA: DNS; ipbcc2def0.dynamic.kabel-deutschland.de Arrival-Date: Wed, 24 Oct 2018 20:32:10 GMT Final-Recipient: RFC822; hsan...@isdg.net Action: failed Status: 5.5.0 Diagnostic-Code: SMTP; 554 REJECTED BY SYSTEM POLICY FILTER Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On 10/10/2018 5:11 AM, Дилян Палаузов wrote: Hello, no feedbach means either everyboby agrees, nobody understands, or nobody cares. Generally, a bit of everything. I'm providing some comments because I am currently updating my DKIM ADSP/ATPS/DMARC implementation and need to take into account the MLM rewrite issue. I suggested introducing * fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3 ] for sending reports on failed DKIM-Signatures, only when they align, and * introducing r=a in DKIM-Signature [ https://tools.ietf.org/html/rfc6651#section-3.2] that only sends reports, when From: aligns. This way, once an email is intenionally modifed, the modifying software is aware that DMARC will trigger and rewrite From: so no distracting reports will be sent. I don't think we need a new DKIM-BASE DKIM-signature tag for what you want. This all starts with DKIM Policy (ADSP/DMARC) restrictive policies and receivers finally honoring them. This could be better done as a DMARC tag extension where it provides the MLM more DMARC mail handling information. For example, new DMARC tag extensions "rewrite=" and "fo=" rewrite=no default, rewriting SHOULD be avoided. rewrite=allow allow rewriting by domain with a p=none or no policy rewrite=strict allow rewriting by domain with a p=reject|quarantine policy fo=da send reports when rewriting is done Keep in mind that not every system will send reports. It is considered a high overhead with a high redundancy. Our implementation does not generate reports. Reporting adds a high barrier and technical implementation requirement. Reporting should be optional for implementation. Also keep in mind that the idea of "Rewriting" is not a "standard" concept. It is actually a long time mail engineering taboo to be destroying the originating author field for any mail platform, including RFC5322. Its a very sensitive design idea. Our MLM package does not rewrite. However, I am considering it now as a means to resolve the problem of errant DMARC/ADSP domains submitting public mailings using restrictive policies. I personally believe the DMARC/ADSP receiver can implement ATPS "Authorized Third-Party Signers" (RFC6541) but that didn't gain traction, so rewrite appears to be the only recourse.With more receivers now honoring the policies, it can cause a major havoc in a list subscription group. Since there are more MLM systems performing DMARC-based rewrites, I believe a better way to deal with this is for the MLM to reject the restrictive domain submission with an email response: "Sorry, your submission was prohibited due to a protected domain restrictive DMARC|ADSP policy." In fact, the MLM should stop all new subscriptions from domains using a restrictive policy. The rewrite should be the last thing to consider, and if it does rewrite, it should replace the original author domain strong policy with its own strong policy. For example, the ietf.org mailing list has begun to rewrite and it replaces the 5322.From with a dmarc.ietf.org domain, adds a new X-Original-From header and resigns the message using an ietf.org signer domain: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From; b=. X-Original-From: Hector Santos From: Hector Santos What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org. 2) It should has hash bind the X-Original-From header to the signature. Since DKIM recommends not to bind "X-" headers, a non "X-" header should be used, i.e. "Original-From:". This means adding the header to the 'h=" field to avoid potential mail resend exploits using different unprotected Original-from: fields. 3) and finally, the dmarc.ietf.org domain should have its own DMARC p=reject policy to effectively replace the one it circumvented with the submission. With these measures, the original author domain will still be protected with a DMARC policy when the MLM rewrites. That's my idea of a better approach to it as oppose to a blind, unprotected rewrite. I am looking for a way to get reports only when somebody unintentionally modifies an email. The reason for this is to have a system without unexplainable failures that makes it easy to fix broken DKIM signing/validating software. Remember, not all systems will send a report. I personally think a MLM should be playing an more active role to protect against DMARC -- who can subscribe, who can submit mail. If the domain is restrictive, it is possible to maybe only allow READ-ONLY mode and/or add a user subscriber option that says: [_] Rewrite the From
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hello, no feedbach means either everyboby agrees, nobody understands, or nobody cares. I suggested introducing * fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3 ] for sending reports on failed DKIM-Signatures, only when they align, and * introducing r=a in DKIM-Signature [ https://tools.ietf.org/html/rfc6651#section-3.2] that only sends reports, when From: aligns. Greetings Дилян This way, once an email is intenionally modifed, the modifying software is aware that DMARC will trigger and rewrite From: so no distracting reports will be sent. On Mon, 2018-08-20 at 19:32 +, Dilyan Palauzov wrote: > Hello, > > for fo=d is written: > > Generate a DKIM failure report if the message had a signature > that failed evaluation, regardless of its alignment. DKIM- > specific reporting is described in [AFRF-DKIM]. > > Once From: is rewritten by MLM, DKIM-Signature is preserved and does > not align anymore, fo=d;ruf=mailto: will generate a report. > > How is fo=d different than having r=y? I want to get repors about > failed DKIM validation only when the email was unintentionally > modified, or sender and verifier are not implemented correct and use > different logic to calculate the hashes. > > Do you suggest to include in RFC 7489bis (DMARC) everything from RFC > 6651, except r=y and ADSP? > > Removing r=y from DKIM-Signature is indeed untrackable operation, but > why should it be? DKIM-Signatures are partially self-signed, however > I proposed to remove r=y only when DKIM-Signature is intentionally > invalidated and in this case the signature is not damaged additionally > by removing r=y. > > I do not insist on removing r=y from DKIM-Signature. I am looking for > a way to get reports only when somebody unintentionally modifies an > email. The reason for this is to have a system without unexplainable > failures that makes it easy to fix broken DKIM signing/validating > software. Repeating myself, when the aggregate reports show that 1% > of the emails are signed wrongly, there is no way to debug the problem > and fix. Before this fixed DMARC cannot be introduced, neither for > incoming nor for outgoing mails. > > Some suggest to remove DKIM-Signature when the mail is modified > intentionally (by MLM), mailman logic is to keep the invalidated > DKIM-Signatures on their path to implement ARC > > I don't like the idea of sending reports about unaligned > DKIM-Signatures (rewritten From: by MLM), as this allow a mailing list > subscriber posting to the list to get a list of all subscribers, but > the list of subscribers might be private. > > How about introducing fo=da for sending reports on failed > DKIM-Signatures, only when they align? This is much like having r=a > in DKIM-Signature that only sends reports, when From: aligns. This > way, once an email is intenionally modifed, the modifying software is > aware that DMARC will trigger and rewrite From: so no distracting > reports will be sent. > > Greetings > Дилян > > ----- Message from Alessandro Vesely - > Date: Mon, 20 Aug 2018 11:31:09 +0200 > From: Alessandro Vesely > Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM > To: ietf-dkim@ietf.org > > > > Hi! > > > > On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote: > > > I cannot provide very useful experience: > > > > Thank you for the overview. Albeit low-volume, it confirms my feeling that > > rfc6651 is not widely adopted. > > > > > [...] > > > - state explicitly that providers who want reports about mismatched > > > DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=... > > > > ruf= suffices. p=reject;pct=0; is to force MLMs to rewrite From:, so as to > > avoid useless reports. However, what one deems useless could be interesting > > for another; for example, one might use aggregate reports triggered by MLM > > sending as a sort of delivery notification, thereby achieving a > > partial list of > > subscribers' domains. One-man-and-for-fun provider's subscription is easily > > betrayed that way. > > > > > > > Why shall software that knows r=y is old-fashion not remove it from > > > DKIM-Signature:, in order to ensure that r=y is not interepreted later by > > > software, that doesn't know r=y was moved to historic? > > > > Let me recall that the DKIM-Signature header field is implicitly signed; > > that > > is, if you alter it any way, it won't verify any more. Removal of > > r=y would be > > nearly impossible to undo, unless y
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hello, for fo=d is written: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM- specific reporting is described in [AFRF-DKIM]. Once From: is rewritten by MLM, DKIM-Signature is preserved and does not align anymore, fo=d;ruf=mailto: will generate a report. How is fo=d different than having r=y? I want to get repors about failed DKIM validation only when the email was unintentionally modified, or sender and verifier are not implemented correct and use different logic to calculate the hashes. Do you suggest to include in RFC 7489bis (DMARC) everything from RFC 6651, except r=y and ADSP? Removing r=y from DKIM-Signature is indeed untrackable operation, but why should it be? DKIM-Signatures are partially self-signed, however I proposed to remove r=y only when DKIM-Signature is intentionally invalidated and in this case the signature is not damaged additionally by removing r=y. I do not insist on removing r=y from DKIM-Signature. I am looking for a way to get reports only when somebody unintentionally modifies an email. The reason for this is to have a system without unexplainable failures that makes it easy to fix broken DKIM signing/validating software. Repeating myself, when the aggregate reports show that 1% of the emails are signed wrongly, there is no way to debug the problem and fix. Before this fixed DMARC cannot be introduced, neither for incoming nor for outgoing mails. Some suggest to remove DKIM-Signature when the mail is modified intentionally (by MLM), mailman logic is to keep the invalidated DKIM-Signatures on their path to implement ARC I don't like the idea of sending reports about unaligned DKIM-Signatures (rewritten From: by MLM), as this allow a mailing list subscriber posting to the list to get a list of all subscribers, but the list of subscribers might be private. How about introducing fo=da for sending reports on failed DKIM-Signatures, only when they align? This is much like having r=a in DKIM-Signature that only sends reports, when From: aligns. This way, once an email is intenionally modifed, the modifying software is aware that DMARC will trigger and rewrite From: so no distracting reports will be sent. Greetings Дилян - Message from Alessandro Vesely - Date: Mon, 20 Aug 2018 11:31:09 +0200 From: Alessandro Vesely Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM To: ietf-dkim@ietf.org Hi! On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote: I cannot provide very useful experience: Thank you for the overview. Albeit low-volume, it confirms my feeling that rfc6651 is not widely adopted. [...] - state explicitly that providers who want reports about mismatched DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=... ruf= suffices. p=reject;pct=0; is to force MLMs to rewrite From:, so as to avoid useless reports. However, what one deems useless could be interesting for another; for example, one might use aggregate reports triggered by MLM sending as a sort of delivery notification, thereby achieving a partial list of subscribers' domains. One-man-and-for-fun provider's subscription is easily betrayed that way. Why shall software that knows r=y is old-fashion not remove it from DKIM-Signature:, in order to ensure that r=y is not interepreted later by software, that doesn't know r=y was moved to historic? Let me recall that the DKIM-Signature header field is implicitly signed; that is, if you alter it any way, it won't verify any more. Removal of r=y would be nearly impossible to undo, unless you know r=y was present and where exactly it was placed. Remove the whole field or rename it to, say, Old-DKIM-Signature. BTW, some signatures are weak enough to survive boilerplate changes. In that case, the signer might be interested in verification failures even after MLM changes. How would you treat that instance? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim - End message from Alessandro Vesely - ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hi! On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote: > > I cannot provide very useful experience: Thank you for the overview. Albeit low-volume, it confirms my feeling that rfc6651 is not widely adopted. > [...] > - state explicitly that providers who want reports about mismatched > DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=... ruf= suffices. p=reject;pct=0; is to force MLMs to rewrite From:, so as to avoid useless reports. However, what one deems useless could be interesting for another; for example, one might use aggregate reports triggered by MLM sending as a sort of delivery notification, thereby achieving a partial list of subscribers' domains. One-man-and-for-fun provider's subscription is easily betrayed that way. > Why shall software that knows r=y is old-fashion not remove it from > DKIM-Signature:, in order to ensure that r=y is not interepreted later by > software, that doesn't know r=y was moved to historic? Let me recall that the DKIM-Signature header field is implicitly signed; that is, if you alter it any way, it won't verify any more. Removal of r=y would be nearly impossible to undo, unless you know r=y was present and where exactly it was placed. Remove the whole field or rename it to, say, Old-DKIM-Signature. BTW, some signatures are weak enough to survive boilerplate changes. In that case, the signer might be interested in verification failures even after MLM changes. How would you treat that instance? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat 18/Aug/2018 23:45:40 +0200 Murray S. Kucherawy wrote:
>
> OpenDKIM still implements RFC6651 and finds it useful for debugging
> problems with new implementations, so at least from that perspective I
> don't think historical status for it is warranted. If an update is needed
> to cover the issues raised here, that's possibly worth pursuing.
The difference w.r.t. DMARC is that it is the signer, not necessarily the
author's domain owner, who gets the report. So, yes, rfc6651 has its own
worthiness. The part related to ADSP, however, deserves to be demoted to
Historic.
IMHO, updating rfc665{1,2} should be done after rfc7489bis, moving the format
definitions to the latter spec, for the reasons explained in my previous
message.
Best
Ale
--
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat, Aug 18, 2018 at 10:42 PM, Dilyan Palauzov wrote: > I suggested to write in ARC to alter the existing signature. > As I said before, I suspect you will have a hard time selling an "alter the existing signature" idea no matter what document you propose to create or update. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat, Aug 18, 2018 at 8:30 PM, Dilyan Palauzov wrote: > Two out of two responders were against removing r=y from the > DKIM-Signature. > > I am fine with removing the invalidated DKIM-Signatures, but mailman > developers are not (https://gitlab.com/mailman/mailman/issues/500) as > this were incompable with ARC. > > What about writing in ARC, which I have not read, to remove r=y, before > handling DKIM-Signature:s? > Do you mean for ARC to ignore "r=y"? Otherwise, isn't this again altering an existing signature, which consensus (so far) disagrees with? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hello, let's first agree on how to technically approach this and only afterwards concentrate on the target specification that needs adjustments. What to do? Two out of two responders were against removing r=y from the DKIM-Signature. I am fine with removing the invalidated DKIM-Signatures, but mailman developers are not (https://gitlab.com/mailman/mailman/issues/500) as this were incompable with ARC. What about writing in ARC, which I have not read, to remove r=y, before handling DKIM-Signature:s? Regards Дилян - Message from "Murray S. Kucherawy" - Date: Sat, 18 Aug 2018 15:02:35 -0700 From: "Murray S. Kucherawy" Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM To: Dilyan Palauzov Cc: Ietf-dkim@ietf.org On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov wrote: I suggest here in to suggest in a more formal manner, that MLMs modifying a message are supposed to remove the r=y part of just invalidated DKIM-Signature and this logic is also applied for ARC, if relevant (I don't know ARC). Fixing only ARC will not help, as there is software that follows DKIM, but has no idea about ARC. Is such a recommendation a good idea? How to make the recomentation? Amendment to RFC6377, amendment to RFC 6651, something else, that is very short to compose? I think advising anyone to alter a signature on a message irrespective of the signature's validity will be hard to sell. It would be simpler to just remove the signature entirely if there's a good reason not to want it there anymore. This unfortunately seems a rather small thing for which to spin up an update to either RFC6377 or RFC6651. Are there any other things that have evolved since those documents were published that might make revisions worth doing? -MSK - End message from "Murray S. Kucherawy" - ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov wrote: > I suggest here in to suggest in a more formal manner, that MLMs modifying > a message are supposed to remove the r=y part of just invalidated > DKIM-Signature and this logic is also applied for ARC, if relevant (I don't > know ARC). Fixing only ARC will not help, as there is software that > follows DKIM, but has no idea about ARC. > > Is such a recommendation a good idea? > > How to make the recomentation? Amendment to RFC6377, amendment to RFC > 6651, something else, that is very short to compose? > I think advising anyone to alter a signature on a message irrespective of the signature's validity will be hard to sell. It would be simpler to just remove the signature entirely if there's a good reason not to want it there anymore. This unfortunately seems a rather small thing for which to spin up an update to either RFC6377 or RFC6651. Are there any other things that have evolved since those documents were published that might make revisions worth doing? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat, Aug 18, 2018 at 2:45 PM, Murray S. Kucherawy wrote: > On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely wrote: > >> > The DKIM aggregate reports show whether a server signs correctly all >> mails or >> > not. If the aggregate reports show that this is sometimes (let's say >> in 1%) >> > not done correctly, the signer has no way to find for which email the >> signing >> > has not worked and cannot fix the signing software, unless a report for >> the >> > failing mail is sent with r=y. >> >> Well, nope. Aggregate reports belong to DMARC. Consider adding a rua= >> address >> to your DMARC record. Sometimes aggregate reports allow a postmaster to >> pin >> which message triggered it. If you also set a ruf= address, you might >> receive >> ARF reports as well. >> > > +1. > Actually, Dilyan is correct; RFC6651 introduced a reporting stream independent of DMARC. I've no data about how widely it's used outside of OpenDKIM, however, but it's not strictly a DMARC or ARC mechanism. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hello, I cannot provide very useful experience: - On r=y almost nobody sends such reports, except very tiny one-man-and-for-fun providers. - The server I run is used primary for incoming emails, users send mails From: the managed domain using other servers, and these emails do not have DKIM-Signature: r=y from my domain. So my conslusions are mainly about emails I send myself. It is about 3-10 emails per month. - The reports I get are sent either because the report-evaluator has bugs, because some MTA does illegal rewritings (like inserting newline in "From: me <1...@example.org>,you <2...@example.int>" between >, and you) , or because the mail was modified by a MLM. But checking each single report for the failure reason is too much time, and I prefer not get such reports, when the mails were intentionally modified. - The server manages mailing lists in a sub-domain, where all emails are signed, but it turns out that email addresses subscribed to a mailing list are not mailing list on their own hosted somewhere else. Emails running over the mailing lists, do not generate reports on r=y, partially because the signatures are not broken and partially because almost all providers ignore r=y. I repeat my self, but the problem was, that I used software for attaching DKIM-Signature to the emails, and the aggregate reports showed that this does not work 100% reliably. I started inserting r=y with the hope, that I will get reports on broken emails, but nearly nobody sends such reports, so r=y has not helped to fix the software i use. fo=d is independent of r=y. The reason to raise the topic, is that mailman developers will not remove r=y, unless there is a formal recommentation. I wanted to deploy DMARC policy reject (or quarantine) once I am sure, that the DKIM signature are 100% correct. I thought there is only one way to get report per failed DKIM signature and this way was to use r=y. I do not sign all emails that come from my domain, as users can use any servers, to send mail from the domain. But if an email is signed by me, I want to be notified when the signature is considered for some reason invalid, in order to ensure that the signing software works correct. fo=d would generate reports for all emails without DKIM-Signature, that is not what I want. ARC. ARF, DMARC, DKIM, Mailing lists... this thread it about DKIM, ARF-reports and recommendations about mailing lists. For this reason I have not contacted the DMARC WG, most of the subscribers are anyway likely to be the same of both ietf mailing lists. Rewriting From: by the MLM does not help with r=y. If r=y / RFC6651 is moved to historic, then RFC6652 is also historic. Do you suggest to: - ignore r=y, move RFC6651 to historic - state explicitly that providers who want reports about mismatched DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=... - hint that fo=1 is not superset of fo=d - do something similar with RFC6652 and SPF Why shall software that knows r=y is old-fashion not remove it from DKIM-Signature:, in order to ensure that r=y is not interepreted later by software, that doesn't know r=y was moved to historic? Greetings Дилян - Message from Alessandro Vesely - Date: Fri, 17 Aug 2018 13:15:48 +0200 From: Alessandro Vesely Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM To: Dilyan Palauzov , Ietf-dkim@ietf.org Hi all! On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote: RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting) adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does not validate, the signing server is notified that something went (unintentionally) wrong. Interesting. I knew about rfc6651, but never cared to implement it. Would you write for those like me a short overview of your experience with your arf+dkim-report mailbox, mentioning e.g. how long have you implemented it for, the rough amount of reports / reporting domains that hit it, and the like, please? The DKIM aggregate reports show whether a server signs correctly all mails or not. If the aggregate reports show that this is sometimes (let's say in 1%) not done correctly, the signer has no way to find for which email the signing has not worked and cannot fix the signing software, unless a report for the failing mail is sent with r=y. Well, nope. Aggregate reports belong to DMARC. Consider adding a rua= address to your DMARC record. Sometimes aggregate reports allow a postmaster to pin which message triggered it. If you also set a ruf= address, you might receive ARF reports as well. Perhaps, rfc7489 is not very clear in the explanation of dmarc-fo. Does fo=d provide for sending a report irrespectively of r=y? MDaemon's implementation, for one, interprets the reference to rfc6651 as a requirement for requesters
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hi all! On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote: > > RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for Failure > Reporting) > adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does > not validate, the signing server is notified that something went > (unintentionally) wrong. Interesting. I knew about rfc6651, but never cared to implement it. Would you write for those like me a short overview of your experience with your arf+dkim-report mailbox, mentioning e.g. how long have you implemented it for, the rough amount of reports / reporting domains that hit it, and the like, please? > The DKIM aggregate reports show whether a server signs correctly all mails or > not. If the aggregate reports show that this is sometimes (let's say in 1%) > not done correctly, the signer has no way to find for which email the signing > has not worked and cannot fix the signing software, unless a report for the > failing mail is sent with r=y. Well, nope. Aggregate reports belong to DMARC. Consider adding a rua= address to your DMARC record. Sometimes aggregate reports allow a postmaster to pin which message triggered it. If you also set a ruf= address, you might receive ARF reports as well. Perhaps, rfc7489 is not very clear in the explanation of dmarc-fo. Does fo=d provide for sending a report irrespectively of r=y? MDaemon's implementation, for one, interprets the reference to rfc6651 as a requirement for requesters to set r=y in their DKIM signatures: When the DMARC "fo=" tag requests reporting of DKIM related failures, MDaemon sends DKIM failure reports according to RFC 6651. Therefore, that specification's extensions must be present in the DKIM-Signature header field, and the domain must publish a valid DKIM reporting TXT record in DNS. DKIM failure reports are not sent independent of DMARC processing or in the absence of RFC 6651 extensions. http://help.altn.com/mdaemon/en/security--dmarc_reporting.htm > RFC6377 (DomainKeys Identified Mail (DKIM) and Mailing Lists) suggests in > section 5.7 to remove the invalidated DKIM-Signagures, if the mailing list > software has changed the email. > > I have not read ARC, but I have the impression that it says to keep the > invalidated DKIM-Signatures. > > When an email with DKIM-Signagure: r=y is sent to a mailing list, the email is > modified, and a final recipient following r=y sends a report. The problem is > that this report is useless and distracting - it does not indicate, that the > signer-MTA or validator-MTA are implemented in wrong way. Correct. MLMs affect DMARC too. > I suggest here in to suggest in a more formal manner, that MLMs modifying a > message are supposed to remove the r=y part of just invalidated DKIM-Signature > and this logic is also applied for ARC, if relevant (I don't know ARC). > Fixing > only ARC will not help, as there is software that follows DKIM, but has no > idea > about ARC. AFAIK, ARC is not involved in reporting. My feeling is that the whole topic now belongs to DMARC's territory. Let me skip the long winded story of the ideas for solving the MLMs problem of DMARC. Suffice it to say that there is a dmarc WG[*], which is where ARC comes from. Meanwhile, the MLMs problem is being solved by rewriting From:. This doesn't help r=y. However, I'm reluctant to elect to rewrite DKIM signatures. A broken signature can still be recovered by manually undoing the obvious modifications applied by MLMs, see attached screenshot. As for rfc6651, it also specifies how to obtain reports for ADSP, which was moved to Historical status. Unless your experience testifies to a relevant community traction, I'd propose rfc6651 be moved to Historical status too, and its format description be moved to rfc7489bis, whenever it comes about. Best Ale -- [*] https://datatracker.ietf.org/wg/dmarc/about/ ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
