Re: [Ietf-dkim] Question about lone CR / LF
On Thu, Feb 1, 2024 at 10:03 AM John Levine wrote: > It appears that Murray S. Kucherawy said: > >-=-=-=-=-=- > > > >On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso > wrote: > > > >> But i cannot read this from RFC 6376. > > > >Sections 2.8 and 3.4.4 don't answer this? > > Not really. They say what to do with CRLF but not with a lone CR or lone > LF. > Ah, I misunderstood the question. 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. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
It appears that Dave Crocker said: >The prohibition is not in DKIM. So the violation is not within DKIM. >And why should DKIM care? RFC 6376 says what to do with 5322 messages. It says nothing about what to do with blobs of bytes that are sort of like but not quite 5322 messages. It even has a few places that remind us of that, e.g., in section 5.3 it reminds us that if the local file convention uses just CR or LF, change them to CRLF before doing anything else. I can see that you have strong opinions about what a DKIM verifier should do with those non-5322 blobs, but I don't see what the basis for that is, and for that matter, I don't really understand what you expect code to do with them. Why is "stop and report failure" any less valid than anything else? R's, John ___ 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 2/1/2024 7:31 PM, John R Levine wrote: 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. Except that that isn't a layer violation, as I noted. It is a behavior within DKIM that only affects DKIM. 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. The prohibition is not in DKIM. So the violation is not within DKIM. And why should DKIM care? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] 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 2/1/2024 7:05 PM, John R Levine wrote: 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. It scans the message; it adds a header field, but it otherwise does not modify the message. Oversigning affects DKIM processing, itself, but still does not affect the message itself. So I don't understand the claim that DKIM does not respect layering. 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. So there might well need to be a separate discussion of these concerns, on emailcore, or the like, but not DKIM. One hopes that discussion distinguishes between protocol architecture and details, versus possible implementation problems. (This is where I cite the workshop some Stanford profs had about problems with TCP and it turned out it wasn't about the protocol but about an implementation -- a distinction they seemed not to have made. Since the audience included Larry Roberts and Barry Leiner, I turned out to offer the softest criticisms...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] 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] Question about lone CR / LF
John Levine wrote in <20240201180340.852b68205...@ary.qy>: |It appears that Murray S. Kucherawy said: |>-=-=-=-=-=- |> |>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso \ |>wrote: |> |>> But i cannot read this from RFC 6376. |> |>Sections 2.8 and 3.4.4 don't answer this? | |Not really. They say what to do with CRLF but not with a lone CR or \ |lone LF. | |RFC5322 says: | | o CR and LF MUST only occur together as CRLF; they MUST NOT appear | independently in the body. | |So I think the answer is that a thing with a lone CR or LF is not a |valid message so signers shouldn't sign them and validators shouldn't |validate them. If you want to allow them, OK, but no promises that |anyone at the other end will treat the brokenness the same way you |dod. Thanks for the answer. That MUST NOT i had completely forgotten. But hanging in some milter i decided to simply treat them as ordinary bytes. I mean, i could enforce message "rejection", even more so later when this thing also verifies, but i would think the MTA administrator would not like this very much -- she or he shall configure the MTA, and i work what i get. This is also why the 8/28/5322 IMF parser simply digs CFWS, plus LF, plus CR etc, almost everywhere. In practice the user wants to see outcome. Some years ago people embedded garbage in emails with base64 encoding, and my parser simply complained on invalid input and refused to show the content. That was no good. The mutt MUA, for example, simply digged it (mostly). So i am now super liberal and simply ignore any non-base64 garbage. But maybe i will add a configuration option when the DKIM thing has matured, especially later with the verifier. |We can get into some theological arguments about BINARYMIME which |allows arbitrary bytes in a MIME part but I expect that DKIM |canonicalization code will choke on other stuff in binary MIME before |it gets to a \x0a or \x0d. It is amazing and frustrating and what not that i send a message with UNIX line endings that ends in a UNIX line endings MBOX, but for the milter postfix creates a complete CRLF terminated message. I (i do not use libmilter) would feel safer if i would simply get NUL terminated strings, or packets with length/data tuples. But so is the protocol. Well. Thank you. --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] Question about lone CR / LF
On 2/1/2024 12:28 PM, Jon Callas wrote: So that gets to the tacit question -- what should a DKIM implementor do? Me, I would*not* put in code looking for bare CRs or LFs. My major rationale is an appeal to layering, or bluntly, it's not my job to enforce RFC 5322 syntax. Someone else in the pipeline is supposed to do that, and all I can do is screw things up. This. 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
On Feb 1, 2024, at 10:03, John Levine wrote: It appears that Murray S. Kucherawy said: -=-=-=-=-=- On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote: But i cannot read this from RFC 6376. Sections 2.8 and 3.4.4 don't answer this? Not really. They say what to do with CRLF but not with a lone CR or lone LF. RFC5322 says: o CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. So I think the answer is that a thing with a lone CR or LF is not a valid message so signers shouldn't sign them and validators shouldn't validate them. If you want to allow them, OK, but no promises that anyone at the other end will treat the brokenness the same way you dod. We can get into some theological arguments about BINARYMIME which allows arbitrary bytes in a MIME part but I expect that DKIM canonicalization code will choke on other stuff in binary MIME before it gets to a \x0a or \x0d. I went down the rabbit hole of RFC5322 syntax around CR and LF, and yes, it seems to me that 5322 is definitely saying no bare CR or LF. However. Section 4.0 and 4.1 (in detail) describe obsolete syntax and bare CR and LF is in there with the interesting comment in 4.1: Bare CR and bare LF appear in messages with two different meanings. In many cases, bare CR or bare LF are used improperly instead of CRLF to indicate line separators. In other cases, bare CR and bare LF are used simply as US-ASCII control characters with their traditional ASCII meanings. Which means that yes, it's forbidden, but it's also obsolete, and there's this note about how someone might want to use (e.g.) an LF for some quote-quote traditional ASCII meaning, like a real line feed that I emulated here with a CRLF and a bunch of spaces. (I am thoroughly amused at how constructing this weird paragraph is making my MUA hyperventilate. I'm even wondering if the droll humor even goes through.) So that gets to the tacit question -- what should a DKIM implementor do? Me, I would *not* put in code looking for bare CRs or LFs. My major rationale is an appeal to layering, or bluntly, it's not my job to enforce RFC 5322 syntax. Someone else in the pipeline is supposed to do that, and all I can do is screw things up. 5322§4.1 doesn't just talk about CR and LF. It also talks about how NUL is also an obsolete character. §4.2 is all about obsolete folding whitespace. §4.3 is about obsolete time zones, and there's a whole lot more in there of obsolete things. If I'm going to parse for CR, shouldn't I also be parsing for someone saying GMT when they meant UTC? Shouldn't I be checking line lengths, too? And we haven't even gotten to other things like your observation about BINARYMIME. If I look at it from a failure-mode analysis, if I generate a false positive on 5322 parsing, or even am totally annoyingly correct -- nuh, uh, I'm not going to sign that message because you said GMT -- it's going to piss people off and I'll look at best like a clenchpoop and at worst like a fool. On the other hand if I sign something that was not 5322-compliant and the signature breaks then well, perhaps the MUA should canonicalize it, or the MSA should reject it. I think it's totally reasonable for a DKIM implementation to just declare that the thing it's given is 5322-compliant, and if it is, it's not DKIM's problem. So I'd assume 5322ness in DKIM, because there are many dragons in the alternative. Jon ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote: > >> But i cannot read this from RFC 6376. > >Sections 2.8 and 3.4.4 don't answer this? Not really. They say what to do with CRLF but not with a lone CR or lone LF. RFC5322 says: o CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. So I think the answer is that a thing with a lone CR or LF is not a valid message so signers shouldn't sign them and validators shouldn't validate them. If you want to allow them, OK, but no promises that anyone at the other end will treat the brokenness the same way you dod. We can get into some theological arguments about BINARYMIME which allows arbitrary bytes in a MIME part but I expect that DKIM canonicalization code will choke on other stuff in binary MIME before it gets to a \x0a or \x0d. R's, John ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Question about lone CR / LF
Murray S. Kucherawy wrote in : |On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso \ |wrote: | |> But i cannot read this from RFC 6376. |> | |Sections 2.8 and 3.4.4 don't answer this? These were why i was coming here. It is one thing to write a 5322/I-M-F parser who documents RFC 5234, B.1. Core Rules "WSP", but simply skips over anything whitespace related, effectively, but the other to digest a lone LF or CR in the data stream. So the answer is this they are not. Thank you very much for this confirmation, i was very unsure. --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] Question about lone CR / LF
On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote: > But i cannot read this from RFC 6376. > Sections 2.8 and 3.4.4 don't answer this? -MSK ___ 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?
On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote: If I add this feature to wcDKIM, it can be introduced as: [X] Enable DKIM Replay Protection That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while there can be other effects on signature robustness. A better sentence could be: [X] Prevent further additions of this field Note that some packages allow choices such as [ ] Sign and oversign only if present in the message [ ] Oversign only if already present in the h= list [ ] Oversign anyway Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
