[Ietf-dkim] Re: DKIM with body length
On Fri, 24 May 2024, Jon Callas wrote: blank lines.) Maybe you can tell it's from a list and the crud is benign, or maybe you can't and you should treat it as suspicious. And yet, I didn't make up the word robustness, it's there in the spec as Dave quoted. When I read the whole paragraph, the message I get is that l= is intended to survive mailing lists but it has many problems so don't use it. My recollection is that for a few features like l=, most of us found them useless, a few people really really wanted them, so that paragraph was a way to get the document out the door. Twenty years ago there was no DMARC* and the issue was that until DKIM became more widely used, mail from dusty lists would have no signatures at all. In fact lists did start signing pretty quickly, list mail all has DKIM reputation and that particular issue is moot. I do not ever recall l= being an proposed as an invitation to recipient systems to do surgery on incoming mail. If anyone had ever suggested that, I'm sure I'm not the only list manager who would have been sure to strip any l= signatures to prevent downstream funny business. 1) It appears that the issue with l= is that implementers are not doing it correctly, ... If there ever was a correct way to use l=, there sure isn't now. But per your next message we seem to agree on the outcome. R's, John * - nobody used ADSP ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
According to Scott Kitterman : Honestly, I think l= is an idea whose time has passed (if it ever existed at all). We ought to just kill it using the simplest procedural mechanism available. We can do an update to deprecate l= but I think that if we just adjusted our validation software to ignore l= the failure rate would be vanishingly low. The ESP that was using l=1 has stopped. Ironport systems sign the entire body and set l= to the body length, so even if you ignore the l=, the signature on an unmodified message will still validate. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On Thu, 23 May 2024, Philip Guenther wrote: I said "this current round of visibility", a statement which implies _previous_ rounds of visibility of a NOT NEW thing. Sorry, I don't understand what you think is invisible here. I think it could be useful to leverage the current round of publicity to fix more than the specific problem, but it sounds like you believe that's a lost cause and reiterating advice is ineffective. Oh well. General advice to the world, nope. Identifying specific senders with the l= problem has been quite effective. We've found an ESP who was signing with l=1 and has now stopped. It appears that a lot of the others have poorly configured Ironport devices so who do we know at Ironport? By the way, I see from IETF mailing list logs that Ironport users have been signing with l= and no Content-Type for most of a decade and nobody has noticed until now. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On Thu, 23 May 2024, Philip Guenther wrote: ** or don't over-sign and clients use the first found... I would prefer not to go there. A message with two Content-Type headers or two Subject headers or Date or Message-ID and so forth is not a valid message, and a DKIM signer or validator should just say no. I'm not familiar with DKIM validators that also apply those sorts of "too many instances of a field" rules. Perhaps it would make sense to talk about that in a revision of the DKIM rfc, ... More than a decade ago Doug Otis went on endlessly about adding an extra subject line, which indeed in some cases would get past a DKIM validator, and pretty much randomly MUAs might show one subject or the other. You can do much more effective filtering by assuming defective messages are spam, which they invariably are, rather than screwing around with signatures on them. This current round of visibility on risks of the l= tag and not signing content-type is a moment where *signers* are being prodded and updating their configurations. ,,, For about the tenth time, this particular issue is specifically called out in RFC 6376. It is not new, it is not interesting beyond noticing that a trickle of signers still get it wrong. If people don't read the spec, there's not much we can do about it. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On Thu, 23 May 2024, Philip Guenther wrote: There's a related, though much less general, attack that works even if you don't use the l= tag: on a message which has nested multiparts, there are multiple potential delimiters that will look legit to a MIME parser, so if you don't sign Content-Type** then an attacker can change the delimiter from the outermost to a inner delimiter and make it appear that the sender directly sent just that inner content, possibly resulting in misattribution. ** or don't over-sign and clients use the first found... I would prefer not to go there. A message with two Content-Type headers or two Subject headers or Date or Message-ID and so forth is not a valid message, and a DKIM signer or validator should just say no. Before anyone mentions the robustness principle, it says to be liberal *where the spec is ambiguous" which it is not here, and to be prepared to recognize and reject garbage that doesn't meet the spec. R's, John ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
Re: [Ietf-dkim] Question about lone CR / LF
Unix MTAs strip out the CR in CRLF, often on the way in, so by the time opendkim sees the message, the line endings are just LF. That might be true when it's handing a message to an LDA, but it's not true for SMTP ingress filters. For milter, CRs are preserved in the body, so opendkim sees exactly what came in over the wire. https://pythonhosted.org/pymilter/milter_api/xxfi_body.html It's probably more of an issue on the way out. On my system all the DKIM and ARC signatures are applied before the message is handed to the MTA, and it's all \n line endings. 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] Question about lone CR / LF
But on review, it seems like I've tiptoed over that line from time to time in support of robustness in some form or another. ... It occurs to me that Dave and I have different views of how software is put together. His sounds like the waterfall model that was popular when he and I were undergraduates. You design the whole thing, you decide what modules do what, then you code the modules. So if module A is supposed to do something, there's no reason for module B to worry about it because A should already have handled it. My view is more pragmatic. People assemble programs from pieces and the pieces have bugs. So to the extent practical, you defend against things like bad input. It happens that bare CR and LF are really easy to check for in DKIM since as I noted before there's already a state machine that is looking at the current character and knows if the previous character was a CR. So it might as well recognize and reject that particular bit of bad input, particularly since whatever result it would otherwise produce isn't likely to be useful. Maybe this illustrates the difference between pure software engineering and applied software engineering? Yup. R's, John PS: It also optionally does LF to CRLF translation. I'm fairly certain this is to accommodate local/human SMTP injections since humans can't be expected to type CRLFs when entering manual tests from a shell. ... Unix MTAs strip out the CR in CRLF, often on the way in, so by the time opendkim sees the message, the line endings are just LF. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
On Sat, 3 Feb 2024, Dave Crocker wrote: Having a DKIM module check for one aspect of RFC5322 conformance raises a need to make it a full RFC5322 compliance engine. That's easy: no, it doesn't. Any DKIM signer or verifier already has a state machine looking for CR and LF to do header or body canonicalization. When the state machine runs into a bare CR or LF, it has to do something. The only options are to produce a wrong result, since there is no correct result, or no result. (As I said in a recent note to Murray, which wrong result is likely to vary depending on local file details.) You seem to be saying that as a matter of principle it should produce a wrong result. I'd rather not. 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] Question about lone CR / LF
I agree that by the time you're talking to a DKIM (or any) filter, I expect that this has been handled somehow. CRLF ends a line, anything before that is part of the line, and WSP is just a space or a tab. Past that, garbage in, garbage out. Yup, which is why I'd prefer to take out the garbage. As I'm sure you know, on Unix-ish systems the internal line separator is LF, so MTAs add the CR on the way out and remove it on the way in. DKIM routines operate on the internal form so they have code to add a CR before each LF when making hashes. So if a message shows up with bare LFs, those DKIM verifiers will treat it as though those were CR LF. But if a message came from some other system, say Windows, that uses CR LF internally, it won't have added the CRs and the hashes won't match. It seems to me that a signature that may or may not verify depending on internal warts of the verifier is worse than no signature at all. 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] Question about lone CR / LF
Layering is a fine principle, but it's not how DKIM has ever worked in practice. Two weeks ago we had a long discussion about oversigning, so DKIM validators can catch messages with multiple From: or Subject: headers which have never been valid in any version of 822/2822/5322 but show up anyway. Please explain how you think DKIM violates layering. What I said in my previous message, people use oversigning to catch 5322 header violations. For the specific issue of bare CR or LF, I was reminded on another list that there is a trendy attack called SMTP smuggling which depends on mail software inconsistently accepting bare CR or LF, and mail providers are busy patching to fix it. That has nothing to do with DKIM, of course. Opinions differ. 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] Question about lone CR / LF
On Thu, 1 Feb 2024, Dave Crocker wrote: Me, I would*not* put in code looking for bare CRs or LFs. ... A 5322 processor gets to decide what is a valid message. That's not DKIM's job. And DKIM has no inherent reason to care about CR or LF on their own, as distinct from any other character on its own. Layering is a fine principle, but it's not how DKIM has ever worked in practice. Two weeks ago we had a long discussion about oversigning, so DKIM validators can catch messages with multiple From: or Subject: headers which have never been valid in any version of 822/2822/5322 but show up anyway. For the specific issue of bare CR or LF, I was reminded on another list that there is a trendy attack called SMTP smuggling which depends on mail software inconsistently accepting bare CR or LF, and mail providers are busy patching to fix it. Read all about it here: https://smtpsmuggling.com/ I realize that there are plenty of ancient mail messages in archives with bare CR or LF, but none of them are going to be signed or verified now. You're not doing your users any favors by signing or verifiying a message-like thing that contains them. 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] Headers that should not be automatically oversigned in a DKIM signature?
Manfred said: (Seems like "seal"ing would be a better term than "oversign"ing.) We've called it oversigning for a decade now. R's, John ___ 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
