Re: [Ietf-dkim] Question about lone CR / LF

[Dave Crocker <[e-mail]>]

On 2/3/2024 10:32 AM, John R Levine wrote:
> 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.


The state machine has to process /every/ character.  You are focusing on 
two that have special DKIM meaning, when occurring together, but that's 
too narrow.  In practical terms, the state engine is evaluating every 
character.

In focusing down so narrowly, you've missed the basic point I made:  
DKIM has no inherent reason to care about these characters' occurring in 
isolation.  DKIM is not a message validation engine. It is a 
DKIM-specific engine.  One more time:  DKIM has no requirement of its 
own that cares about a bare CR or bare LF.

If you think otherwise, please explain, in terms of DKIM syntax and 
semantics, independent of a general message format specification.

And the point I made was not that it was difficult to add code to raise 
an exception when one of them occurs on its own, but that DKIM is the 
wrong place to put the exception. And that makes it likely there will be 
a maintenance problem down the line.

Imagine, if you will, that the email format standard changes to make CR 
and LF acceptable to occur, each on their own.  This is not all the 
impossible, given that they were entirely legal in RFC 733 and RFC822.

In fact, upon reviewing the different versions, I see that they are 
/still /legal in RFC 2822 and RFC 5322 and RFC5322bis parsing, with some 
text implying why there was  a change from being fully legal.

/<rant> While I understand the explanation, I don't agree with the 
change, since I think it deals with local misbehaviors by changing 
global standards behaviors. More likely, the better way to think of it 
is that the global details have not been specified precisely enough.  So 
I think the fix is to define the semantics of each character globally 
and require local engines to match it, as they already have to do for 
newline. </rant>/

Hmmm... So it seems that the claim that they are illegal is not correct!

But let's continue the hypothetical that they are illegal. If/when they 
become legal, there has to be memory that DKIM treats them as illegal.

DKIM is not a general message parsing engine, so it entirely possible 
(likely) that the maintainer of DKIM code will not know to make the change.

Since DKIM does not need to care about bare occurrences of these 
characters, things are kept simpler and frankly easier to maintain, by 
having bare occurrences pass through as other characters do.  The fact 
that the appearance of a bare CR will raise a flag (or change a state) 
in case the next character is an LF is a distraction to the current 
issue.  It does not require failing the DKIM-specific parse, because in 
terms of what /DKIM /itself needs to care about, a bare CR and a bare LF 
are just characters like any other.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[e-mail]