Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis

[Hector Santos <[e-mail]>]

> On Apr 23, 2023, at 4:17 PM, Dotzero <[e-mail]> wrote:
> 
> On Sun, Apr 23, 2023 at 1:20 PM Hector Santos <hsantos=[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> With each year, that "temporary hack" becomes the new normal and it 
>> will be harder to clean up. It is not the right way and I don't  its 
>> too late to reverse.  However, it has been 17 years and DMARCbis is 
>> not finished without some clean up in this area.
> 
> It HAS NOT been 17 years for either DMARC (first published in 2011  and first submitted to IETF as informational in 2015) or DMARCbis. Let's at least use publicly available data points for time frames rather than time frames pulled out of thin air.

Wow.  I’ll apologize for the confusion. Allow me to paraphrase it:

“However, it has been 17 years since the evolution of SSP, DSAP, ADSP, ATPS and now DMARCbis and unfortunately it is not finished without some clean up in this area.”

A little better, I hope.

I see all of the as a DKIM Policy Model and DMARC just happens to be current rendition of the concept.  I have worked with all of them and before that, we did a real security analysis and requirements work.  Not sure if you participated in this early DKIM wg work.

>> 
>> I can understand why DMARCbis's editor does not want to document  
>> rewrite, but imto, can't be ignored anymore.   The details of a 
>> rewrite can be quickly outlined.  To help the RFC process, maybe 
>> DMARCbis could refer to the Functional Specifications of SSP (RFC5016) 
>> Section 5.3, Item 10 which basically reinforces the idea that local 
>> policy ALWAYS prevails and it is quite possible there will be 
>> undesirable tearing down of secured submissions.  One possible 
>> mitigation is to replaced it with a secured rewriter with a p=reject 
>> policy.
> 
> SSP is long gone and failed. Referencing something which failed to gain support many years ago is also not a path to go down. 


I referenced the Functional Specification for SSP (RFC5016), not the SSP itself which was still only in draft form.  https://datatracker.ietf.org/doc/html/draft-allman-dkim-ssp-02

The development and point of RFC4866 and RFC5016 was to help Eric and Jim create SSP and thats when Levine’s ADSP stepped in.  From a software engineering standpoint, the documents provided the security analysis and requirements to make a "SSP” protocol.  It does not change the original analysis or requirements. 

Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
https://datatracker.ietf.org/doc/html/rfc4686

Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
https://datatracker.ietf.org/doc/html/rfc5016

Please review these, especially Section 5.3 of RFC5016.  I was sort of helping DMARCbis.  It can refer that provision to maybe justify the rewrite.  After all, it was a game changer in all this when it was added.

—
HLS