On 4/21/2014 2:54 PM, Vlatko Salaj wrote:
On Sunday, April 20, 2014 9:00 PM, Hector Santos wrote:
This would be a simple first step consideration -- A new ATPS tag
this may fix DKIM 3rd party support, but does little to support
3rd party SPF. i think it's important to have a fix for all
underlying mechanisms, not just some of them.
How do you define a 3rd party SPF condition that isn't already defined
and authorized by the 1st party? IOW, by virtue of the 1st party
adding the 3rd party information into a SPF record, it is inherently
ready for 3rd party operations. No? This would be different that the
DKIM + Author Domain Policy security model.
The problem with all the author domain policy protocols is that anyone
can SIGN. The original SSP (Sender Signer Practices) had 3rd party
semantic and controls. ADSP pruned and reduced SSP to 1st party
semantics. The pruning left holes and ADSP was left unsolved. DMARC
followed up with its own more explicit 1st party only semantics.
The main difference SSP, ADSP and DMARC is that finally someone has
taken the rejection handling semantics seriously and began to apply
it. That also means that any domain with ADSP dkim=discardable can
expect to see rejection/discard to be finally enabled. See PAYPAL.COM
ADSP and DMARC records.
Also, consider that DMARC "may" have violated RFC5016 "Requirements
for DKIM Signing Practices Protocol" section 5.3, provision #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.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
If DMARC is about conforming to DKIM operations, then it SHOULD of
provided the option for 3rd party signers to exist. DKIM is about 3rd
party TRUST support. Even the policy advocated accepted that model,
but we also felt POLICY was a fundamental part too.
considering DMARC may include additional underlying mechanism in
the future, a fix for 3rd party needs to be DMARC-based, not
based on whatever underlying mechanisms are included in DMARC
instead, imo. if we start fixing underlying mechanisms just to
have them DMARC-imposed alignment requirement compatible,
we are introducing new griefs to be dealt with in the future,
and adding bunch of incompatibilities with legacy support for
those protocols. so, whoever supports DMARC will have to add
support for all those new extensions and additional protocols
which may be more than what they are willing to do, opting for
just ignoring DMARC completely.
I am not sure what that all means, but DMARC is notT conforming to the
DKIM specification that by design allows for 3rd party operations. So
whatever the above means, DMARC does need to be fixed or not endorsed
by the IETF. DKIM is a STD level specification now. DMARC must FIT
with DKIM, not the other way around.
also, such path simply creates more resource usage, especially on
DNS, cause all those extensions have their DNS checks, and
sometimes more than one. also, more protocols, more libraries
running on server, fighting for resources...
Yes, ATPS does add more DNS records, but that seems to be an more
acceptable in application design today, i.e. just like XML. High
overhead processing which today machines and communication speeds can
handle making it feasible to consider.
why should we go that line, when it's easier to build a DMARC-based
support for 3rd party and fix the problem at the source?
Agree, but if there is going to be resistance by the "gate keepers" of
the specification and they won't do the "right thing" then the IETF
needs to make the corrections, and the best current way to do this is
with extensions which DMARC section 3.1.4.3 allows. I agree, it
should be part of the base spec.
atps=0� default, extension disabled allowed backward compatibility.
atps=1� Valid alignment allows a valid 3rd party signature (no checks).
this is similar to specifying adkim=n, the way Tomki Camp already
suggested, which i like better instead, since it's DMARC-based.
If adkim=n(one) was proposed then that would do the trick to satisfy
this particular "MUST BE SIGNED, BY ANYONE" practice, it would match:
SSP o=- signature required, 3rd party allowed policy
ADSP dkim=all signature required, 3rd party allowed policy?
The problem was ADSP proposed standard was that it was unclear whether
dkim=all also allowed 3rd party signatures.
You should review the 9+ years of R&D done with DKIM + POLICY layer,
starting with SSP and ADSP to see how DMARC evolved and what fell thru
the cracks with it. My thinking was that DMARC was never really
meant to be a policy handling protocol but a reporting protocol.
atps=2� Valid alignment allows a valid 3rd party signature with ATPS
(Authorized 3rd Party Signer) checking, RFC6541.
a receiver wishing to support ATPS can account for it during processing
DMARC, without any change in DMARC itself.
however, i'm quite sure everybody would be much more happy with a
single working protocol, instead of bunch of extensions.
Sure, but you also have to be prepared for extensions too.
atps=3� Valid alignment allows a valid 3rd party signature using
the May-Resign header method.
which is what exactly? i guess something similar to adkim=s:yahoo.com,
which i proposed already, but if u would like to continue lobbying for
this idea, please elaborate and provide examples.
Mr. Resnick can provide more details, but in general, the point was to
show flexibility with a new tag that allows for additional alignment
processing.
in any case, i would like to see what benefits these solutions have
over other suggested proposals, like those suggested by
Joseph Humphreys, Tomski Camp and me, all of which tend to fix
DMARC, and not introduce requirements for additional extensions to
underlying protocols.
Again, there is 9+ years of R&D. Overall, the #1 issue was not that
it wasn't a good idea, but how to SCALE it and how do manage it. It
adds complexity. But the #1 resistance was the mailing list folks who
didn't want to have any restrictions on (re)signing mail. See above
about section 5.3, item 10 in RFC5016.
But there was proof of concepts and operations did already yse ADSP
plus ATPS. There is an even a ADSP + ATPS wizard zone creator and
simulator at:
http://www.winserver.com/public/wcadsp
DMARC was created as a solution for a problem a bunch of other
extensions tried covering before already. all about failing.
There is only one difference -- rejection was finally switched on.
ADSP did have support too by many of the high value domains. But I
don't think we were quite ready to do the rejection/discarding
enforcement. We were just processing and logging the results to
hopefully gather data with the AUTH-RES header. Reporting was always
suggested but it was also viewed as something to limit potential abuse
and it was never formalized. That is what DMARC did and what YAHOO did
was finally turned on the rejection switch. Thats really the main and
only true event shocker here, IMO. Not DMARC as a "language" itself
because we did have SSP and ADSP but we had too many IETF opponents
against POLICY regarding middle ware issues -- hence this issue with
YAHOO now. DMARC was produced outside the IETF as it was envisioned
to be the only way to get something moving. Unfortunately, they
really didn't do a good job in satisfying all the possible boundary
conditions of the DKIM+POLICY+TRUST model. In other words, they
didn't really learn, did they? DMARC is very limited and that is what
the IETF has to address.
we could skip that broken-path with DMARC today, since it's still in
development, and simply add 3rd party support to its base. i see
no issue with the idea of authorised alignment. it's natural to the
way email works. with some thinking, i'm sure we can make it work
for mailing lists too.
Agree.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
