Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Sun, Feb 19, 2023 at 11:49 AM Dave Crocker wrote: > This is a very basic point about protocols vs. implementations. A > protocol defines the 4 walls of its sandbox. It owns that sandbox and > defines whatever it needs to, within the confines of that space. > > [...] > > But again, this is protocol and standards 101. Seems odd to be > rehashing something this basic, in a forum like this > I didn't see this as a rehashing, just a clarification of the nomenclature being used. Reviewing the last few posts in this thread have me thinking we're all otherwise agreeing. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
The RFC just talks about returning PERFMAIL when the evaluation fails for one reason or another. It's abstract, of course; the implementer is free to decide what that actually means in each case. In the implementation I did, the library receives all the details and returns a status (with its own detail) about each signature, and the caller is free to do what it wants with that information. This is a very basic point about protocols vs. implementations. A protocol defines the 4 walls of its sandbox. It owns that sandbox and defines whatever it needs to, within the confines of that space. To be reliable and accurate, it has to be objective and precise. Specific inputs, specific outputs. It might distinguish permanent failures, such as a cryptographic value not validating -- the passage of time is not going to change that; versus a temporary failure, such as a failure to get a DNS response; the passage of time might change that. The liberal-vs-strict cliche applies to the interpretation of protocol specification details that might legitimately permit alternative interpretations, because prose can be ambiguous, in spite of efforts for it not to be. But a protocol spec is not supposed to call on subjective judgement -- ie, whim. An implementation of the protocol, also has no freedom, in terms of strict conformance. However a real-world implementation, in which the protocol implementation is incorporated as a part, will tend to demonstrate all sorts of programmer and organization whim in deciding what to /do/ with the available information. DKIM is precise. A filtering engine that uses it well might not be. Heuristics don't belong in a protocol spec but usually /do/ belong in a filtering engine. But again, this is protocol and standards 101. Seems odd to be rehashing something this basic, in a forum like this 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] DKIM Replay Problem Statement and Scenarios -01 draft posted
On 2/18/23 8:41 PM, Murray S. Kucherawy wrote: On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas wrote: Beyond this SHOULD, I think we need to consider whether the caller needs to be told specifically when a failure occurs for this reason. Right now an implementation might return just a PERMFAIL without noting that it's because of "x=" versus the signature failing for some other reason. Should the caller be given this extra detail to enhance the decision tree, or will this just complicate things? Why would it permfail? Does it permfail email without a signature too? Absent p=reject, there is nothing wrong with unsigned email. I'm using the language of the DKIM RFC, so "PERMFAIL" here refers to evaluation of the signature, not of the message. But DKIM doesn't return status to anybody. That's completely internal to the verifier. At most they might want to create an A-R, but that isn't required and it's definitely not sent back to the sender. I think we're talking about different layers here. Otherwise, DKIM has to return status someplace, otherwise why do the evaluation? That status might be in the form of an A-R header field, or a recommended final action, or a log entry, or whatever that operator wants. The RFC just talks about returning PERFMAIL when the evaluation fails for one reason or another. It's abstract, of course; the implementer is free to decide what that actually means in each case. In the implementation I did, the library receives all the details and returns a status (with its own detail) about each signature, and the caller is free to do what it wants with that information. From the standards standpoint a signature either verifies or not (modulo DNS glitches), but from a verifier's standpoint signatures and the covered parts of the message contains a wealth of other information that a filter module could use as inputs to make its decisions. That may or may not be distilled into a single status, but that is completely up to the receiver so PERMFAIL is just conceptual, not real. x= in particular is rather vague about what a receiver should make of an expired signature, and completely silent on what a low value might imply. I've always thought of it as "I don't take responsibility for this anymore" from the sender's standpoint, but others are free to have a different opinion and that's fine (in particular, the HER EMAILS crowd certainly wouldn't care). Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
