Re: DMARC and ietf.org

[Hector Santos <[e-mail]>]

On 7/21/2014 4:40 PM, MH Michael Hammer (5304) wrote:
>
>> Mike,
>>
>> There is no "pretending" here. We actually IMPLEMENTED and DEPLOYED the
>> consensus built MAILING LIST recommendations and it works.
>>
>
> The fact that you implemented and deployed does not mean that there is a general consensus in the IETF sense.
>

In the IETF sense, there was many IETF consensus built document. Thats 
exactly my point. You are referring to adoption. The claim was there 
was no "consensus at all" in dealing with the problem is not true. 
Guidelines were produced. The reasons for not lacking multiple vendor 
support is a different issue best to lay rest as long as the IETF 
mistakes are recognized and finally finish this "job."

>> So I disagree 100% with the erroneous suggestion there has been "no
>> consensus at all."  To suggest there is no guidelines whatsoever has been the
>> real disservice being promoted.  Its not true.
>>
>
> Guidleines != consensus.

Consensus does not necessarily translate to support and adoption. Agree.
But consensus does leads to production of (RFC, STD) guidelines in the 
IETF.

> The devil is always in the details. ADSP!=DMARC.

Of course, but the entire policy framework with I-D and RFCs (SSP, 
DSAP, ADSP, ASL, ATPS, TPA, DMARC) from an software engineering 
standpoint are all sender/author domain signing policy protocols. 
They all fall in the same plug and play "black box" principle for the 
verifier "Checking Signing Practices" (CSP) module. This was all 
outlined and extracted from the IETF consensus-built documents:

    RFC4686  Analysis of Threats Motivating DKIM
    RFC5016  Requirements for a DKIM Signing Practices Protocol
    RFC5585  DKIM Service Overview

In particular,  see the RFC5685 architectural illustration with the 
CSP module in the middle of all this. See the RFC4686 illustration 
with the SSP and SIGNER EVALUATION modules.

My main point, love them or not, these and other DKIM-related 
documents were all consensus IETF built RFC guidelines for an 
integrated mail framework and list servers are part of the framework.

There were many integrated areas that were not consistent.  What 
created the core conflict we have today was predicted with the last 
minute provision added in RFC5016 section 5.3 item 10:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

IMO, it disallowed us from finishing the job. Its hard to do software 
with this logic. I believe the intent was this:

    if two or more signatures exist and one is a 3rd party, ignore the
    1st party.

It allowed the list operation to disregard all new security protection 
mechanisms and passed the buck to the receivers when all they have to 
do is three basic things:

    1) Deny Restrictive Domains from Subscribing
    2) Deny Restrictive Domains from List Submission
    3) Pottery Principle "You break it, you own it" - Resign mail

I agree, there was limited adoption.


-- 
HLS