Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Mon, Aug 24, 2020 at 3:34 PM Douglas E. Foster  wrote:

> Something seems inconsistent:
>
> - The people who have implemented DMARC do not see any significant
> problems, and as a result they are not interested in a third-party
> authorization scheme.
>

I suspect you are conflating disinterest with being unconvinced that it is
workable, at least in any of the forms in which it's been presented.

I implemented DMARC and, unless you've been missing my commentary, I am far
from "do not see any significant problems".

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Something seems inconsistent:

- The people who have implemented DMARC do not see any significant problems, 
and as a result they are not interested in a third-party authorization scheme.

- Yet adoption is very slow, especially for anything other than p=none

Are we to assume that mailing list compatibility explains the slow adoption?   
If not, what other obstacles do we need to be considering?

DF


From: "Murray S. Kucherawy" 
Sent: 8/24/20 11:21 AM
To: Brandon Long 
Cc: IETF DMARC WG , Tim Draegen , Alessandro 
Vesely 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Thu, Aug 20, 2020 at 2:01 PM Brandon Long  wrote:
I tend to agree with the negative stance on third party auth, but SPF obviously 
has the include: statement which is third party auth at the most basic 
level...atps[1] is the obvious equivalent for DKIM.  I don't know if atps 
failed because it wasn't all that useful, or if it was tied in folks minds to 
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage across 
thousands of "relays" etc, and I don't think they should be used for that, but 
for a bunch of small to medium entities, it could be the thing that makes 
higher p= possible.

ATPS was designed as a proof of concept to see if third party policy was 
conceptually useful at all.  Scale could come later if the initial experiment 
had a positive result.  The industry, however, apparently didn't even have 
appetite to try, so we may never know.

-MSK


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Revisiting DMARC bis Ticket 66 - What It Means To Implement DMARC

[Todd Herr]

Thank you for the feedback, Ale; comments inline.

On Sat, Aug 22, 2020 at 5:06 AM Alessandro Vesely  wrote:

> On Fri 21/Aug/2020 21:25:50 +0200 Todd Herr wrote:
> [snip]
>
> >
> -
> > 8 Implementations
> >
> > The characteristics of a DMARC implementation will vary for the different
> > roles in the messaging infrastructure.
> > 8.1 Domain Owner Implementations
> >
> > Section 6.5  describes
> > many of the provisions for implementing the DMARC mechanism as a Domain
> > Owner. This section will clarify those needed for minimal and full
> > implementations.
>
>
> I'd start by introducing the distinction between domain owner and mail
> receiver.
>
>
The distinctions already exist in RFC 7489, the original DMARC spec:

https://tools.ietf.org/html/rfc7489#section-3


> A statement should then say what is the combined minimal/ full
> implementation.
>
>
> > 8.1.2 Full Domain Owner Implementation
> >
> > Full implementation of the DMARC mechanism by a Domain Owner requires all
> > of the following characteristics:
> >
> > -
> >
> > Creation of the DMARC policy record in DNS which meets these
> criteria:
> > -
> >
> >The policy record MUST express a Requested Mail Receiver policy of
> >“quarantine” or “reject” for the Organizational Domain and all
> sub-domains
> >-
> >
> >The Requested Mail Receiver policy MUST apply to a percentage of
> mail
> >not less than 100
> >-
>
>
> Nope.  A domain can say it has a *strict policy* when the above criteria
> are met.  Standing the principle that domains which host human users
> mailboxes must not publish a strict policy, mandating that these domains
> don't fully implement DMARC makes little sense.
>
> Note that I'm opposed to said principle, which is a limitation of DMARC.
> However, the limitation is there and we must first remove it.  Afterwards,
> perhaps, we can mandate strict policies.
>
>
I'm not clear on what you mean by "strict policy"; it's not a term I used
here.

Also worth noting is that I'm not trying to mandate anything, only
attempting to define two levels of implementation for each role - minimal
and full.


>
> > Establishment of an address to receive aggregate reports at least
> daily;
> > other than in exceptional circumstances such as resource exhaustion,
> the
> > address must support receiving reports up to at least ten megabytes
> in size.
> > -
> >
> > Deployment of authentication technologies to ensure Identifier
> Alignment
>
>
> Isn't it clearer to say "both SPF and DKIM"?
>
>
Perhaps, but I took pains here to re-use the same verbiage that's in
section 6.5 of RFC 7489:

https://tools.ietf.org/html/rfc7489#section-6.5


>
> > 8.2 Mail Receiver Implementations
> >
> > This section will describe minimal and full implementations of the DMARC
> > mechanism for Mail Receivers.
>
>
> > 8.2.1 Minimal Mail Receiver Implementation
> >
> > Minimal implementation of the DMARC mechanism by a Mail Receiver means
> > fully implementing the provisions of Section 6.6
> > 
>
>
> Maybe a minimal implementation could skip storing the results of DMARC
> processing.
>
>
Perhaps, but again I was re-using text from the original RFC -
https://tools.ietf.org/html/rfc7489#section-8


> > -
> >
> > Validation of any ARC header sets found in the message
>
>
> Nope.  DMARC has nothing to do with ARC.
>
>
Your statement is true, but I would submit that ARC has everything to do
with DMARC (and SPF, and DKIM) and attempting to mitigate the failures in
authentication that can be caused by mail transiting intermediaries.


>
> > -
> >
> > Enforcement of discovered policies in a manner that is consistent
> > with Section
> > 6.7 
>
>
> Hm...  that adds nothing to the requirements.  Section 6.7 allows
> receivers to do what they see fit.
>
>
Again, I'm not proposing to mandate any behavior here, only to define
different levels of implementation; further, I don't sense much in the way
of consensus from the group on trying to mandate behavior.


>
> > -
> >
> > Send aggregate reports at least daily using “mailto” URIs; such
> > aggregate reports MUST be no larger than ten megabytes in size.
>
>
> I'd just mandate reporting.  Size is a different issue.
>
>
The ten megabytes limit is original text from section 8 -
https://tools.ietf.org/html/rfc7489#section-8 -  It seems antiquated to use
such a small size today, but I was trying not to stray too far afield of
the original text.

Limiting the size makes more sense for each mailto: address, as it should
> reflect message size limits that the corresponding MTA enforces.  See also
> ticket #53.
>
> Some domains react to the size limit by sending multiple records fo

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John Levine]

In article  
you write:
>> message. If the intermediary DKIM signs the modified message with their own
>> signature, that provides some assurance to the receiver.
>
>You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
>
>I'm pretty sure that got implemented too, but I can't recall now if it ever 
>shipped.

I don't think it ever did.  It has the scaling problem of every system that 
sends to mailing lists
having to decide what mail it's willing to have re-signed and what domain the 
second signature
will use.  Usually it's the domain name of the list except when it's not.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Thu, Aug 20, 2020 at 2:01 PM Brandon Long  wrote:

> I tend to agree with the negative stance on third party auth, but SPF
> obviously has the include: statement which is third party auth at the most
> basic level...
> atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed
> because it wasn't all that useful, or if it was tied in folks minds to
> adps, or the failure of the follow-on reputation system stuff..
>
> Neither atps or spf include are really designed for large scale usage
> across thousands of "relays" etc, and I don't think they should be used for
> that, but for a bunch of small to medium entities, it could be the thing
> that makes higher p= possible.
>

ATPS was designed as a proof of concept to see if third party policy was
conceptually useful at all.  Scale could come later if the initial
experiment had a positive result.  The industry, however, apparently didn't
even have appetite to try, so we may never know.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Thu, Aug 20, 2020 at 4:56 PM Dotzero  wrote:

> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.


You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?

I'm pretty sure that got implemented too, but I can't recall now if it ever
shipped.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc