Re: DMARC and ietf.org

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]