Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> In message <6585e535.11582.3a72...@postmaster.inter-corporate.com>, > Randolf Richardson, Postmaster via mailop writes > > >> The most commonly seen method of tracking is probably inclusion of > >> specifically crafted links in the message, that refer to a tracking server > >> run by the sender, so the sender knows if the recipient clicked on a link > >> in > >> the message. > > > > You're entirely correct -- thanks for adding this as I wasn't even > >thinking of it. > > ask most any ESP .. this works poorly these days, robots click on the > links to make sure they are safe and mailbox provides pre-fetch images > for reasons of performance, safety and (tada !) to make tracking harder We are an ESP, and this is something we're considering in the future, along with a variety of other techniques. We haven't spoken with other ESPs about this sort of thing. > >> >Some of our clients are investigators, lawyers, etc., who > >> > occasionally need high quality (read "reliable") evidence for the > >> > cases they're working on. DKIM, when available, makes it easier to > >> > authenticate eMail evidence in a way that can satisfy these needs. > > people who speculate about lawyers need are generally not lawyers. I've The movie-making industry is probably the worst offender of getting factual things like this wrong. :D > been an expert witness on email related cases often enough to know that > they are often perfectly satisfied to have a description of a well- > formed set of Received header fields... I agree as I've done this too. In my experience, most of requests were early enough that the evidence was helpful in changing the case direction toward a settlement rather than taking the matter to court. > ... usual quote : if you think cryptography solves your problem then you > don't understand cryptography and you don't understand your problem Right. > Investigators are even less interested in proof, they're reading all the > headers, checking DNS records and jumping to (usually plausible) > conclusions ! It depends on the investigators/lawyers. Many do want the quick and easy approach, but I have encountered some who do want more detail to make a better case. > > Some of the investigators I've dealt with neededd to deal with this > >specific scnario where someone denied sending an eMail. Although > >DKIM can help, if the server logs haven't cycled out yet then an > >affirmed affidavit that the mail server log entries are authentic has > >almost always been sufficient for motivating the denying party to > >suddenly remember that they did send the message. > > exactly ... (remember civil cases work on the balance of > probabilities).. and also remember that there is account takeover, > people in your household who know your passwords better than you do and > that's before you get into all the BGP, NTP etc exotica (if that > interests you then I once wrote a PhD thesis on all the assumptions we > make about "traceability" and the circumstances in which they go wrong) As I recall, those were probably all civil cases/investigations. Would you mind sending me a linjk to your thesis? That's an interesting topic, and based on what you've written I get the impression that you have a lot more experience than I do. > -- > richard Richard Clayton > > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
In message <6585e535.11582.3a72...@postmaster.inter-corporate.com>, Randolf Richardson, Postmaster via mailop writes >> The most commonly seen method of tracking is probably inclusion of >> specifically crafted links in the message, that refer to a tracking server >> run by the sender, so the sender knows if the recipient clicked on a link in >> the message. > > You're entirely correct -- thanks for adding this as I wasn't even >thinking of it. ask most any ESP .. this works poorly these days, robots click on the links to make sure they are safe and mailbox provides pre-fetch images for reasons of performance, safety and (tada !) to make tracking harder >> >Some of our clients are investigators, lawyers, etc., who >> > occasionally need high quality (read "reliable") evidence for the >> > cases they're working on. DKIM, when available, makes it easier to >> > authenticate eMail evidence in a way that can satisfy these needs. people who speculate about lawyers need are generally not lawyers. I've been an expert witness on email related cases often enough to know that they are often perfectly satisfied to have a description of a well- formed set of Received header fields... ... usual quote : if you think cryptography solves your problem then you don't understand cryptography and you don't understand your problem Investigators are even less interested in proof, they're reading all the headers, checking DNS records and jumping to (usually plausible) conclusions ! > Some of the investigators I've dealt with neededd to deal with this >specific scnario where someone denied sending an eMail. Although >DKIM can help, if the server logs haven't cycled out yet then an >affirmed affidavit that the mail server log entries are authentic has >almost always been sufficient for motivating the denying party to >suddenly remember that they did send the message. exactly ... (remember civil cases work on the balance of probabilities).. and also remember that there is account takeover, people in your household who know your passwords better than you do and that's before you get into all the BGP, NTP etc exotica (if that interests you then I once wrote a PhD thesis on all the assumptions we make about "traceability" and the circumstances in which they go wrong) -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop > pisze: > > > Tracking/spying elements in email messsages are usually intended to spy on > > > the *recipient* - did the recipient read the email at all, did he clicked > > > on a link in the email etc. > > > > ...mail server logs would be one obvious angle, but even that would > > require additional effort to extract the target user's eMail activity > > since mail server logs cycle through pretty quickly (at least on a > > lot of busy Linux systems, anyway). Log retention is generally used > > for troubleshooting, so a long-term retention usually isn't needed. > > > > Another method is for a malicious sender to deceptively include > > tracking software in an attachment. Most security software stops > > this, which includes security daemons on mail servers that can also > > be combined with blacklists of IP addresses and/or domain names that > > distribute malicious eMails or are otherwise-infected systems that > > can be used to commit such types of SMTP abuse. > > The most commonly seen method of tracking is probably inclusion of > specifically crafted links in the message, that refer to a tracking server > run by the sender, so the sender knows if the recipient clicked on a link in > the message. You're entirely correct -- thanks for adding this as I wasn't even thinking of it. > Also the HTML-formatted message may include images loaded from sender's > server, which can also be used to track whether the recipient has opened the > message at all. Yes, that's another risk, and it's probably a lot more effective than attaching a SpyWare payload in a file attachment since most users have anti-virus software these days. > But all this has absolutely nothing to do with message being DKIM-signed. Yes. > > > What does one have to do with the other and to the discussion about > > > publishing keys (the latter - to my understanding - serves only possible > > > legal purposes in case the sender needs to deny the fact that he sent the > > > message, which for me is a completely made-up scenario, an absolute > > > fiction). > > > > Some of our clients are investigators, lawyers, etc., who > > occasionally need high quality (read "reliable") evidence for the > > cases they're working on. DKIM, when available, makes it easier to > > authenticate eMail evidence in a way that can satisfy these needs. > > > > While this doesn't happen very often, I'd say that, since its > > inception, DKIM-based authenticity has moved from being a completely > > made-up scenario to having some actual utility. > > I was not talking about *confirming* the authenticity of a message by means > of a DKIM signature, but the opposite - what was being discussed here, ie. > the possibility for the sender to *deny* that he has sent the message > (despite it being DKIM signed), because of previous publication of the DKIM > private key. That seems a fictional scenario for me. Thanks for clarifying. Some of the investigators I've dealt with neededd to deal with this specific scnario where someone denied sending an eMail. Although DKIM can help, if the server logs haven't cycled out yet then an affirmed affidavit that the mail server log entries are authentic has almost always been sufficient for motivating the denying party to suddenly remember that they did send the message. DKIM can be helpful as additional supporting evidence in these cases, or even be used as a substitute where mail server logs aren't available. But the problem with this is that DKIM doesn't protect individual senders, and it also doesn't protect against someone else using another person's eMail credentials (or controlling a computer they're logged in to, etc.). > -- > Regards, >Jaroslaw Rafa >r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
Dnia 22.12.2023 o godz. 10:54:54 Randolf Richardson, Postmaster via mailop pisze: > > Tracking/spying elements in email messsages are usually intended to spy on > > the *recipient* - did the recipient read the email at all, did he clicked > > on a link in the email etc. > > ...mail server logs would be one obvious angle, but even that would > require additional effort to extract the target user's eMail activity > since mail server logs cycle through pretty quickly (at least on a > lot of busy Linux systems, anyway). Log retention is generally used > for troubleshooting, so a long-term retention usually isn't needed. > > Another method is for a malicious sender to deceptively include > tracking software in an attachment. Most security software stops > this, which includes security daemons on mail servers that can also > be combined with blacklists of IP addresses and/or domain names that > distribute malicious eMails or are otherwise-infected systems that > can be used to commit such types of SMTP abuse. The most commonly seen method of tracking is probably inclusion of specifically crafted links in the message, that refer to a tracking server run by the sender, so the sender knows if the recipient clicked on a link in the message. Also the HTML-formatted message may include images loaded from sender's server, which can also be used to track whether the recipient has opened the message at all. But all this has absolutely nothing to do with message being DKIM-signed. > > What does one have to do with the other and to the discussion about > > publishing keys (the latter - to my understanding - serves only possible > > legal purposes in case the sender needs to deny the fact that he sent the > > message, which for me is a completely made-up scenario, an absolute > > fiction). > > Some of our clients are investigators, lawyers, etc., who > occasionally need high quality (read "reliable") evidence for the > cases they're working on. DKIM, when available, makes it easier to > authenticate eMail evidence in a way that can satisfy these needs. > > While this doesn't happen very often, I'd say that, since its > inception, DKIM-based authenticity has moved from being a completely > made-up scenario to having some actual utility. I was not talking about *confirming* the authenticity of a message by means of a DKIM signature, but the opposite - what was being discussed here, ie. the possibility for the sender to *deny* that he has sent the message (despite it being DKIM signed), because of previous publication of the DKIM private key. That seems a fictional scenario for me. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period (anti-forgery vs. anti-spying)
> Dnia 22.12.2023 o godz. 16:22:45 Slavko via mailop pisze: > > But my point was (mostly) not about courties cases, i mean usual users > > tracking/spying (contacts, shoppings, opinions, etc), where signature is > > checked once (at receive time), but used/stored forever. And that cannot > > be solved by rotation nor by publishing nor by any cryptographic method > > (which i am aware of). > > I'm sorry, but I don't understand how in your view the fact that message is > DKIM signed is related to tracking/spying etc. I agree: it's not for tracking/spying since it's for authenticating the sender's identity (as an authorized user)... > Tracking/spying elements in email messsages are usually intended to spy on > the *recipient* - did the recipient read the email at all, did he clicked > on a link in the email etc. ...mail server logs would be one obvious angle, but even that would require additional effort to extract the target user's eMail activity since mail server logs cycle through pretty quickly (at least on a lot of busy Linux systems, anyway). Log retention is generally used for troubleshooting, so a long-term retention usually isn't needed. Another method is for a malicious sender to deceptively include tracking software in an attachment. Most security software stops this, which includes security daemons on mail servers that can also be combined with blacklists of IP addresses and/or domain names that distribute malicious eMails or are otherwise-infected systems that can be used to commit such types of SMTP abuse. > On the other hand, DKIM signature identifies the *sender* of the message. That's the reason we use DKIM, and we reject DKIM-detectable forgeries to make eMail safer for our users, which is also helpful to other mail server operators who put the effort into setting up SPF, DMARC, and DKIM to protect the domains they're responsible for. > What does one have to do with the other and to the discussion about > publishing keys (the latter - to my understanding - serves only possible > legal purposes in case the sender needs to deny the fact that he sent the > message, which for me is a completely made-up scenario, an absolute > fiction). Some of our clients are investigators, lawyers, etc., who occasionally need high quality (read "reliable") evidence for the cases they're working on. DKIM, when available, makes it easier to authenticate eMail evidence in a way that can satisfy these needs. While this doesn't happen very often, I'd say that, since its inception, DKIM-based authenticity has moved from being a completely made-up scenario to having some actual utility. The most compelling case for me though is that users typically don't want to contend with forgeries of known vendors and other parties they routinely interact with, so rejecting all detectable forgeries with the help of SPF and DKIM is a solution that works well. > I cannot understand what topic you're actually discussing in this thread. It was probably just a misunderstanding of the uses of DKIM. > -- > Regards, >Jaroslaw Rafa >r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Postmaster - postmas...@inter-corporate.com Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada https://www.inter-corporate.com/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
On Thu 21/Dec/2023 22:26:34 +0100 Gellner, Oliver wrote: If Google would have published their DKIM private key after it was rotated in 2016, checking the DKIM signature in 2020 would have proven nothing. Yet, if the message was ARC-sealed on forwarding and the forwarder didn't rotate and publish its keys, repudiation would still be unavailable. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
Dnia 22.12.2023 o godz. 16:22:45 Slavko via mailop pisze: > But my point was (mostly) not about courties cases, i mean usual users > tracking/spying (contacts, shoppings, opinions, etc), where signature is > checked once (at receive time), but used/stored forever. And that cannot > be solved by rotation nor by publishing nor by any cryptographic method > (which i am aware of). I'm sorry, but I don't understand how in your view the fact that message is DKIM signed is related to tracking/spying etc. Tracking/spying elements in email messsages are usually intended to spy on the *recipient* - did the recipient read the email at all, did he clicked on a link in the email etc. On the other hand, DKIM signature identifies the *sender* of the message. What does one have to do with the other and to the discussion about publishing keys (the latter - to my understanding - serves only possible legal purposes in case the sender needs to deny the fact that he sent the message, which for me is a completely made-up scenario, an absolute fiction). I cannot understand what topic you're actually discussing in this thread. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM validity period
Dňa 21. decembra 2023 21:26:34 UTC používateľ "Gellner, Oliver via mailop" napísal: >If Google would have published their DKIM private key after it was rotated in >2016, checking the DKIM signature in 2020 would have proven nothing. Yes, checking that signature in 2020 is pointless. But if you checked it before rotation it was fully validated. The all magic then matter only on fact how to prove, when you did the check. I am sure, that you are aware of systems which can prove time of operation, eg. accounting... (again, hard to name them in English for me) But my point was (mostly) not about courties cases, i mean usual users tracking/spying (contacts, shoppings, opinions, etc), where signature is checked once (at receive time), but used/stored forever. And that cannot be solved by rotation nor by publishing nor by any cryptographic method (which i am aware of). Sure, DKIM doesn't identifies individual users, but signed message has significantly higher value than (random/faked) not signed. >Yes, I agree. Because the users have no control over the DKIM signature and >often don’t even know it exists, it would be especially important for large >ESPs to publish their old keys. Try to ask regular users (and not only gmail/outlook/etc) if they searched if his/her ESP published keys. I ask them (from time to time) and i almost always get: "What? DKIM? Keys???" :-) regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ECDSA DKIM validation?
On Thu, 21 Dec 2023, Stuart Henderson wrote: If you've had to talk someone not very technical through adding a DKIM RSA key to a poorly implemented web interface from some cheap DNS provider that doesn't handle long TXT records, you might feel differently. I take your point but I can only have limited sympathy for "you have to change your correctly working mail system because we don't care enough to fix our broken DNS crudware." There is often a workaround in that case - using 1024 bit keys - but then there *is* a cryptographic problem. A 1536 bit key should fit in one string and that's plenty long for the forseeable future. The largest RSA number known to be factored is 829 bits, and that's nearly twice the length. Keep in mind that DKIM keys are intended to protect messages for a few weeks, not years, so expensive attacks aren't worth it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ECDSA DKIM validation?
> On 21 Dec 2023, at 17:13, John R Levine via mailop wrote: > > On Thu, 21 Dec 2023, Mike Hillyer wrote: >> John Said: >> >>> I'm sure that Google has code somewhere that can validate ED25519 >>> signatures. But that does not mean that it would be a good idea for them >>> to use that code in production today and try to update their reputation >>> systems to deal with the dual signing that implies. >> >> With the number of messages already arriving with multiple DKIM signatures I >> can't imagine their reputation systems don't already handle dual signing >> just fine. Granted this would be two signatures on the same domain, but that >> seems that a small change from handling a signature on the From plus one >> from the ESP and maybe even one for the list-unsubscribe domain. > > If there's two signatures for the same domain, one is good and one is bad, > which do you believe? I know what the spec says, but we have no practical > experience. For a while we were checking DKIM with 2 different parsers. There were keys that passed in one parser and not the other. It was consistent across signing - so all microsoft signatures failed with parser 1 and passed with parser 2. But there were other signatures that passed with parser 1 and failed with parser 2. Point is, I have orthogonal experience to the one you’re positing: same signature, 2 different results using two different parsers. I believed the one that passed (ie, I believed it was validly signed by the responsible domain). Laura > In any event, as I've said at least three times now, RSA keys are fine for > the forseeable future so there is no benefit to using ED25519 keys unless > there is an unexpected key break. -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
