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