Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Thursday, February 27, 2020 12:30:59 AM EST Murray S. Kucherawy wrote:
> On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz  wrote:
> > First, while I know you've said the needs of external actors won't weigh
> > on your decision about moving forward, I would like to mention that
> > having a stable reference for PSD DMARC will help us with working towards
> > policy changes that would allow us to participate in this experiment.  It
> > may not be important to the WG Chairs' decision on the draft, but there
> > are stakeholders for whom it is important.
> 
> Just to be clear, I don't mean to suggest the restriction you're referring
> to is invalid.  I'm sympathetic to the idea that some potential
> participants in PSD are constrained by policies outside of their control or
> ours.  But I look at it this way: A series of "X can't happen until Y
> happens" assertions have been made over the last while, and the series is
> roughly circular.  I don't mean to be insensitive to the pain of you or
> others under external constraints, yet at the same time, from the
> perspective of the IETF, those constraints are very much external and thus
> are easier to disqualify as we try (sometimes desperately) to find a way
> out of this deadlock we're in.
> 
> I will also be somewhat ashamed to hand Alexey a deadlocked working group
> in March.  :-)
> 
> With my chair hat on, I'm leaning toward making the following consensus
> evaluation: With a completed (and now seven month old) Working Group Last
> Call on the PSD document, and as far as I can see no sustained objection,
> we should proceed toward publication.  Unless someone wants to argue that
> this is not the WG's consensus, we'll proceed at the end of next week.
> 
> To be specific:
> 
> Dave raised a post-WGLC concern that DMARC and its use of the PSL really
> ought to be teased apart.  I have heard no objection to that, and in fact
> have seen some support for it, so I consider that also to have consensus.
> The part that does not appear to have consensus is that it is mandatory for
> this to be done before the PSD work can proceed.
> 
> Dave also suggested that Experimental status is not procedurally
> appropriate for this work, and stated some reasons.  There appear to be no
> others lending support for this assertion either.  However, while I
> disagree, and I believe I gave an existence proof to the contrary, I will
> put this question to the working group: Can we solve this problem by
> switching the document to Informational status, and can the working group
> accept that outcome?  That seems an easy compromise, and I saw it proposed
> but not fully discussed yet.  This seems quite reasonable as well when one
> considers that PSD's proponents could very likely get the thing published
> as an RFC via the Independent Stream if they continue to find no progress
> here.  So, please discuss this option on the list and I'll measure
> consensus on it at the end of next week as well when next steps are chosen.
> 
> Mike objected to PSD generally, also long after WGLC completed.  This too
> does not appear to have swayed consensus.  (And he's been cogitating on
> that thread for a few weeks now...)
> 
> As a reminder, we still need to do AD evaluation, an IETF-wide last call,
> directorate reviews, and IESG evaluation before it lands in the RFC
> editor's queue.

As editor, I'm happy to update the draft to match whatever the chairs find as 
consensus.

Personally, I think informational is fine.  I'll wait for direction from the 
chairs before doing anything.

Scott K

Scott K



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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Tim Wicinski]

Informational works for me if that helps moves things forward.

I also agree with Mr. Crocker's thesis on teasing about the PSL from DMARC,
but that should not hinder forward progress on PSD.

tim




On Thu, Feb 27, 2020 at 4:50 PM Kurt Andersen (b)  wrote:

> On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely  wrote:
>
>> On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote:
>> >
>> > With a completed (and now seven month old) Working Group Last Call on
>> the
>> > PSD document, and as far as I can see no sustained objection, we should
>> > proceed toward publication.
>>
>> Great!
>>
>
> +1
>
> > I will put this question to the working group: Can we solve this problem
>> by
>> > switching the document to Informational status, and can the working
>> group
>> > accept that outcome?
>>
>> If publishing as experimental would further delay publication, I'd accept
>> informational.
>>
>
> Also agree.
>
> --Kurt
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Thu, Feb 27, 2020 at 4:16 AM Alessandro Vesely  wrote:

> On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote:
> >
> > With a completed (and now seven month old) Working Group Last Call on the
> > PSD document, and as far as I can see no sustained objection, we should
> > proceed toward publication.
>
> Great!
>

+1

> I will put this question to the working group: Can we solve this problem
> by
> > switching the document to Informational status, and can the working group
> > accept that outcome?
>
> If publishing as experimental would further delay publication, I'd accept
> informational.
>

Also agree.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Thu 27/Feb/2020 06:30:59 +0100 Murray S. Kucherawy wrote:
> 
> With a completed (and now seven month old) Working Group Last Call on the
> PSD document, and as far as I can see no sustained objection, we should 
> proceed toward publication.

Great!


> I will put this question to the working group: Can we solve this problem by
> switching the document to Informational status, and can the working group
> accept that outcome?

IMHO, experimental is appropriate.  There are three competing methods; maybe it
will be worth to maintain all of them indefinitely, maybe some of them will
turn out to be impractical or not used.  That's the experimental question.  The
sooner we run it the sooner the response.

If publishing as experimental would further delay publication, I'd accept
informational.  However, I don't understand why.


jm2c
Ale
-- 



































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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Wed, Feb 5, 2020 at 3:02 AM Craig Schwartz  wrote:

> First, while I know you've said the needs of external actors won't weigh
> on your decision about moving forward, I would like to mention that
> having a stable reference for PSD DMARC will help us with working towards
> policy changes that would allow us to participate in this experiment.  It
> may not be important to the WG Chairs' decision on the draft, but there
> are stakeholders for whom it is important.
>

Just to be clear, I don't mean to suggest the restriction you're referring
to is invalid.  I'm sympathetic to the idea that some potential
participants in PSD are constrained by policies outside of their control or
ours.  But I look at it this way: A series of "X can't happen until Y
happens" assertions have been made over the last while, and the series is
roughly circular.  I don't mean to be insensitive to the pain of you or
others under external constraints, yet at the same time, from the
perspective of the IETF, those constraints are very much external and thus
are easier to disqualify as we try (sometimes desperately) to find a way
out of this deadlock we're in.

I will also be somewhat ashamed to hand Alexey a deadlocked working group
in March.  :-)

With my chair hat on, I'm leaning toward making the following consensus
evaluation: With a completed (and now seven month old) Working Group Last
Call on the PSD document, and as far as I can see no sustained objection,
we should proceed toward publication.  Unless someone wants to argue that
this is not the WG's consensus, we'll proceed at the end of next week.

To be specific:

Dave raised a post-WGLC concern that DMARC and its use of the PSL really
ought to be teased apart.  I have heard no objection to that, and in fact
have seen some support for it, so I consider that also to have consensus.
The part that does not appear to have consensus is that it is mandatory for
this to be done before the PSD work can proceed.

Dave also suggested that Experimental status is not procedurally
appropriate for this work, and stated some reasons.  There appear to be no
others lending support for this assertion either.  However, while I
disagree, and I believe I gave an existence proof to the contrary, I will
put this question to the working group: Can we solve this problem by
switching the document to Informational status, and can the working group
accept that outcome?  That seems an easy compromise, and I saw it proposed
but not fully discussed yet.  This seems quite reasonable as well when one
considers that PSD's proponents could very likely get the thing published
as an RFC via the Independent Stream if they continue to find no progress
here.  So, please discuss this option on the list and I'll measure
consensus on it at the end of next week as well when next steps are chosen.

Mike objected to PSD generally, also long after WGLC completed.  This too
does not appear to have swayed consensus.  (And he's been cogitating on
that thread for a few weeks now...)

As a reminder, we still need to do AD evaluation, an IETF-wide last call,
directorate reviews, and IESG evaluation before it lands in the RFC
editor's queue.

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

[dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Paul Abramson]

List members,

I have been working with fTLD on the advisory council for a few years now, an 
adopter of both a .BANK domain and DMARC reject policy since 2015.  I support 
the work related to DMARC PSD.  It helps close an important security gap 
allowing the abuse of unregistered domains in the trusted TLD space.

Thanks for your consideration.


Paul Abramson
EVP, Chief Technology Officer

AmericanRivieraBank.com | PH 805.730.4997 | FX 805.965.8523
1033 Anacapa St | Santa Barbara Ca 93101

[cid:image002.jpg@01D3EB59.D24329B0]  
[cid:image004.png@01D50B1A.D5CE25D0]






CONFIDENTIALITY?NOTICE:?This?communication,?including?attachments,?is?for?the?exclusive?use?of?the?person?or?entity?to?which?it?is?addressed?and?may?contain?confidential,?proprietary?and/or?privileged?information.?Any?review,?retransmission,?dissemination?or?other?use?of,?or?taking?of?any?action?in?reliance?upon,?this?information?by?persons?or?entities?other?than?the?intended?recipient?is?prohibited.?If?you?received?this?by?mistake,?please?contact?the?sender?immediately.?American?Riviera?Bank?keeps?a?copy?of?all?E-mails?sent?and?received?for?a?minimum?of?18?months.?All?retained?E-mails?may?be?subject?to?audits?and?litigation?research.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Hector Santos]

From a software engineering standpoint, we have an "Lookup" black box 
mechanism.  It should be left open-ended so the DMARC-bis can move it. 
 The default mechanism is the existing DMARC one. Consider PSD a 
Lookup extension to DMARCbis.DMARCbis can describe "Lookup 
Extensions." Remember, we still TPA design issues and we have an 
extended lookup ATPS deployed.  Until we get a valid TPA method more 
systems accept, we will never be done with DKIM Policy modeling.


Can we please move on to completing DMARC as a standard?


On 2/3/2020 10:08 PM, Murray S. Kucherawy wrote:

On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz mailto:cr...@ftld.com>> wrote:

Hi Murray,

<<>>

In my capacity as managing director of fTLD Registry Services
(fTLD), registry operator of the .BANK and .INSURANCE TLDs, I
believe PSD would provide invaluable threat intelligence to domain
registrants and to TLD administrators like ourselves for
NXDOMAINs. PSD has tremendous value to specialized TLDs including,
but not limited to, .BRANDS, community-based domains,
high-security domains, governments, etc. and as such I believe PSD
should proceed. I’ve previously posted to this list expressing
this view and while fTLD cannot participate in experimentation due
to a prohibition by ICANN, we remain committed to supporting and
seeing this work continue.


Craig,

Thanks for this, and for one other person that sent to the chairs
privately (it was a list non-member caught in moderation, nothing secret).

To be clear, however: I think the working group mailing list archive
has enough of a record that participants think the experiment will be
useful or even critical to the evolution of DMARC, though people are
of course welcome to affirm that support for the record.  The question
being put, however, goes to the form of the experiment and the current
form of DMARC as a protocol with respect to determining Organizational
Domains, and whether there are indeed risks to the deployed
infrastructure that the experiment could become permanent.  That's the
meaty stuff that would really help to move this along.

-MSK


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



--
HLS


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Chudow, Eric B CIV NSA DSAW (USA)]

On Tuesday, February 04, 2020 3:44 PM Scott Kitterman wrote:
> As designed, the experiment is self-contained: For senders, it only affects
> PSDs that have been listed as participants. For receivers, it only affects
> receivers that choose to deploy code to do the additional check related to 
> PSD DMARC. As far as I can determine, there is zero impact on anyone else.

On Wednesday, February 05, 2020 5:59 AM Craig Schwartz wrote:
> Second, I have consulted with my technical advisors and our conclusion is
> that the risks to deployed infrastructure if this experiment becomes 
> permanent are negligible.

As both Craig and Scott pointed out, this experiment will only impact senders 
and receivers who opt-in to participating and has minimal risks to deployed 
infrastructure, so there shouldn’t be an issue there. For scalability, it may 
or may not scale as is, but the experiment has limited risk and should provide 
data on scalability or other issues, and so would be a good experiment to 
provide input into making DMARC better. 

On Wednesday, February 05, 2020 5:59 AM Craig Schwartz wrote:
> Finally, if the DMARC working group is successful in updating DMARC not to 
> use the PSL, then PSD DMARC would naturally evolve to use that solution (PSD
> is currently defined relative to org domain, so if the method for finding org
> domain changes, PSD DMARC will use it without any change needed).  As a 
> result, to the extent the use of lists like the PSL is a problem, PSD DMARC 
> is already ready to take advantage of whatever solution the IETF develops.

For the question related to the PSL and determining the Organizational Domain, 
I think Scott, Kurt, and Craig established this is not an issue for this 
experiment since that issue lies with DMARC itself and so it does not need to 
be addressed in PSD DMARC or for this experiment to proceed. 

On Tuesday, February 4, 2020 3:49 PM Andrew Kennedy wrote:
> One has to wonder if delaying or impeding advancement of this I-D, because
> of an external dependency that appears unlikely to be resolved in a timely
> fashion, is making the perfect the enemy of the good.  

On Monday, February 3, 2020 2:52 PM Ian Levy wrote:
> Experiments will give us data that helps us make better solutions in the 
> future. If those solutions look like the current draft then great. If they
> don’t then we’ll be changing them based on data and experience. 

Lastly, I agree with Ian, Andrew, and others that making everything perfect 
now is the enemy of the good and we should move ahead with the experiment to 
get better data to make better solutions. I think that PSD DMARC will be 
valuable and should proceed.

Thanks,
-Eric


Eric Chudow
DoD Cybersecurity Mitigations

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 2/5/2020 6:40 AM, Dave Crocker wrote:


Help me understand.



I'll try with the



no idea why my text got truncated.

what I typed was: I'll try with the other response I'm considering.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 2/4/2020 10:13 PM, Scott Kitterman wrote:

On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:


I don't recall that scaling limitation was an embedded and acknowledged
fact about that spec. And with a quick scan I don't see anything about
that in the document.

There is a difference between having some folk be critical of an
experiment, versus have its non-scalability be an admitted limit to its
future.  That is, you or I or whoever might know a spec sucks and can't
succeed, but that's different from having the formal process declare
that an experiment is /intended/ not to scale, which seems to be the
case here.

This claim seems to me to be unrelated to anything in the draft.  Would you
please point to where you found this?



Murray's 12/3 email:

"I don't think it's based entirely on naivety.  I think there's a 
healthy dose of feeling that the experiment as it's currently designed 
couldn't possibly scale to "the entire domain namespace" and/or "all 
servers on the Internet", so in that sense from where I sit there's a 
built in safeguard against this becoming a permanent wart."






Why would the expectations for Experimental be higher than for
Informational?  LMTP is Informational, and it certainly needs to succeed.

As a rule -- or certainly a solid pattern -- Experimental means that the
document wants to be standards track or BCP but needs some vetting
before being permitted that honor.  Informational docs don't have an
expectation of making it to standards track.

Would you withdraw your objections if we made this informational?


It would eliminate my concerns about this being Experimental, of 
course.  With an equal 'of course', it would not affect the technical 
concerns.





Help me understand.



I'll try with the other note I'm considering. However my intent for that 
note is as a summary, not as offering some new material.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Craig Schwartz]

Murray,

Notwithstanding the extensive commentary on this list in the last 24 hours,
you wrote the following so let me share some thoughts.

<<>>

First, while I know you've said the needs of external actors won't
weigh on your
decision about moving forward, I would like to mention that having a stable
reference for PSD DMARC will help us with working towards policy changes
that would allow us to participate in this experiment.  It may not be important
to the WG Chairs' decision on the draft, but there are stakeholders for
whom it is important.

Second, I have consulted with my technical advisors and our conclusion is
that the risks to deployed infrastructure if this experiment becomes
permanent are negligible.  Currently the PSL has 8,818 non-comment
entries.  For PSD DMARC, we have 4.  We don't believe adding a list that's
..04% as long as the one that is currently being used successfully for DMARC
is an issue at all. Additionally, we believe that the use of this list to
constrain when PSD DMARC lookups will need to occur provides a very useful
limit on the impacts to DNS
(not that we would expect them to be significant regardless).

Finally, if the DMARC working group is successful in updating DMARC not to
use the PSL, then PSD DMARC would naturally evolve to use that solution
(PSD is currently defined relative to org domain, so if the method for
finding org domain changes, PSD DMARC will use it without any change
needed).  As a result, to the extent the use of lists like the PSL is a
problem, PSD DMARC is already ready to take advantage of whatever solution
the IETF develops.

In short, we've reviewed this and see many advantages to proceeding and
none for not.

Craig


*--*
Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .INSURANCE
Office: +1 202 589 2532
Mobile: +1 202 236 1154
Skype: craig-schwartz
www.fTLD.com








On Mon, Feb 3, 2020 at 10:08 PM Murray S. Kucherawy 
wrote:

> On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz  wrote:
>
>> Hi Murray,
>>
>> <<> of needing this work but not knowing how to engage; you either give your
>> feedback on the list or privately to the chairs or Area Directors, or you
>> are along for whatever ride results.  Please indicate, as soon as possible,
>> where your support lies given the above.>>>
>>
>> In my capacity as managing director of fTLD Registry Services (fTLD),
>> registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would
>> provide invaluable threat intelligence to domain registrants and to TLD
>> administrators like ourselves for NXDOMAINs. PSD has tremendous value to
>> specialized TLDs including, but not limited to, .BRANDS, community-based
>> domains, high-security domains, governments, etc. and as such I believe PSD
>> should proceed. I’ve previously posted to this list expressing this view
>> and while fTLD cannot participate in experimentation due to a prohibition
>> by ICANN, we remain committed to supporting and seeing this work continue.
>>
>
> Craig,
>
> Thanks for this, and for one other person that sent to the chairs
> privately (it was a list non-member caught in moderation, nothing secret)..
>
> To be clear, however: I think the working group mailing list archive has
> enough of a record that participants think the experiment will be useful or
> even critical to the evolution of DMARC, though people are of course
> welcome to affirm that support for the record.  The question being put,
> however, goes to the form of the experiment and the current form of DMARC
> as a protocol with respect to determining Organizational Domains, and
> whether there are indeed risks to the deployed infrastructure that the
> experiment could become permanent.  That's the meaty stuff that would
> really help to move this along.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Tue, Feb 4, 2020 at 10:13 PM Scott Kitterman 
wrote:

>
> Assuming that's correct, please help me understand what PSD DMARC is
> affected at all.  All it does is consume the org domain however
> DMARC/DMARCbis choose to define it.  I don't see as it makes a difference
> from a PSD DMARC perspective.
>
> I get that you want to fix the architectural warts in DMARC and I don't
> disagree with you about working on that.  Where I get lost is how PSD DMARC
> has anything to do with it.  PSD DMARC could be done first, in parallel, or
> after the DMARC architectural work.  It would have no impact on that work.
>
> I would like to understand your position, but I don't, so please help me
> out here.
>

Scott,

Thank you for expressing this so clearly. This is exactly the issue that
I've been trying to understand in this series of conversations. It seems
like the PSD proposal has been being used as leverage to have an (almost)
entirely separate discussion about DMARCbis.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Tuesday, February 4, 2020 10:20:14 PM EST Dave Crocker wrote:
> (I am trying to formulate a response on the higher-level technical and
> process issues under consideration, but decided to respond now on these
> particulars, since they are more focused...)
> 
> On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:
> > Dave,
> > 
> > On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker  > 
> > > wrote:
> >> Nothing I've worked on at the IETF with such a label is something
> >> I would necessarily stand behind as Internet-scalable.
> > 
> > Such as?
> > 
> > RFC 6541 comes to mind.  To the best of my knowledge, it's an
> > experiment that never even ran.
> 
> I don't recall that scaling limitation was an embedded and acknowledged
> fact about that spec. And with a quick scan I don't see anything about
> that in the document.
> 
> There is a difference between having some folk be critical of an
> experiment, versus have its non-scalability be an admitted limit to its
> future.  That is, you or I or whoever might know a spec sucks and can't
> succeed, but that's different from having the formal process declare
> that an experiment is /intended/ not to scale, which seems to be the
> case here.

This claim seems to me to be unrelated to anything in the draft.  Would you 
please point to where you found this?

> > Implementations shipped, but its use on the open Internet was never
> > detected or reported.  And I had my doubts about the scalability of
> > the second DNS check that was added to it, but it didn't seem like it
> > could go forward without.
> > 
> > One that wasn't mine: RFC 6210, an experiment to prove how bad
> > something can be.
> 
> There is a reasonable argument to be made that little about /any/
> security spec actually scales well, but that's such a cheap shot, I
> wouldn't dream of taking it.
> 
> However, yeah, "to find out how bad including hash parameters will be"
> does seem to provide an existence proof for using IETF Experimental to
> bench-test something rather than as a gateway to standard for that
> something.  sigh.
> 
> >> But I would probably expect something at Informational probably
> >> to scale, and anything with "Standard" in it certainly to scale.
> > 
> > Laying any general expectation on an IETF Informational RFC would
> > be a mistake, because there is so much variety in their content
> > and intent.
> > 
> > Why would the expectations for Experimental be higher than for
> > Informational?  LMTP is Informational, and it certainly needs to succeed.
> 
> As a rule -- or certainly a solid pattern -- Experimental means that the
> document wants to be standards track or BCP but needs some vetting
> before being permitted that honor.  Informational docs don't have an
> expectation of making it to standards track.

Would you withdraw your objections if we made this informational?

> >> So: Can you propose any sort of specific restructuring of the
> >> document or the experiment that achieves the same goal as the
> >> current version while also resolving your concerns?
> > 
> > I'm pretty sure I've raised fundamental concerns about this work
> > and that those concerns have not been addressed.  The simple
> > summary is that the way to restructure this work is to go back to
> > first principles.  But there doesn't seem to be any interest in
> > having that sort of discussion.
> > 
> > I thought we were having that sort of a discussion right here.
> > 
> > Your position as I recall is that we have no choice but to take all of
> > this back to first principles and separate DMARC from the
> > determination of Organizational Domain (i.e., make them separate
> > documents) before PSD can proceed.
> 
> Unfortunately, that's accurate. At the least, I'd expect to see
> thoughtful responses and some breadth of support for those responses,
> countering the fundamental concerns I expressed. I don't recall seeing
> responses with such substance.
> 
> (One of the challenges for me, in trying to formulate the 'thoughtful'
> response I'm considering is to provide/repeat a concise summary of those
> fundamental concerns.  As I recall they were both architectural and
> operational.)

Help me understand.

Currently the proposal is:

PSD DMARC defines PSD relative to org domain and points to DMARC for how one 
finds org domain (no PSL reference in the PSD DMARC draft - there have been at 
times, but there aren't now).

You find this unacceptable, as I understand it.  What you think we should do is 
first split the DMARC spec into two so that:

PSD DMARC defines PSD relative to org domain and points to DMARCbis for how one 
finds org domain and DMARCbis points to a new spec that explains how to use the 
PSL to find the org domain (or some other method if it's agreed).

You find this acceptable, as I understand it.

Assuming that's correct, please help me understand what PSD DMARC is affected 
at all.  All 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

(I am trying to formulate a response on the higher-level technical and 
process issues under consideration, but decided to respond now on these 
particulars, since they are more focused...)



On 2/3/2020 10:47 AM, Murray S. Kucherawy wrote:

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker > wrote:



Nothing I've worked on at the IETF with such a label is something
I would necessarily stand behind as Internet-scalable.


Such as?


RFC 6541 comes to mind.  To the best of my knowledge, it's an 
experiment that never even ran.



I don't recall that scaling limitation was an embedded and acknowledged 
fact about that spec. And with a quick scan I don't see anything about 
that in the document.


There is a difference between having some folk be critical of an 
experiment, versus have its non-scalability be an admitted limit to its 
future.  That is, you or I or whoever might know a spec sucks and can't 
succeed, but that's different from having the formal process declare 
that an experiment is /intended/ not to scale, which seems to be the 
case here.



Implementations shipped, but its use on the open Internet was never 
detected or reported.  And I had my doubts about the scalability of 
the second DNS check that was added to it, but it didn't seem like it 
could go forward without.


One that wasn't mine: RFC 6210, an experiment to prove how bad 
something can be.



There is a reasonable argument to be made that little about /any/ 
security spec actually scales well, but that's such a cheap shot, I 
wouldn't dream of taking it.


However, yeah, "to find out how bad including hash parameters will be" 
does seem to provide an existence proof for using IETF Experimental to 
bench-test something rather than as a gateway to standard for that 
something.  sigh.




But I would probably expect something at Informational probably
to scale, and anything with "Standard" in it certainly to scale.

Laying any general expectation on an IETF Informational RFC would
be a mistake, because there is so much variety in their content
and intent.


Why would the expectations for Experimental be higher than for 
Informational?  LMTP is Informational, and it certainly needs to succeed.


As a rule -- or certainly a solid pattern -- Experimental means that the 
document wants to be standards track or BCP but needs some vetting 
before being permitted that honor.  Informational docs don't have an 
expectation of making it to standards track.




So: Can you propose any sort of specific restructuring of the
document or the experiment that achieves the same goal as the
current version while also resolving your concerns?


I'm pretty sure I've raised fundamental concerns about this work
and that those concerns have not been addressed.  The simple
summary is that the way to restructure this work is to go back to
first principles.  But there doesn't seem to be any interest in
having that sort of discussion.

I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of 
this back to first principles and separate DMARC from the 
determination of Organizational Domain (i.e., make them separate 
documents) before PSD can proceed.



Unfortunately, that's accurate. At the least, I'd expect to see 
thoughtful responses and some breadth of support for those responses, 
countering the fundamental concerns I expressed. I don't recall seeing 
responses with such substance.


(One of the challenges for me, in trying to formulate the 'thoughtful' 
response I'm considering is to provide/repeat a concise summary of those 
fundamental concerns.  As I recall they were both architectural and 
operational.)



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dotzero]

On Tue, Feb 4, 2020 at 6:36 PM Murray S. Kucherawy 
wrote:

> On Tue, Feb 4, 2020 at 1:44 PM Dotzero  wrote:
>
>> On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy 
>> wrote:
>>
>>> 
>>>
>>> I think what Dave proposed about PSL separation from DMARC is entirely
>>> appropriate and pragmatic, and in fact probably easy enough: DMARC is
>>> changed so that it says the organizational domain is determined using some
>>> process [currently] external to DMARC, and then a second document explains
>>> how that process is accomplished using the PSL (and/or PSD, depending on
>>> when the experiment result comes in).  That's a fairly simple edit overall,
>>> and is actually probably minor and non-controversial compared to some of
>>> the other surgery that I believe is in the queue.
>>>
>>>
>> This would go a long way to alleviating my concerns.
>>
>
> The question to you, then, is: Is it the case that this MUST be done
> *first*?
>
> -MSK
>

Dropping IETF "MUST" on me are you? "Alex, I'll take something between
"MUST" and "SHOULD" for $200".

Let me cogitate on this a bit.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Tue, Feb 4, 2020 at 1:44 PM Dotzero  wrote:

> On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy 
> wrote:
>
>> 
>>
>> I think what Dave proposed about PSL separation from DMARC is entirely
>> appropriate and pragmatic, and in fact probably easy enough: DMARC is
>> changed so that it says the organizational domain is determined using some
>> process [currently] external to DMARC, and then a second document explains
>> how that process is accomplished using the PSL (and/or PSD, depending on
>> when the experiment result comes in).  That's a fairly simple edit overall,
>> and is actually probably minor and non-controversial compared to some of
>> the other surgery that I believe is in the queue.
>>
>>
> This would go a long way to alleviating my concerns.
>

The question to you, then, is: Is it the case that this MUST be done
*first*?

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Tuesday, February 4, 2020 4:26:30 PM EST Murray S. Kucherawy wrote:
> On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman  wrote:
> > I agree on DMARCbis.  I don't think advancing this draft has a significant
> > effect on that.  Worst case, if DMARCbis is done before we can reach any
> > conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
> > it.
> 
> I think we've always been assuming that PSD DMARC would be input to
> DMARCbis, so we were planning to start the latter but not close it until
> the former was completed.  This is the first time I've seen a different
> suggestion.

I think DMARCbis will take long enough that that is how things will work out, 
but if there's working group consensus to eventually proceed without it 
because it's not ready, that may well be a reasonable course of action.  
Proceeding with DMARC PSD doesn't tie the working group's hands.  I agree 
that's been the plan, but if the situation changes (and DMARCbis is ready, but 
PSD DMARC isn't ready to be included) then we can change it.

It does occur to me that a more relaxed approach to the question of if PSD 
DMARC will be included in the working group DMARCbis deliverable would be much 
easier to sustain if there was a stable reference for it (i.e. we publish the 
draft).

> I'd love to hear more opinions about ordering of the work here.  This seems
> like an ideal time to review and update our milestones.

I think it's not predictable when DMARCbis will be mostly complete and it's 
also hard to predict how long it will take to resolve the open questions in 
the experiment.  They can run in parallel for some period of time and we can 
make a decision when there's one to make.  There's none needed now.

> > I don't see anything about PSD DMARC being inherently on the critical path
> > for
> > DMARCbis.  I suspect the current major obstacle to DMARCbis is that the
> > question of how to take the PSL out of the equation is unsolved, despite
> > one
> > IETF WG that was supposed to be dedicated to the question.
> > 
> > I don't think not publishing PSD DMARC helps move DMARCbis forward, so I
> > think
> > it's a false choice.
> 
> I think what Dave proposed about PSL separation from DMARC is entirely
> appropriate and pragmatic, and in fact probably easy enough: DMARC is
> changed so that it says the organizational domain is determined using some
> process [currently] external to DMARC, and then a second document explains
> how that process is accomplished using the PSL (and/or PSD, depending on
> when the experiment result comes in).  That's a fairly simple edit overall,
> and is actually probably minor and non-controversial compared to some of
> the other surgery that I believe is in the queue.

That's exactly the approach PSD DMARC takes about organizational domain, so 
I'm even more confused how that's problematic for PSD DMARC but doing the 
exact same thing solves the problem for DMARC?

I also don't see how that actually helps.  It seems to be something along the 
lines of claiming DMARC no longer relies on the PSL, but telling people to pay 
no attention to the man behind the curtain [1].

Scott K

> Seth, our illustrious WG secretary, has been compiling that list, and
> perhaps can give us some idea where it stands?
> 
> -MSK

[1] https://www.shmoop.com/quotes/pay-no-attention-man-behind-the-curtain.html


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dotzero]

On Tue, Feb 4, 2020 at 4:26 PM Murray S. Kucherawy 
wrote:

> 
>
> I think what Dave proposed about PSL separation from DMARC is entirely
> appropriate and pragmatic, and in fact probably easy enough: DMARC is
> changed so that it says the organizational domain is determined using some
> process [currently] external to DMARC, and then a second document explains
> how that process is accomplished using the PSL (and/or PSD, depending on
> when the experiment result comes in).  That's a fairly simple edit overall,
> and is actually probably minor and non-controversial compared to some of
> the other surgery that I believe is in the queue.
>
>
This would go a long way to alleviating my concerns.

Michael Hammer


> Seth, our illustrious WG secretary, has been compiling that list, and
> perhaps can give us some idea where it stands?
>
> -MSK
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman  wrote:

> I agree on DMARCbis.  I don't think advancing this draft has a significant
> effect on that.  Worst case, if DMARCbis is done before we can reach any
> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
> it.
>

I think we've always been assuming that PSD DMARC would be input to
DMARCbis, so we were planning to start the latter but not close it until
the former was completed.  This is the first time I've seen a different
suggestion.

I'd love to hear more opinions about ordering of the work here.  This seems
like an ideal time to review and update our milestones.

I don't see anything about PSD DMARC being inherently on the critical path
> for
> DMARCbis.  I suspect the current major obstacle to DMARCbis is that the
> question of how to take the PSL out of the equation is unsolved, despite
> one
> IETF WG that was supposed to be dedicated to the question.
>
> I don't think not publishing PSD DMARC helps move DMARCbis forward, so I
> think
> it's a false choice.
>

I think what Dave proposed about PSL separation from DMARC is entirely
appropriate and pragmatic, and in fact probably easy enough: DMARC is
changed so that it says the organizational domain is determined using some
process [currently] external to DMARC, and then a second document explains
how that process is accomplished using the PSL (and/or PSD, depending on
when the experiment result comes in).  That's a fairly simple edit overall,
and is actually probably minor and non-controversial compared to some of
the other surgery that I believe is in the queue.

Seth, our illustrious WG secretary, has been compiling that list, and
perhaps can give us some idea where it stands?

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Tue, Feb 4, 2020 at 12:25 PM Dotzero  wrote:

> I am not against experiments, but having reread the entire thread starting
> from Dave's post in August, I believe his concerns are valid.
>

I want to say again that I make no assertion that any of Dave's claims are
invalid.  The main thing I want us to discuss is whether any of them rise
to the level of halting PSD's movement through the process versus finding a
way to do all of it in parallel, accepting the risks being identified.
Fixing everything first will be extremely time-consuming, but it is a
possible course of action.

My question to the chairs and the group as a whole is whether an experiment
> can be constructed that is valid and useful without "comingling" PSD issues
> and concerns with the core of DMARC at scale? That is, the group that is
> seriously interested does their experiment amongst themselves to produce
> data that supports and justifies such changes in the wild.
>

Yes, that is the question.  And the working group can still legitimately
conclude that it wants to advance this document before conducting that
experiment.  As you said, rough consensus.

I would remind everyone, however, that this document still needs to pass a
two week IETF-wide Last Call, appropriate directorate reviews, and IESG
review before it can be sent to the RFC editor queue, where again it will
wait for a while.  Assuming we have consensus to proceed in spite of what
Dave and now Mike are saying, we're still at least a month or two from
publication.  That seems a long time to wait before starting the experiment
and collecting data.  Are we sure we want to serialize everything this way?

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Tuesday, February 4, 2020 3:50:12 PM EST Dotzero wrote:
> On Tue, Feb 4, 2020 at 3:44 PM Scott Kitterman  wrote:
> > On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote:
> > > I am not against experiments, but having reread the entire thread
> > 
> > starting
> > 
> > > from Dave's post in August, I believe his concerns are valid. My
> > > question
> > > to the chairs and the group as a whole is whether an experiment can be
> > > constructed that is valid and useful without "comingling" PSD issues and
> > > concerns with the core of DMARC at scale? That is, the group that is
> > > seriously interested does their experiment amongst themselves to produce
> > > data that supports and justifies such changes in the wild.
> > 
> > I think the draft as written works as you suggest.  I think Dave's
> > concerns
> > are really about DMARC (or at least 99.6% about DMARC) and not
> > significantly
> > related to this addition.  As designed, the experiment is self-contained:
>
> And those are my concerns as well. I would rather see DMARCbis go forward

I agree on DMARCbis.  I don't think advancing this draft has a significant 
effect on that.  Worst case, if DMARCbis is done before we can reach any 
conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in it.

I don't see anything about PSD DMARC being inherently on the critical path for 
DMARCbis.  I suspect the current major obstacle to DMARCbis is that the 
question of how to take the PSL out of the equation is unsolved, despite one 
IETF WG that was supposed to be dedicated to the question.

I don't think not publishing PSD DMARC helps move DMARCbis forward, so I think 
it's a false choice.

Scott K

> 
> > For senders, it only affects PSDs that have been listed as participants.
> > 
> > For receivers, it only affects receivers that choose to deploy code to do
> > the
> > additional check related to PSD DMARC.
> > 
> > As far as I can determine, there is zero impact on anyone else.
> > 
> > We have running code.  I'll leave it to the chairs to evaluate the
> > consensus.
> > 
> > Scott K


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dotzero]

On Tue, Feb 4, 2020 at 3:44 PM Scott Kitterman  wrote:

> On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote:
> > I am not against experiments, but having reread the entire thread
> starting
> > from Dave's post in August, I believe his concerns are valid. My question
> > to the chairs and the group as a whole is whether an experiment can be
> > constructed that is valid and useful without "comingling" PSD issues and
> > concerns with the core of DMARC at scale? That is, the group that is
> > seriously interested does their experiment amongst themselves to produce
> > data that supports and justifies such changes in the wild.
>
> I think the draft as written works as you suggest.  I think Dave's
> concerns
> are really about DMARC (or at least 99.6% about DMARC) and not
> significantly
> related to this addition.  As designed, the experiment is self-contained:
>
>
And those are my concerns as well. I would rather see DMARCbis go forward


> For senders, it only affects PSDs that have been listed as participants.
>
> For receivers, it only affects receivers that choose to deploy code to do
> the
> additional check related to PSD DMARC.
>
> As far as I can determine, there is zero impact on anyone else.
>
> We have running code.  I'll leave it to the chairs to evaluate the
> consensus.
>
> Scott K
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Andrew Kennedy]

Scott--I agree whole-heartedly.  One has to wonder if delaying or impeding
advancement of this I-D, because of an external dependency that appears
unlikely to be resolved in a timely fashion, is making the perfect the
enemy of the good.  This group has much accomplish in a time frame quite
possibly measured in years and that work can and should be done in parallel
to competing IETF equities.  The stated risk, as I understand it, appears
small as it is constrained by the experiment and resolvable in future
drafts (and implementations).

-Andrew

On Tue, Feb 4, 2020 at 2:49 PM Scott Kitterman  wrote:

> On Tuesday, February 4, 2020 12:39:09 PM EST Kurt Andersen (b) wrote:
> > I support publishing the I-D as confirmed in the WGLC with (perhaps) some
> > additional caveats regarding the ephemerality of the Experiment as deemed
> > necessary by the chairs.
> >
> > Given the expected duration of the experiment (at least a year to collect
> > some useful data, if not 2-3 years), I also support unblocking the other
> > work in this WG since we ought not wait for this experiment to "conclude"
> > (whatever that means) before proceeding on other work items.
>
> I don't see any reason the other WG items can't proceed in parallel with
> the
> experiment.  I believe the changes to DMARC to bring it to IETF standards,
> particularly the need for an alternative to the PSL, will take significant
> effort to achieve.  As a result, I think there's little risk that results
> from
> the experiment will end up being a critical path item for any WG effort.
>
> Scott K
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dotzero]

On Tue, Feb 4, 2020 at 3:39 PM Scott Kitterman  wrote:

> On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote:
> > Someone pointed to Sender-ID as an example experiment. A very poor
> example
> > to choose. It was broken from the start. As an aside, I kept sending
> email
> > to the folks at Microsoft using @Microsoft.com email addresses by using
> > "Sender" to game PRA to get a neutral". Furthermore, it dragooned senders
> > who had no intention of participating in the experiment by reusing their
> > published SPF records in a manner they did not intend them to be used. I
> > also point out how long it took to put a stake in the heart of Sender-ID.
> > And yet even today we can find Sender-ID records littering the Internet
> and
> > even a few places doing Sender-ID checks. For some definition of "We", we
> > are good at additions and modifications but poor at deletes.
>
> That was me.  I agree it was a horrible idea.  The point wasn't that
> Sender ID
> was great, it wasn't.  The point was that the AIB considered it reasonable
> as
> an experiment.  I think this is far less risky than that was.  I was
> trying to
> respond to the idea what the IETF doesn't support experiments where there
> are
> technical concerns about the nature of the technology.  The AIB's
> position, as
> I read it, was that such experiments are fine and if the IESG has
> concerns,
> they should add a note to document.
>
> Scott K
>

At the risk of offending some, politics was the elephant in the room on
Sender-ID and SPF both ending up being designated as experimental.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote:
> I am not against experiments, but having reread the entire thread starting
> from Dave's post in August, I believe his concerns are valid. My question
> to the chairs and the group as a whole is whether an experiment can be
> constructed that is valid and useful without "comingling" PSD issues and
> concerns with the core of DMARC at scale? That is, the group that is
> seriously interested does their experiment amongst themselves to produce
> data that supports and justifies such changes in the wild.

I think the draft as written works as you suggest.  I think Dave's concerns 
are really about DMARC (or at least 99.6% about DMARC) and not significantly 
related to this addition.  As designed, the experiment is self-contained:

For senders, it only affects PSDs that have been listed as participants.

For receivers, it only affects receivers that choose to deploy code to do the 
additional check related to PSD DMARC.

As far as I can determine, there is zero impact on anyone else.

We have running code.  I'll leave it to the chairs to evaluate the consensus.

Scott K



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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Tuesday, February 4, 2020 3:25:06 PM EST Dotzero wrote:
> Someone pointed to Sender-ID as an example experiment. A very poor example
> to choose. It was broken from the start. As an aside, I kept sending email
> to the folks at Microsoft using @Microsoft.com email addresses by using
> "Sender" to game PRA to get a neutral". Furthermore, it dragooned senders
> who had no intention of participating in the experiment by reusing their
> published SPF records in a manner they did not intend them to be used. I
> also point out how long it took to put a stake in the heart of Sender-ID.
> And yet even today we can find Sender-ID records littering the Internet and
> even a few places doing Sender-ID checks. For some definition of "We", we
> are good at additions and modifications but poor at deletes.

That was me.  I agree it was a horrible idea.  The point wasn't that Sender ID 
was great, it wasn't.  The point was that the AIB considered it reasonable as 
an experiment.  I think this is far less risky than that was.  I was trying to 
respond to the idea what the IETF doesn't support experiments where there are 
technical concerns about the nature of the technology.  The AIB's position, as 
I read it, was that such experiments are fine and if the IESG has concerns, 
they should add a note to document.

Scott K


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dotzero]

I do not support publishing draft-ietf-dmarc-psd as is. Running code and
rough consensus.

I, as were a few others on the list, was part of the private effort that
eventually became the "DMARC team". I point out that until DMARC was
published openly, the experiment had absolutely zero impact on others and
the Internet at large. It was a closed system. Subsequent to publication
(not originally as an I-D), some receivers did take steps that some
considered coercive towards senders, but that was beyond the specification
itself. At a subsequent point, some (large) sender domains published DMARC
policies that were painful for both intermediaries as well as users with
accounts at those domains but which sent mail from other origins.

Someone pointed to Sender-ID as an example experiment. A very poor example
to choose. It was broken from the start. As an aside, I kept sending email
to the folks at Microsoft using @Microsoft.com email addresses by using
"Sender" to game PRA to get a neutral". Furthermore, it dragooned senders
who had no intention of participating in the experiment by reusing their
published SPF records in a manner they did not intend them to be used. I
also point out how long it took to put a stake in the heart of Sender-ID.
And yet even today we can find Sender-ID records littering the Internet and
even a few places doing Sender-ID checks. For some definition of "We", we
are good at additions and modifications but poor at deletes.

I am not against experiments, but having reread the entire thread starting
from Dave's post in August, I believe his concerns are valid. My question
to the chairs and the group as a whole is whether an experiment can be
constructed that is valid and useful without "comingling" PSD issues and
concerns with the core of DMARC at scale? That is, the group that is
seriously interested does their experiment amongst themselves to produce
data that supports and justifies such changes in the wild.

"Be conservative in what you do, be liberal in what you accept from others.
"

Michael Hammer

On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy 
wrote:

> Dave,
>
> On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker  wrote:
>
>> Nothing I've worked on at the IETF with such a label is something I would
>> necessarily stand behind as Internet-scalable.
>>
>> Such as?
>>
>
> RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment
> that never even ran.  Implementations shipped, but its use on the open
> Internet was never detected or reported.  And I had my doubts about the
> scalability of the second DNS check that was added to it, but it didn't
> seem like it could go forward without.
>
> One that wasn't mine: RFC 6210, an experiment to prove how bad something
> can be.
>
>>
>> But I would probably expect something at Informational probably to scale,
>> and anything with "Standard" in it certainly to scale.
>>
>> Laying any general expectation on an IETF Informational RFC would be a
>> mistake, because there is so much variety in their content and intent.
>>
>
> Why would the expectations for Experimental be higher than for
> Informational?  LMTP is Informational, and it certainly needs to succeed.
>
>> So: Can you propose any sort of specific restructuring of the document or
>> the experiment that achieves the same goal as the current version while
>> also resolving your concerns?
>>
>> I'm pretty sure I've raised fundamental concerns about this work and that
>> those concerns have not been addressed.  The simple summary is that the way
>> to restructure this work is to go back to first principles.  But there
>> doesn't seem to be any interest in having that sort of discussion.
>>
> I thought we were having that sort of a discussion right here.
>
> Your position as I recall is that we have no choice but to take all of
> this back to first principles and separate DMARC from the determination of
> Organizational Domain (i.e., make them separate documents) before PSD can
> proceed.  Since that will take months, I've proposed a compromise, because
> I don't think that's strictly necessary to allow the data collection work
> to proceed.  The proposed compromise, then, is to do the work in hand, then
> rip the experiment down and apply whatever we learn from it to standards
> track DMARC, which is the next milestone.  That will include the separation
> of function you proposed, because we agree it's an improvement.  I believe
> the set of likely participants in the experiment are present on the list,
> and it can be made clear to them that they should have no expectation of
> the mechanism it describes surviving past the termination of the
> experiment.  So the path forward here comes down to whether the working
> group achieves consensus on that compromise, or whether the asserted risk
> of the experiment's structure leaking into the permanent deployed base
> warrants shutting it down before it starts.
>
> Now, to the working group as a whole:
>
> The chairs note that we 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Tuesday, February 4, 2020 12:39:09 PM EST Kurt Andersen (b) wrote:
> I support publishing the I-D as confirmed in the WGLC with (perhaps) some
> additional caveats regarding the ephemerality of the Experiment as deemed
> necessary by the chairs.
> 
> Given the expected duration of the experiment (at least a year to collect
> some useful data, if not 2-3 years), I also support unblocking the other
> work in this WG since we ought not wait for this experiment to "conclude"
> (whatever that means) before proceeding on other work items.

I don't see any reason the other WG items can't proceed in parallel with the 
experiment.  I believe the changes to DMARC to bring it to IETF standards, 
particularly the need for an alternative to the PSL, will take significant 
effort to achieve.  As a result, I think there's little risk that results from 
the experiment will end up being a critical path item for any WG effort.

Scott K


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Mon 03/Feb/2020 19:47:45 +0100 Murray S. Kucherawy wrote:
> 
> Now, to the working group as a whole:
> 
> The chairs note that we have a duly and properly completed WGLC in hand. 
> Still, Dave's concerns have validity, so they need to be considered by the
> working group.  Since we need to do *something*, we are now putting the
> question back to the working group, and we need to see some answers.  The
> chairs will not accept hearsay replies or opinions, or expressions of needing
> this work but not knowing how to engage; you either give your feedback on the
> list or privately to the chairs or Area Directors, or you are along for
> whatever ride results.  Please indicate, as soon as possible, where your
> support lies given the above.  We're not going to let this go additional 
> months
> (probably not even weeks) without progress in some direction.


I support publishing draft-ietf-dmarc-psd as is.

As I wrote already, I appreciate Dave's narration and think it can lead to a
better overall statement of DMARC.  However, I don't think it suggests any
practical software technique that may improve [PSD]DMARC implementations in the
short term.


> I will also say for the record that we don't find compelling the assertion 
> that
> resources will not be dedicated to the experiment absent a document in the RFC
> Editor queue.  That constraint is fully external to the IETF, and it will 
> carry
> no weight in the decision made here.  It should indeed be possible to run an
> experiment based on a document in any state at all.  We're entertaining
> publication not because it must happen, but because that action (currently) 
> has
> consensus, and it's our job to act on consensus.


There are a number of ICANN liaisons mentioned in IETF website[*].  I think it
is their, or at least some of them's, duty to inform the relevant ICANN
authority about the experiment, so that they can allow it to proceed, as soon
as draft-ietf-dmarc-psd enters the RFC Editor queue.  Will Area Directors
please advise them?

NOTE: The provision to publish _dmarc resource records, or whatever selection
of registered underscored node names[†], under selected global TLDs is *not* to
be considered ephemeral.


[*] https://ietf.org/about/liaisons/
[†]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names


> Dave also made an additional observation, that experiments expected to fail 
> are
> not generally what the IETF produces.  I would quibble some with that wording:
> The working group doesn't expect the experiment to "fail", but rather expects
> it to be ephemeral.  Were we to refer to chapter-and-verse, there's nothing in
> RFC2026 (which defines "Experimental" as a document status) that precludes 
> what
> the working group appears to be trying to do here.  As for whether the IETF
> generally should produce an Experimental document describing something
> ephemeral, I would claim that a working group or its chairs are below the pay
> grade where authoritative claims like those are made; it's the kind of thing
> about which the IESG makes proclamations.  Accordingly, I've Cc'd our current
> Area Director to see what he thinks might happen if we were to send this up,
> and give him a chance to provide guidance in case that's the decision (but we
> won't wait long for that either).


I don't expect the experiment to fail.

What seems to me to be ephemeral is its providing for three different
services[‡] to determine which TLDs deserve an extra DNS lookup.  The
experiment will hopefully determine which one(s) are fit.


[‡] https://psddmarc.org/



Best
Ale
-- 
























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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Monday, February 3, 2020 1:47:45 PM EST Murray S. Kucherawy wrote:
> Now, to the working group as a whole:
> 
> The chairs note that we have a duly and properly completed WGLC in hand.
> Still, Dave's concerns have validity, so they need to be considered by the
> working group.  Since we need to do *something*, we are now putting the
> question back to the working group, and we need to see some answers.  The
> chairs will not accept hearsay replies or opinions, or expressions of
> needing this work but not knowing how to engage; you either give your
> feedback on the list or privately to the chairs or Area Directors, or you
> are along for whatever ride results.  Please indicate, as soon as possible,
> where your support lies given the above.  We're not going to let this go
> additional months (probably not even weeks) without progress in some
> direction.

Personally, I think Dave is wrong.  I think he's given an assertion, but 
nothing beyond that.  Given that DMARC has been successfully deployed at scale 
depending on a list (PSL), I believe that's an adequate existence proof that 
Dave's assertion that anything depending on a list can't scale is not correct.

Dave's claim that the IETF hasn't done anything depending on a list may or may 
not be correct, I don't know, but that's not a technical point.  If the IETF 
was stopped by "we haven't done this before", we wouldn't have much of an 
Internet today.

That isn't to argue using the PSL to find the org domain is a technically clean 
solution.  It's not.  It's only less horrible than the alternatives.

> I will also say for the record that we don't find compelling the assertion
> that resources will not be dedicated to the experiment absent a document in
> the RFC Editor queue.  That constraint is fully external to the IETF, and
> it will carry no weight in the decision made here.  It should indeed be
> possible to run an experiment based on a document in any state at all.
> We're entertaining publication not because it must happen, but because that
> action (currently) has consensus, and it's our job to act on consensus.

I think the IETF tells external organizations not to use I-Ds [1], so I don't 
really understand this point, but I don't think it affects consensus much.
> 
> Dave also made an additional observation, that experiments expected to fail
> are not generally what the IETF produces.  I would quibble some with that
> wording: The working group doesn't expect the experiment to "fail", but
> rather expects it to be ephemeral.  Were we to refer to chapter-and-verse,
> there's nothing in RFC2026 (which defines "Experimental" as a document
> status) that precludes what the working group appears to be trying to do
> here.  As for whether the IETF generally should produce an Experimental
> document describing something ephemeral, I would claim that a working group
> or its chairs are below the pay grade where authoritative claims like those
> are made; it's the kind of thing about which the IESG makes proclamations.
> Accordingly, I've Cc'd our current Area Director to see what he thinks
> might happen if we were to send this up, and give him a chance to provide
> guidance in case that's the decision (but we won't wait long for that
> either).

It won't surprise you to find that I support publishing the draft substantially 
as is.  I believe there are some open questions described in the experimental 
portions of the draft that will take some operational experience to evaluate 
and having a stable reference will be useful for that purpose.

As a side note, I don't think this is anywhere near the most extreme 
experimental document that IETF has considered for publication.  The Sender ID 
RFCs conflicted with current Internet Standards and were still published even 
after an appeal on that point.  Having just re-read the IAB response to that 
appeal [2], particularly Section 3, I'm even more convinced that the DMARC PSD 
draft is well within the realm of what's appropriate for an experimental RFC.

Scott K


[1] https://ietf.org/standards/ids/
[2] 
https://www.iab.org/appeals/2006-2/iab-response-to-appeal-from-julian-mehnle-2-march-2006/


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz  wrote:

> Hi Murray,
>
> << of needing this work but not knowing how to engage; you either give your
> feedback on the list or privately to the chairs or Area Directors, or you
> are along for whatever ride results.  Please indicate, as soon as possible,
> where your support lies given the above.>>>
>
> In my capacity as managing director of fTLD Registry Services (fTLD),
> registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would
> provide invaluable threat intelligence to domain registrants and to TLD
> administrators like ourselves for NXDOMAINs. PSD has tremendous value to
> specialized TLDs including, but not limited to, .BRANDS, community-based
> domains, high-security domains, governments, etc. and as such I believe PSD
> should proceed. I’ve previously posted to this list expressing this view
> and while fTLD cannot participate in experimentation due to a prohibition
> by ICANN, we remain committed to supporting and seeing this work continue..
>

Craig,

Thanks for this, and for one other person that sent to the chairs privately
(it was a list non-member caught in moderation, nothing secret).

To be clear, however: I think the working group mailing list archive has
enough of a record that participants think the experiment will be useful or
even critical to the evolution of DMARC, though people are of course
welcome to affirm that support for the record.  The question being put,
however, goes to the form of the experiment and the current form of DMARC
as a protocol with respect to determining Organizational Domains, and
whether there are indeed risks to the deployed infrastructure that the
experiment could become permanent.  That's the meaty stuff that would
really help to move this along.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Craig Schwartz]

Hi Murray,

<<>>

In my capacity as managing director of fTLD Registry Services (fTLD),
registry operator of the .BANK and .INSURANCE TLDs, I believe PSD would
provide invaluable threat intelligence to domain registrants and to TLD
administrators like ourselves for NXDOMAINs. PSD has tremendous value to
specialized TLDs including, but not limited to, .BRANDS, community-based
domains, high-security domains, governments, etc. and as such I believe PSD
should proceed. I’ve previously posted to this list expressing this view
and while fTLD cannot participate in experimentation due to a prohibition
by ICANN, we remain committed to supporting and seeing this work continue.


Sincerely,

Craig


*--*
Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .INSURANCE
Office: +1 202 589 2532
Mobile: +1 202 236 1154
Skype: craig-schwartz
www.fTLD.com








On Mon, Feb 3, 2020 at 1:48 PM Murray S. Kucherawy 
wrote:

> Dave,
>
> On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker  wrote:
>
>> Nothing I've worked on at the IETF with such a label is something I would
>> necessarily stand behind as Internet-scalable.
>>
>> Such as?
>>
>
> RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment
> that never even ran.  Implementations shipped, but its use on the open
> Internet was never detected or reported.  And I had my doubts about the
> scalability of the second DNS check that was added to it, but it didn't
> seem like it could go forward without.
>
> One that wasn't mine: RFC 6210, an experiment to prove how bad something
> can be.
>
>>
>> But I would probably expect something at Informational probably to scale,
>> and anything with "Standard" in it certainly to scale.
>>
>> Laying any general expectation on an IETF Informational RFC would be a
>> mistake, because there is so much variety in their content and intent.
>>
>
> Why would the expectations for Experimental be higher than for
> Informational?  LMTP is Informational, and it certainly needs to succeed.
>
>> So: Can you propose any sort of specific restructuring of the document or
>> the experiment that achieves the same goal as the current version while
>> also resolving your concerns?
>>
>> I'm pretty sure I've raised fundamental concerns about this work and that
>> those concerns have not been addressed.  The simple summary is that the way
>> to restructure this work is to go back to first principles.  But there
>> doesn't seem to be any interest in having that sort of discussion.
>>
> I thought we were having that sort of a discussion right here.
>
> Your position as I recall is that we have no choice but to take all of
> this back to first principles and separate DMARC from the determination of
> Organizational Domain (i.e., make them separate documents) before PSD can
> proceed.  Since that will take months, I've proposed a compromise, because
> I don't think that's strictly necessary to allow the data collection work
> to proceed.  The proposed compromise, then, is to do the work in hand, then
> rip the experiment down and apply whatever we learn from it to standards
> track DMARC, which is the next milestone.  That will include the separation
> of function you proposed, because we agree it's an improvement.  I believe
> the set of likely participants in the experiment are present on the list,
> and it can be made clear to them that they should have no expectation of
> the mechanism it describes surviving past the termination of the
> experiment.  So the path forward here comes down to whether the working
> group achieves consensus on that compromise, or whether the asserted risk
> of the experiment's structure leaking into the permanent deployed base
> warrants shutting it down before it starts.
>
> Now, to the working group as a whole:
>
> The chairs note that we have a duly and properly completed WGLC in hand.
> Still, Dave's concerns have validity, so they need to be considered by the
> working group.  Since we need to do *something*, we are now putting the
> question back to the working group, and we need to see some answers.  The
> chairs will not accept hearsay replies or opinions, or expressions of
> needing this work but not knowing how to engage; you either give your
> feedback on the list or privately to the chairs or Area Directors, or you
> are along for whatever ride results.  Please indicate, as soon as possible,
> where your support lies given the above.  We're not going to let this go
> additional months (probably not even weeks) without progress in some
> direction.
>
> I will also say for the record that we don't find compelling the assertion
> that resources will not be dedicated to the experiment absent a document in
> the RFC Editor queue.  That constraint is fully external to the IETF, and
> it will carry no weight in the decision made here.  It should indeed be
> possible to run an experiment based on a document in any state at all.
> We're entertaining publication not because it must happen, but because 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Ian Levy]

> I believe the set of likely participants in the experiment
> are present on the list, and it can be made clear to
> them that they should have no expectation of the
> mechanism it describes surviving past the termination
> of the experiment.

I believe I represent one of those participants and I’m happy with Murray’s 
caution. Experiments will give us data that helps us make better solutions in 
the future. If those solutions look like the current draft then great. If they 
don’t then we’ll be changing them based on data and experience.

Surely that’s a good outcome for all??

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
i...@ncsc.gov.uk

Staff officer : Tracy, trac...@ncsc.gov.uk or 07468 837625
Assistant : Rose, ros...@ncsc.gov.uk

Pronouns : he/him
(I work stupid hours and weird times – that doesn’t mean you have to. If this 
arrives outside your normal working hours, don’t feel compelled to respond 
immediately!)

From: dmarc  on behalf of Murray S. Kucherawy 

Sent: Monday, February 3, 2020 6:47:45 PM
To: Dave Crocker 
Cc: IETF DMARC WG ; Alexey Melnikov 
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker 
mailto:dcroc...@gmail.com>> wrote:
Nothing I've worked on at the IETF with such a label is something I would 
necessarily stand behind as Internet-scalable.

Such as?

RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment that 
never even ran.  Implementations shipped, but its use on the open Internet was 
never detected or reported.  And I had my doubts about the scalability of the 
second DNS check that was added to it, but it didn't seem like it could go 
forward without.

One that wasn't mine: RFC 6210, an experiment to prove how bad something can be.


But I would probably expect something at Informational probably to scale, and 
anything with "Standard" in it certainly to scale.
Laying any general expectation on an IETF Informational RFC would be a mistake, 
because there is so much variety in their content and intent.

Why would the expectations for Experimental be higher than for Informational?  
LMTP is Informational, and it certainly needs to succeed.
So: Can you propose any sort of specific restructuring of the document or the 
experiment that achieves the same goal as the current version while also 
resolving your concerns?

I'm pretty sure I've raised fundamental concerns about this work and that those 
concerns have not been addressed.  The simple summary is that the way to 
restructure this work is to go back to first principles.  But there doesn't 
seem to be any interest in having that sort of discussion.

I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of this 
back to first principles and separate DMARC from the determination of 
Organizational Domain (i.e., make them separate documents) before PSD can 
proceed.  Since that will take months, I've proposed a compromise, because I 
don't think that's strictly necessary to allow the data collection work to 
proceed.  The proposed compromise, then, is to do the work in hand, then rip 
the experiment down and apply whatever we learn from it to standards track 
DMARC, which is the next milestone.  That will include the separation of 
function you proposed, because we agree it's an improvement.  I believe the set 
of likely participants in the experiment are present on the list, and it can be 
made clear to them that they should have no expectation of the mechanism it 
describes surviving past the termination of the experiment.  So the path 
forward here comes down to whether the working group achieves consensus on that 
compromise, or whether the asserted risk of the experiment's structure leaking 
into the permanent deployed base warrants shutting it down before it starts.

Now, to the working group as a whole:

The chairs note that we have a duly and properly completed WGLC in hand.  
Still, Dave's concerns have validity, so they need to be considered by the 
working group.  Since we need to do *something*, we are now putting the 
question back to the working group, and we need to see some answers.  The 
chairs will not accept hearsay replies or opinions, or expressions of needing 
this work but not knowing how to engage; you either give your feedback on the 
list or privately to the chairs or Area Directors, or you are along for 
whatever ride results.  Please indicate, as soon as possible, where your 
support lies given the above.  We're not going to let this go additional months 
(probably not even weeks) without progress in some direction.

I will also say for the record that we don't find compelling the assertion that 
resources will not be dedicated to the experiment absent a document in the RFC 
Editor queue.  That constraint is fully external to the IETF, and it will carry 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

Dave,

On Fri, Jan 17, 2020 at 8:44 AM Dave Crocker  wrote:

> Nothing I've worked on at the IETF with such a label is something I would
> necessarily stand behind as Internet-scalable.
>
> Such as?
>

RFC 6541 comes to mind.  To the best of my knowledge, it's an experiment
that never even ran.  Implementations shipped, but its use on the open
Internet was never detected or reported.  And I had my doubts about the
scalability of the second DNS check that was added to it, but it didn't
seem like it could go forward without.

One that wasn't mine: RFC 6210, an experiment to prove how bad something
can be.

>
> But I would probably expect something at Informational probably to scale,
> and anything with "Standard" in it certainly to scale.
>
> Laying any general expectation on an IETF Informational RFC would be a
> mistake, because there is so much variety in their content and intent.
>

Why would the expectations for Experimental be higher than for
Informational?  LMTP is Informational, and it certainly needs to succeed.

> So: Can you propose any sort of specific restructuring of the document or
> the experiment that achieves the same goal as the current version while
> also resolving your concerns?
>
> I'm pretty sure I've raised fundamental concerns about this work and that
> those concerns have not been addressed.  The simple summary is that the way
> to restructure this work is to go back to first principles.  But there
> doesn't seem to be any interest in having that sort of discussion.
>
I thought we were having that sort of a discussion right here.

Your position as I recall is that we have no choice but to take all of this
back to first principles and separate DMARC from the determination of
Organizational Domain (i.e., make them separate documents) before PSD can
proceed.  Since that will take months, I've proposed a compromise, because
I don't think that's strictly necessary to allow the data collection work
to proceed.  The proposed compromise, then, is to do the work in hand, then
rip the experiment down and apply whatever we learn from it to standards
track DMARC, which is the next milestone.  That will include the separation
of function you proposed, because we agree it's an improvement.  I believe
the set of likely participants in the experiment are present on the list,
and it can be made clear to them that they should have no expectation of
the mechanism it describes surviving past the termination of the
experiment.  So the path forward here comes down to whether the working
group achieves consensus on that compromise, or whether the asserted risk
of the experiment's structure leaking into the permanent deployed base
warrants shutting it down before it starts.

Now, to the working group as a whole:

The chairs note that we have a duly and properly completed WGLC in hand.
Still, Dave's concerns have validity, so they need to be considered by the
working group.  Since we need to do *something*, we are now putting the
question back to the working group, and we need to see some answers.  The
chairs will not accept hearsay replies or opinions, or expressions of
needing this work but not knowing how to engage; you either give your
feedback on the list or privately to the chairs or Area Directors, or you
are along for whatever ride results.  Please indicate, as soon as possible,
where your support lies given the above.  We're not going to let this go
additional months (probably not even weeks) without progress in some
direction.

I will also say for the record that we don't find compelling the assertion
that resources will not be dedicated to the experiment absent a document in
the RFC Editor queue.  That constraint is fully external to the IETF, and
it will carry no weight in the decision made here.  It should indeed be
possible to run an experiment based on a document in any state at all.
We're entertaining publication not because it must happen, but because that
action (currently) has consensus, and it's our job to act on consensus.

Dave also made an additional observation, that experiments expected to fail
are not generally what the IETF produces.  I would quibble some with that
wording: The working group doesn't expect the experiment to "fail", but
rather expects it to be ephemeral.  Were we to refer to chapter-and-verse,
there's nothing in RFC2026 (which defines "Experimental" as a document
status) that precludes what the working group appears to be trying to do
here.  As for whether the IETF generally should produce an Experimental
document describing something ephemeral, I would claim that a working group
or its chairs are below the pay grade where authoritative claims like those
are made; it's the kind of thing about which the IESG makes proclamations.
Accordingly, I've Cc'd our current Area Director to see what he thinks
might happen if we were to send this up, and give him a chance to provide
guidance in case that's the decision (but we won't wait long for that
either).


> The real 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 1/17/2020 12:06 AM, Murray S. Kucherawy wrote:
On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker > wrote:


The IETF does not typically -- or, as far as I recall, ever -- promote
specifications known not to scale.  (While I think of this concern as
foundational to the IETF, it's a bit odd that nothing like it is 


included in the IETF's "Mission and principles" statement.[1])


I'm not sure that I would reasonably expect anything labeled 
"Experimental" to scale, especially if it were to make very explicit 
claims to the contrary.


As a standalone bit of thinking that sounds reasonable, but it does not 
match my sense of IETF history, nor my sense of application of that 
model in the case of X-.  What you describe makes sense for something 
out of the IRTF, not IETF.


As for IETF history, while there certainly have been IETF Experimental 
RFCs that have failed, I don't recall their being /expected/ to fail.  
(I'm counting inability to scale as failure. If anyone has a different 
view of inability to scale, there needs to be a separate discussion...)


For the latter:  X- was an email header field construct design to make 
an explicit statement that something was /not/ a standard header field. 
I was added to the RFC 822 spec, though I do not remember who first 
suggested it, other than it wasn't me.  I thought it a fine and 
reasonable idea, as did many others.  Note that it was eventually 
deprecated. Because it did not work as intended:  People using X- fields 
came to rely on them, creating defacto standards.


That's the danger with an IETF stream RFC, especially one coming out of 
a working group: Those implementing and using an IETF published 
specification tend to come to rely on continuing to use it.



Nothing I've worked on at the IETF with such a label is something I 
would necessarily stand behind as Internet-scalable.


Such as?


But I would probably expect something at Informational probably to 
scale, and anything with "Standard" in it certainly to scale.


Laying any general expectation on an IETF Informational RFC would be a 
mistake, because there is so much variety in their content and intent.




> Comparing it to the "obs" grammars of days of yore, the PSD proposal
> is much too expensive to become engrained as-is, whereas the old
> grammars were relatively easy to carry forward.

I don't quite grok the reference to "obs", and mostly think of the
introduction of that construct in RFC 2822 as an interesting idea
that,
itself, failed.  (I see it as being instructive on the challenges of
designing for transition from an installed base.)


That was indeed the intended reference.


I don't understand how you see benefit in citing a reasonable idea that 
failed -- obs- did not serve its intended purpose and was in a standards 
track specification: The obs- rules both weren't deprecated from later 
work and continue to be relied on. If anything, it validates my concern 
about entrenched use.




All sorts of experimental specs fail.  But they aren't /expected/ to
fail.  And they aren't expected to be unable to scale.


This one isn't expected to fail,


If it is known that it can't scale, that's inherent failure for IETF work.


but its mechanism is not (as far as I can tell) intended to be 
permanent, nor could it become so.



You keep making statements that warrant this as IRTF work, not IETF work.


Since one of your core assertions is that the IETF shouldn't publish 
things like this, I have suggested that, as a compromise, interested 
parties proceed with the experiment using the document in its draft 
state.



Sounds like a fine idea, to me.


Unfortunately I am also regularly reminded that there are 
organizations wishing to participate in this experiment and related 
work but which simply cannot, by reason of policy, do so without this 
document being first approved for publication.



That should raise some very bold, very large red flags about publishing 
this as an IETF stream RFC.



So: Can you propose any sort of specific restructuring of the document 
or the experiment that achieves the same goal as the current version 
while also resolving your concerns?



I'm pretty sure I've raised fundamental concerns about this work and 
that those concerns have not been addressed.  The simple summary is that 
the way to restructure this work is to go back to first principles.  But 
there doesn't seem to be any interest in having that sort of discussion.





The real challenge for most IETF specs is community engagement, not
engineering adequacy.


Interestingly I would claim we have clearly achieved the former here, 
though obviously not the latter.


My sense is -- as has become common in the IETF -- an extremely small 
core of folk interesting in promoting this work, rather than extensive 
community interest.



Extensive community interest is what generates serious demonstration of 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker  wrote:

> The IETF does not typically -- or, as far as I recall, ever -- promote
> specifications known not to scale.  (While I think of this concern as
> foundational to the IETF, it's a bit odd that nothing like it is

included in the IETF's "Mission and principles" statement.[1])
>

I'm not sure that I would reasonably expect anything labeled "Experimental"
to scale, especially if it were to make very explicit claims to the
contrary.  Nothing I've worked on at the IETF with such a label is
something I would necessarily stand behind as Internet-scalable.  But I
would probably expect something at Informational probably to scale, and
anything with "Standard" in it certainly to scale.


> > Comparing it to the "obs" grammars of days of yore, the PSD proposal
> > is much too expensive to become engrained as-is, whereas the old
> > grammars were relatively easy to carry forward.
>
> I don't quite grok the reference to "obs", and mostly think of the
> introduction of that construct in RFC 2822 as an interesting idea that,
> itself, failed.  (I see it as being instructive on the challenges of
> designing for transition from an installed base.)
>

That was indeed the intended reference.

All sorts of experimental specs fail.  But they aren't /expected/ to
> fail.  And they aren't expected to be unable to scale.
>

This one isn't expected to fail, but its mechanism is not (as far as I can
tell) intended to be permanent, nor could it become so.  In terms of
meeting its stated goal, we don't know the outcome yet.  We have a guess,
but we need data to confirm it, and everyone participating needs to agree
on how to participate.  That seems to me to be what an Experimental
specification is for.  The non-scalable component is part of the means by
which participants agree on the operation of the test itself.

Mostly, IETF/Experimental is used to check whether a spec is
> operationally viable -- it's expected to be but the community isn't
> quite sure -- or to check for community interest.  The latter
> constitutes market research, not technical research.
>

I would claim it's clear that this is the former.  We're trying to assess
whether this extended logic is a reasonable change to the accuracy of
DMARC.  Some of the supporting mechanism added in the experiment is
ancillary to that goal, and is discardable.  Nothing to do with market
research.

A pointedly friendly reading of the relevant Guidelines might seem to
> support the publication under IETF/Experimental being proposed here, but
> a more critical one probably doesn't and I think that this use of the
> label doesn't really match common practice.[2]
>

The status chosen most closely reflects the intent and quality of the work,
certainly as compared to something aiming for the standards track.  And
there's consensus to move forward, or was when WGLC ended.  Quite a bit of
time has now passed since then and we are no closer to getting the answers
the working group needs to make progress on the core issues it's facing.
Rightly, there's now a lot of grumbling going on.

Since one of your core assertions is that the IETF shouldn't publish things
like this, I have suggested that, as a compromise, interested parties
proceed with the experiment using the document in its draft state.
Unfortunately I am also regularly reminded that there are organizations
wishing to participate in this experiment and related work but which simply
cannot, by reason of policy, do so without this document being first
approved for publication.  I personally find that position peculiar -- many
things from DKIM up to QUIC are implemented experimentally by very large
operators during development, without an approved document -- and it's not
really the IETF's responsibility to acquiesce, but nevertheless it results
in some urgency for this community to find a way forward here.

So: Can you propose any sort of specific restructuring of the document or
the experiment that achieves the same goal as the current version while
also resolving your concerns?

The real challenge for most IETF specs is community engagement, not
> engineering adequacy.
>

Interestingly I would claim we have clearly achieved the former here,
though obviously not the latter.

Also, any suggestion to rely on a published list ignores the history of
> problems with such lists, as well as at least requiring a careful
> specification for the list and a basis for believing it will be
> maintained well.
>

The list, as I understand its use in the specification, amounts to a list
of who's participating in the experiment.  When the experiment is done, the
list goes away, and the concerns of its maintenance would go with it.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Ian Levy]

  *   Maybe no one would be willing to go with np=reject without being able to 
confirm there's no good mail doing that.

Exactly this. As we’ve pushed DMARC across gov.uk we’ve found all sorts of 
interesting things in the reporting we get.

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
i...@ncsc.gov.uk<mailto:i...@ncsc.gov.uk>

Staff Officer : Kate Atkins, kat...@ncsc.gov.uk<mailto:kat...@ncsc.gov.uk>
Pronouns : he/him

(I work stupid hours and weird times – that doesn’t mean you have to. If this 
arrives outside your normal working hours, don’t feel compelled to respond 
immediately!)

From: dmarc  On Behalf Of Brandon Long
Sent: 12 December 2019 23:38
To: Kurt Andersen (b) 
Cc: IETF DMARC WG ; Scott Kitterman 
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd



On Wed, Dec 11, 2019 at 7:45 AM Kurt Andersen (b) 
mailto:kb...@drkurt.com>> wrote:
On Tue, Dec 10, 2019 at 2:13 PM Brandon Long 
mailto:bl...@google.com>> wrote:

On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b) 
mailto:kb...@drkurt.com>> wrote:
On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman 
mailto:skl...@kitterman.com>> wrote:
On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:

> I'm sure I probably missed this, but couldn't we avoid this question by just 
> mandating no reporting for non-existing organizational domains?  Is that a 
> non-starter?

It's one of the use cases we are trying to cover.  I don't know if that makes 
it a non-starter.

Unless I'm misunderstanding Brandon's suggestion, it seems like you (Brandon) 
are asking if doing no reporting on missing org domains solves the scalability 
problem. *Getting* reports for missing org domains is the main purpose of the 
PSD proposal so it would render the purpose moot.

Hmm, I guess I don't see it that way.

Preventing phishing attacks from 
nonexistent.gov.uk<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnonexistent.gov.uk=02%7C01%7Cian.levy%40ncsc.gov.uk%7C522306c0a8a84aca4a7308d77f5c5d4b%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637117906987236215=Be5QRL1NweewdLl2E6UbuliKRWqAEZb0KPS7YW8nn5E%3D=0>,
 insomuch as DMARC can be used for such, seems way more important than the 
reporting.  Obviously, getting to p=reject without reporting is more 
challenging.  You can certainly have policy without reporting.

While it is very true that receivers may implement validation and possibly 
enforcement without reporting, we could solve the use case of phishing from 
missing org-level domains by the same approach that we can solve it from any 
missing domain - just don't accept mail from such bogus sources. That does not 
help the overseers of a domain realm (org-1, aka LPSD) to tackle takedowns or 
public awareness campaigns against such abuse though.

I mean, that was also true for all DMARC, the point was the owner was asking 
everyone to do that.  If you're saying we should have a different system for 
trying to get everyone to not accept messages from non-existent domains... ok, 
but I'm not sure where that would come from.

Maybe no one would be willing to go with np=reject without being able to 
confirm there's no good mail doing that.  That seems more likely to be true for 
existing large scale branded domains (which I guess 
gov.uk<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgov.uk=02%7C01%7Cian.levy%40ncsc.gov.uk%7C522306c0a8a84aca4a7308d77f5c5d4b%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637117906987246211=ADl8m4tEnSW2tzuk6dWIVU7sx8Y%2BRUQ%2FS1cffxjsuOU%3D=0>
 falls into), whereas setting that policy for the newer branded domains 
(.google) and multi-organizational (.bank) seems fine without reporting.

Brandon
This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Tue, Dec 10, 2019 at 2:13 PM Brandon Long  wrote:

>
> On Mon, Dec 9, 2019 at 6:27 PM Kurt Andersen (b)  wrote:
>
>> On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman 
>> wrote:
>>
>>> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
>>>
>>> > I'm sure I probably missed this, but couldn't we avoid this question
>>> by just mandating no reporting for non-existing organizational domains?  Is
>>> that a non-starter?
>>>
>>> It's one of the use cases we are trying to cover.  I don't know if that
>>> makes it a non-starter.
>>>
>>
>> Unless I'm misunderstanding Brandon's suggestion, it seems like you
>> (Brandon) are asking if doing no reporting on missing org domains solves
>> the scalability problem. *Getting* reports for missing org domains is the
>> main purpose of the PSD proposal so it would render the purpose moot.
>>
>
> Hmm, I guess I don't see it that way.
>
> Preventing phishing attacks from nonexistent.gov.uk, insomuch as DMARC
> can be used for such, seems way more important than the reporting.
> Obviously, getting to p=reject without reporting is more challenging.  You
> can certainly have policy without reporting.
>

While it is very true that receivers may implement validation and possibly
enforcement without reporting, we could solve the use case of phishing from
missing org-level domains by the same approach that we can solve it from
any missing domain - just don't accept mail from such bogus sources. That
does not help the overseers of a domain realm (org-1, aka LPSD) to tackle
takedowns or public awareness campaigns against such abuse though.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 12/9/2019 4:41 PM, Brandon Long wrote:
I mean, the PSL is already a maintained object.  Is this new detail 
something
that has different ownership/privacy/etc concerns than the existing 
details?


So, ummm, you want to replace one problematic operation with another?

On the consumption side, I've only heard comments that the PSL has 
problems.  On the provision side, I've heard vigorous and repeated 
claims of overwork of the the volunteer force, sufficient that there is 
no bandwidth for dealing with revision/replacement efforts.


I'm sure I probably missed this, but couldn't we avoid this question 
by just mandating
no reporting for non-existing organizational domains?  Is that a 
non-starter?


Without commenting on the merits of that suggesting, I'll offer that it 
is an example of why this spec is -- at its very best -- still 
incomplete, or at least the thinking about how it will get used is 
incomplete. (if workable at scale.)


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Dec 9, 2019 at 4:54 PM Scott Kitterman  wrote:

> On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
>
> > I'm sure I probably missed this, but couldn't we avoid this question by
> just mandating no reporting for non-existing organizational domains?  Is
> that a non-starter?
>
> It's one of the use cases we are trying to cover.  I don't know if that
> makes it a non-starter.
>

Unless I'm misunderstanding Brandon's suggestion, it seems like you
(Brandon) are asking if doing no reporting on missing org domains solves
the scalability problem. *Getting* reports for missing org domains is the
main purpose of the PSD proposal so it would render the purpose moot.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Monday, December 9, 2019 7:41:27 PM EST Brandon Long wrote:
> On Mon, Dec 9, 2019 at 8:44 AM Dave Crocker  wrote:
> > On 12/7/2019 12:11 PM, Scott Kitterman wrote:
> > >> Remind me again the the additional work is that might be too much?
> > >> Isn't it just another DNS lookup for the org domain -1... of which
> > >> there are maybe a couple thousand and easily cacheable?
> > >> 
> > >> This seems way less than say the additional work for ARC.
> > > 
> > > It's slightly more.  There's also a check to see if a LPSD (org -1)
> > > is a PSD > DMARC participant.  Exactly how to document that is the major
> > > unresolved question that we should evaluate experimentally.  It might
> > > be one of three
> > 
> > > things:
> > First, this sort of exchange highlights the need for considering basic
> > operational issues carefully and before publication.
> > 
> > Second, it highlights the challenges of doing that in a way that isn't
> > myopic.  What is easy/cheap for highly motivated, expert, well-resourced
> > participants might not be all that easy or cheap for the larger Internet
> > community.  (This is the operational side of scalability.)
> 
> Ah, re-reading the spec, I'd guess we're talking about the scalability of
> psddmarc.org.

It's only relevant for the purposes of the experiment.  Part of coming to 
consensus on the longer term plan would be making sure we have a scalable 
approach for determining PSD DMARC participants.

> [snip]
> 
> > Also, any suggestion to rely on a published list ignores the history of
> > problems with such lists, as well as at least requiring a careful
> > specification for the list and a basis for believing it will be
> > maintained well.
> 
> I mean, the PSL is already a maintained object.  Is this new detail
> something
> that has different ownership/privacy/etc concerns than the existing details?
> 
> I'm sure I probably missed this, but couldn't we avoid this question by
> just mandating
> no reporting for non-existing organizational domains?  Is that a
> non-starter?

It's one of the use cases we are trying to cover.  I don't know if that makes 
it a non-starter.

Scott K



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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 12/3/2019 11:42 PM, Murray S. Kucherawy wrote:

>I think there's a healthy

dose of feeling that the experiment as it's currently designed
couldn't possibly scale to "the entire domain namespace" and/or "all
servers on the Internet", so in that sense from where I sit there's a
built in safeguard against this becoming a permanent wart.  Rather,
it's primed as a possibly useful data collection exercise.

The IETF does not typically -- or, as far as I recall, ever -- promote
specifications known not to scale.  (While I think of this concern as
foundational to the IETF, it's a bit odd that nothing like it is
included in the IETF's "Mission and principles" statement.[1])

Perhaps even more importantly, I don't recall the IETF ever promoting a
specification that was /expected/ to be thrown away, in favor of then
doing the 'real' specification.  I do believe such work is sometimes
done in the I/R/TF.  Note that, for example, this view of throwing a 
spec away and starting over is quite different from wanting to let the 
market choose between competing specs.


Also, viewing this scaling limitation as a safeguard has recently and
notably proved wrong.  cf, DMARC.  It was designed for a very limited
scenario. Then it got re-purposed in the field, by some operators having
significant leverage.

Worse, publishing a spec always carries the likelihood of operational
momentum. If the spec has real utility, it tends to get implemented and
used.  That creates pressure against replacing it, because that's
expensive and possibly disruptive.



Comparing it to the "obs" grammars of days of yore, the PSD proposal
is much too expensive to become engrained as-is, whereas the old
grammars were relatively easy to carry forward.


I don't quite grok the reference to "obs", and mostly think of the
introduction of that construct in RFC 2822 as an interesting idea that,
itself, failed.  (I see it as being instructive on the challenges of
designing for transition from an installed base.)


Perhaps there are exampls of IETF experiments that have permitted 
entirely starting over, but mostly those only happen when there is a 
complete failure, and those typically are called experiments.


ATPS (RFC 6541) was Experimental, and it flatly failed.  For a more 
visible example, Sender ID was Experimental, and I would argue it did

 too.  Should they not have been?


All sorts of experimental specs fail.  But they aren't /expected/ to
fail.  And they aren't expected to be unable to scale.

Mostly, IETF/Experimental is used to check whether a spec is
operationally viable -- it's expected to be but the community isn't
quite sure -- or to check for community interest.  The latter
constitutes market research, not technical research.

A pointedly friendly reading of the relevant Guidelines might seem to
support the publication under IETF/Experimental being proposed here, but
a more critical one probably doesn't and I think that this use of the
label doesn't really match common practice.[2]




On 12/7/2019 12:11 PM, Scott Kitterman wrote:

Remind me again the the additional work is that might be too much?
Isn't it just another DNS lookup for the org domain -1... of which
there are maybe a couple thousand and easily cacheable?

This seems way less than say the additional work for ARC.

It's slightly more.  There's also a check to see if a LPSD (org -1)
is a PSD > DMARC participant.  Exactly how to document that is the major
unresolved question that we should evaluate experimentally.  It might
be one of three
things:


First, this sort of exchange highlights the need for considering basic 
operational issues carefully and before publication.


Second, it highlights the challenges of doing that in a way that isn't 
myopic.  What is easy/cheap for highly motivated, expert, well-resourced 
participants might not be all that easy or cheap for the larger Internet 
community.  (This is the operational side of scalability.)


The real challenge for most IETF specs is community engagement, not 
engineering adequacy.



Some additional thoughts:

The example that Tim added, of RFC 7706, is of an efficiency mechanism, 
not a basic and required addition to the architecture. The difference is 
important here.


Also, any suggestion to rely on a published list ignores the history of 
problems with such lists, as well as at least requiring a careful 
specification for the list and a basis for believing it will be 
maintained well.



d/


[1] Mission and principles

[2] https://ietf.org/standards/process/informational-vs-experimental/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[John R Levine]

(just a fan of
https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt)


Don't miss https://github.com/jrlevine/bound

I found and fixed a bunch of bugs in the spec when I implemented it.  Who 
knew that could happen?




On Sun, Dec 8, 2019 at 4:58 PM John Levine  wrote:


In article  you write:

So we could decide on doing a combinatory of #3 and #1, with the right
mechanisms.


Publishing a list of PSD superdomains in the DNS is pretty trivial
using my dbound scheme, and should typically find out whether any name
needs a PSD check with one DNS query.  The total zone for the PSL is
under 10K records, so doing a local mirror should be easy, too.

R's,
John





Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Tim Wicinski]

+1

Tim
(just a fan of
https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt)

On Sun, Dec 8, 2019 at 4:58 PM John Levine  wrote:

> In article  q...@mail.gmail.com> you write:
> >So we could decide on doing a combinatory of #3 and #1, with the right
> >mechanisms.
>
> Publishing a list of PSD superdomains in the DNS is pretty trivial
> using my dbound scheme, and should typically find out whether any name
> needs a PSD check with one DNS query.  The total zone for the PSL is
> under 10K records, so doing a local mirror should be easy, too.
>
> R's,
> John
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[John Levine]

In article 
 you 
write:
>So we could decide on doing a combinatory of #3 and #1, with the right
>mechanisms.

Publishing a list of PSD superdomains in the DNS is pretty trivial
using my dbound scheme, and should typically find out whether any name
needs a PSD check with one DNS query.  The total zone for the PSL is
under 10K records, so doing a local mirror should be easy, too.

R's,
John

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Wednesday, December 4, 2019 8:04:00 PM EST Brandon Long wrote:
> On Wed, Dec 4, 2019 at 10:01 AM Kurt Andersen (b)  wrote:
> > On Wed, Dec 4, 2019 at 2:39 AM Alessandro Vesely  wrote:
> >> > Rather, it's primed as a possibly useful data collection exercise.
> >> 
> >> Kurt also talked about reporting some findings.  I'm embarrassed, I have
> >> no
> >> idea what I, as a receiver, should report.  What data should I, and other
> >> receivers collect?
> > 
> > I was thinking of something along the line of what was assembled for RFC
> > 6686. In this case it would be something like the quantity of messages
> > which were assessed against the LPSD record and their disposition compared
> > to the number of messages dispositioned at the org level. Something to
> > answer Dave's concern about "too much additional work" for not enough
> > benefit.
> 
> Remind me again the the additional work is that might be too much?  Isn't
> it just another DNS lookup for the org domain -1... of which there are
> maybe a couple thousand and easily cacheable?
> 
> This seems way less than say the additional work for ARC.

It's slightly more.  There's also a check to see if a LPSD (org -1) is a PSD 
DMARC participant.  Exactly how to document that is the major unresolved 
question that we should evaluate experimentally.  It might be one of three 
things:

1.  A registry that is occasionally updated and consumed locally.
2.  A DNS RBL type service lookup.
3.  An exended PSL.

Options 2 and 3 both have a second additional lookup.  Personally, I like 
option 1, but there's no consensus about this.  There are working versions of 
all three available from psddmarc.org for testing.

Scott K


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Wed, Dec 4, 2019 at 2:39 AM Alessandro Vesely  wrote:

>
> > Rather, it's primed as a possibly useful data collection exercise.
>
> Kurt also talked about reporting some findings.  I'm embarrassed, I have no
> idea what I, as a receiver, should report.  What data should I, and other
> receivers collect?
>

I was thinking of something along the line of what was assembled for RFC
6686. In this case it would be something like the quantity of messages
which were assessed against the LPSD record and their disposition compared
to the number of messages dispositioned at the org level. Something to
answer Dave's concern about "too much additional work" for not enough
benefit.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Wed 04/Dec/2019 08:42:09 +0100 Murray S. Kucherawy wrote:
> On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker  > wrote:
> 
>>> * add text to the PSD draft making it clear that what it's describing is
>>>   an experiment whose outcome will be taken only as feedback to the
>>>   revision of the standard (i.e., this is not intended to be the final form
>>>   of anything), and it is not intended to be deployed outside of the
>>>   experiment's participants;
>> 
>>  Forgive me, but while everyone involved in this has extensive experience
>>  and is trying to solve a real and serious issue, this is an astonishingly
>>  naive view.
> 
> I don't think it's based entirely on naivety.  I think there's a healthy dose
> of feeling that the experiment as it's currently designed couldn't possibly
> scale to "the entire domain namespace" and/or "all servers on the Internet", 
> so
> in that sense from where I sit there's a built in safeguard against this
> becoming a permanent wart.


After installing the DKIM/DMARC filter that implements PSD, I can say that the
impact is unnoticeable.  I didn't carry out precise measurements, I just didn't
notice any delay.  Perhaps because I don't get so much mail from gov.uk, but I
don't think I could reliably measure a positive delay even if I were a strict
correspondent of Boris.


> Rather, it's primed as a possibly useful data collection exercise.

Kurt also talked about reporting some findings.  I'm embarrassed, I have no
idea what I, as a receiver, should report.  What data should I, and other
receivers collect?

IMHO, the experiment should be conceived as having it run by as many receivers
as possible, so as to have a noticeable effect on senders.  They can collect
aggregate reports and make a comparison.


Best
Ale
-- 


















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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker  wrote:

>
> * add text to the PSD draft making it clear that what it's describing is
> an experiment whose outcome will be taken only as feedback to the revision
> of the standard (i.e., this is not intended to be the final form of
> anything), and it is not intended to be deployed outside of the
> experiment's participants;
>
> Forgive me, but while everyone involved in this has extensive experience
> and is trying to solve a real and serious issue, this is an astonishingly
> naive view.
>
I don't think it's based entirely on naivety.  I think there's a healthy
dose of feeling that the experiment as it's currently designed couldn't
possibly scale to "the entire domain namespace" and/or "all servers on the
Internet", so in that sense from where I sit there's a built in safeguard
against this becoming a permanent wart.  Rather, it's primed as a possibly
useful data collection exercise.

Comparing it to the "obs" grammars of days of yore, the PSD proposal is
much too expensive to become engrained as-is, whereas the old grammars were
relatively easy to carry forward.

> Perhaps there are exampls of IETF experiments that have permitted entirely
> starting over, but mostly those only happen when there is a complete
> failure, and those typically are called experiments.
>
ATPS (RFC 6541) was Experimental, and it flatly failed.  For a more visible
example, Sender ID was Experimental, and I would argue it did too.  Should
they not have been?

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

I think that if we could get a core set of receivers who would be willing
to test this and report on their findings in 3-6 months, that would be
great.

--Kurt

On Tue, Dec 3, 2019 at 12:40 PM Murray S. Kucherawy 
wrote:

> On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker  wrote:
>
>> On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
>>
>> * add text to the PSD draft making it clear that what it's describing is
>> an experiment whose outcome will be taken only as feedback to the revision
>> of the standard (i.e., this is not intended to be the final form of
>> anything), and it is not intended to be deployed outside of the
>> experiment's participants;
>>
>> Forgive me, but while everyone involved in this has extensive experience
>> and is trying to solve a real and serious issue, this is an astonishingly
>> naive view.
>>
>> The IETF does standards, not experiments.  Not /real/ experiments.  What
>> it calls an experiment mostly serves as market testing, with a smidgen of
>> engineering tuning later.  For the most part, IETF experiments produce an
>> accepted/failed/needs-small-revisions range of results.  What it does /not/
>> produce is results along the lines of "that was interesting, now let's
>> start fresh and do the real standard."
>>
>> Perhaps there are exampls of IETF experiments that have permitted
>> entirely starting over, but mostly those only happen when there is a
>> complete failure, and those typically are called experiments.
>>
> Should I take this as advocating for running the experiment without
> publishing an RFC about it?  Or do you have another suggestion?
>
> I don't think the idea of going back and fixing the DMARC-PSL separation
> issue first is tenable given how long it will take, compared to the urgent
> need to get some data here.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Mon, Nov 11, 2019 at 2:21 PM Dave Crocker  wrote:

> On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
>
> * add text to the PSD draft making it clear that what it's describing is
> an experiment whose outcome will be taken only as feedback to the revision
> of the standard (i.e., this is not intended to be the final form of
> anything), and it is not intended to be deployed outside of the
> experiment's participants;
>
> Forgive me, but while everyone involved in this has extensive experience
> and is trying to solve a real and serious issue, this is an astonishingly
> naive view.
>
> The IETF does standards, not experiments.  Not /real/ experiments.  What
> it calls an experiment mostly serves as market testing, with a smidgen of
> engineering tuning later.  For the most part, IETF experiments produce an
> accepted/failed/needs-small-revisions range of results.  What it does /not/
> produce is results along the lines of "that was interesting, now let's
> start fresh and do the real standard."
>
> Perhaps there are exampls of IETF experiments that have permitted entirely
> starting over, but mostly those only happen when there is a complete
> failure, and those typically are called experiments.
>
Should I take this as advocating for running the experiment without
publishing an RFC about it?  Or do you have another suggestion?

I don't think the idea of going back and fixing the DMARC-PSL separation
issue first is tenable given how long it will take, compared to the urgent
need to get some data here.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Ian Levy]

> Let me pinpoint that the hack you talk about is the use of wildcards, which 
> Scott's draft tries to fix with the np= tag.  That's a protocol issue.

Fair point. I was only trying to make sure that people don’t take wildcards as 
a long term solution to this problem. In our experience, they're not. 

> At a PSO level, someone decided that gov.uk can publish TXT records which may 
> affect all of the downward tree --solved.  

That was me. Still don't agree that the problem is 'solved', but I may just be 
being a pedant :-).

> The bank PSO cannot do that, and we (the WG) look forward to ICANN allowing 
> it --not yet solved.  

Agreed. 

> I hope I've now clarified what I mean by "ICANN problem".

Yes, thanks. I think we can, as the WG, do something - and that's to make known 
to ICANN the problem we believe exists and how their current policy could be 
amended (safely) to help fix it. We'll certainly do that, but I know our voice 
is not strong. Consistent messaging from people on this group would help, I 
believe. 

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
i...@ncsc.gov.uk

Staff Officer : Kate Atkins, kat...@ncsc.gov.uk

(I work stupid hours and weird times – that doesn’t mean you have to. If this 
arrives outside your normal working hours, don’t feel compelled to respond 
immediately!)

-Original Message-
From: dmarc  On Behalf Of Alessandro Vesely
Sent: 12 November 2019 08:17
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Tue 12/Nov/2019 07:59:09 +0100 Ian Levy wrote:
>> while _dmarc.gov.uk returns a valid record. The latter is a Nominet, 
>> already solved problem, AFAICS.>
> I can speak authoritatively about this. What we’ve got is an evil, 
> hacky kludge that has some weird side effects (since we respond to 
> *any* non existent sub domain, not just DMARC and SPF related ones). 
> It’s just about passable as an interim, but we believe we need a 
> better, targeted solution along the lines of Scott’s draft.

Thank you for chiming in.  Let me pinpoint that the hack you talk about is the 
use of wildcards, which Scott's draft tries to fix with the np= tag.  That's a 
protocol issue.

At a PSO level, someone decided that gov.uk can publish TXT records which may 
affect all of the downward tree --solved.  The bank PSO cannot do that, and we 
(the WG) look forward to ICANN allowing it --not yet solved.  The com PSO 
cannot do it either, but I'd guess lots of people trust that ICANN will never 
allow it.

I hope I've now clarified what I mean by "ICANN problem".  Scott's draft cannot 
solve it, albeit it nearly touches on the point at the end of the intro.  It is 
not a protocol problem.  It involves PSO-registrants agreements, and ICANN 
managing that stuff.  There is not much we (the WG) can do, except hoping that 
ICANN may consider protocol factors when making decisions.  As an Internet 
user, I'd welcome diversity among TLDs, as numerousness without diversity 
becomes just annoying.


Best
Ale
--


















___
dmarc mailing list
dmarc@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarcdata=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cf21cf2f2ad5f40c6740208d76748ae44%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637091434175522175sdata=EZCj0S7gpioXC1UWsJ%2B8wsU8D1%2FPdtA2FZGBn84vj%2BQ%3Dreserved=0
This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Tue 12/Nov/2019 07:59:09 +0100 Ian Levy wrote:
>> while _dmarc.gov.uk returns a valid record. The latter is a Nominet,
>> already solved problem, AFAICS.>
> I can speak authoritatively about this. What we’ve got is an evil, hacky
> kludge that has some weird side effects (since we respond to *any* non
> existent sub domain, not just DMARC and SPF related ones). It’s just about
> passable as an interim, but we believe we need a better, targeted solution
> along the lines of Scott’s draft.

Thank you for chiming in.  Let me pinpoint that the hack you talk about is the
use of wildcards, which Scott's draft tries to fix with the np= tag.  That's a
protocol issue.

At a PSO level, someone decided that gov.uk can publish TXT records which may
affect all of the downward tree --solved.  The bank PSO cannot do that, and we
(the WG) look forward to ICANN allowing it --not yet solved.  The com PSO
cannot do it either, but I'd guess lots of people trust that ICANN will never
allow it.

I hope I've now clarified what I mean by "ICANN problem".  Scott's draft cannot
solve it, albeit it nearly touches on the point at the end of the intro.  It is
not a protocol problem.  It involves PSO-registrants agreements, and ICANN
managing that stuff.  There is not much we (the WG) can do, except hoping that
ICANN may consider protocol factors when making decisions.  As an Internet
user, I'd welcome diversity among TLDs, as numerousness without diversity
becomes just annoying.


Best
Ale
-- 


















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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Ian Levy]

> while _dmarc.gov.uk returns a valid record. The
> latter is a Nominet, already solved problem, AFAICS.

I can speak authoritatively about this. What we’ve got is an evil, hacky kludge 
that has some weird side effects (since we respond to *any* non existent sub 
domain, not just DMARC and SPF related ones). It’s just about passable as an 
interim, but we believe we need a better, targeted solution along the lines of 
Scott’s draft.

Ta.

I.

—
Dr Ian Levy
Technical Director
National Cyber Security Centre
i...@ncsc.gov.uk

From: dmarc  on behalf of Alessandro Vesely 

Sent: Monday, November 11, 2019 5:50:30 PM
To: dmarc@ietf.org 
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
>
> I don't think that it is fair to say that anyone who refers to the org domain
> concept as cited in the DMARC spec is necessarily invoking the PSL.


Agreed.  The PSL just happens to be the only valid tool to do that.

For various reasons, large organizations administer many apparently unrelated
domains.  For example, _dmarc.youtube.com has a rua mailto ending in
@google.com.  We cannot infer an OD from that, but I think the concept is clear.


> I do have a problem with the conflation of the org domain with a
> super-organizational "realm" (?) that may impose conditions upon organizations
> that fall within their jurisdictional purview. My main concerns are with the
> potential usurpation of the org domain's policy declaration rights. "Moving"
> the org domain up one level disenfranchises the organizations and that is the
> wrong thing to do IMO.


The I-D definitions are clear enough.  Section 2.5, in particular, prevents the
conflation neatly.


> As to the proposed "let's run this as an experiment pending DMARCbis", I don't
> see how that satisfies Dave's concern about creating new work for receivers in
> order to help a small set of domain (realm) owners. I'm not opposed to it, but
> I just don't see how this solves the issue.


Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt returns
an empty NOERROR response, while _dmarc.gov.uk returns a valid record.  The
latter is a Nominet, already solved problem, AFAICS.


Best
Ale
--














___
dmarc mailing list
dmarc@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarcdata=02%7C01%7Cian.levy%40ncsc.gov..uk%7C63443737a62a47a65f1008d766cfae3a%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637090914473667320sdata=cOeg7QPSBP0Fzldb8a0RE3ZqsIrBmVG%2B4B2HOrCopaQ%3Dreserved=0
This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 12:43 PM Alessandro Vesely  wrote:

>
> about the need for each OD to opt out by defining its own DMARC record,
> lest
> have reports delivered to the realm.  In the latter sense, Nominet solved
> the
> problem of what rights has gov.uk on domains below it.
>

Requiring "trick" authoritative name servers at the realm level is a/the
solution?!? If so, let's just drop all this I-D noise and get it all done.
That would also solve .bank's problem because they would not have to
"publish" any records contravening ICANN's requirements. They would only
have to "serve" them as responses.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[John Levine]

In article <79b1cbe6-8a53-9157-63de-210fd2bad...@dcrocker.net> you write:
>This goes to the essential challenge of a proposal like PSD.  It 
>embodies a particular model, in the absence of clarity about the model 
>or broad-based discussion of its appropriateness.  (Note, for example, 
>that my review offered some discussion of that sort but got no comment 
>on that discussion.)
>
>In effect, it creates a strategic solution -- that is, a long-lived and 
>embedded mechanism -- without a clear and broad understanding of the 
>organizational space it is working in.

I've been talking to some of the PSL people, and they seem really
stuck.  They know they don't have a way to describe vanity
single-registrant TLDs, and I don't even want to suggest that they
might want to describe something like PSD, with a super-authority
above a suffix boundary.

R's,
John

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[John Levine]

In article  
you write:
>https://datatracker.ietf.org/doc/draft-brotman-rdbd/
>
>which defines a mechanism where two domains can state they are related, or
>not related via DNS records.
>What one wishes to use this information is left to them.
>
>It would be great to get y'all giving feedback

If it's useful at all, which I don't think it is, it's definitely not
useful for PSD since it's intended to describe cross-tree
relationships, not the vertical ones that the PSL identifies and that
PSD needs.

This proposal also invents yet another signature scheme, presumably
for the benefit of people who don't think DNSSEC will ever work, which
is strange since the lead author works for Comcast who have what is
probably the world's biggest set resolvers that validate and use
DNSSEC and DANE.

R's,
John

PS: It's not that I think there are no cross-tree relationships to
describe, it's that we know from Andrew Sullivan's failed SOPA
proposal that doing it one label at a time rather than subtree
to subtree isn't viable.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 11/11/2019 2:21 PM, Dave Crocker wrote:

and those typically are called experiments.


/not/ called.


(sorry)


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 11/11/2019 7:46 AM, Kurt Andersen (b) wrote:
I do have a problem with the conflation of the org domain with a 
super-organizational "realm" (?) that may impose conditions upon 
organizations that fall within their jurisdictional purview.



This goes to the essential challenge of a proposal like PSD.  It 
embodies a particular model, in the absence of clarity about the model 
or broad-based discussion of its appropriateness.  (Note, for example, 
that my review offered some discussion of that sort but got no comment 
on that discussion.)


In effect, it creates a strategic solution -- that is, a long-lived and 
embedded mechanism -- without a clear and broad understanding of the 
organizational space it is working in.



On 11/10/2019 11:34 PM, Murray S. Kucherawy wrote:
* add text to the PSD draft making it clear that what it's describing 
is an experiment whose outcome will be taken only as feedback to the 
revision of the standard (i.e., this is not intended to be the final 
form of anything), and it is not intended to be deployed outside of 
the experiment's participants;



Forgive me, but while everyone involved in this has extensive experience 
and is trying to solve a real and serious issue, this is an 
astonishingly naive view.


The IETF does standards, not experiments.  Not /real/ experiments.  What 
it calls an experiment mostly serves as market testing, with a smidgen 
of engineering tuning later.  For the most part, IETF experiments 
produce an accepted/failed/needs-small-revisions range of results.  What 
it does /not/ produce is results along the lines of "that was 
interesting, now let's start fresh and do the real standard."


Perhaps there are exampls of IETF experiments that have permitted 
entirely starting over, but mostly those only happen when there is a 
complete failure, and those typically are called experiments.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Tim Wicinski]

>
> If it were possible to infer OD from some kind of DNS record (or from RDAP
> responses, for another way) then we'd have a tool alternative to the PSL.
> That
> proves that the concept of OD is independent of the PSL, doesn'it?
>

Over in DNSOP we're been working with the authors on this Related Domains
draft

https://datatracker.ietf.org/doc/draft-brotman-rdbd/

which defines a mechanism where two domains can state they are related, or
not related via DNS records.
What one wishes to use this information is left to them.

It would be great to get y'all giving feedback

Tim


On Mon, Nov 11, 2019 at 3:43 PM Alessandro Vesely  wrote:

> On Mon 11/Nov/2019 19:31:52 +0100 Kurt Andersen (b) wrote:
> > On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely 
> wrote:
> >
> >> For various reasons, large organizations administer many apparently
> >> unrelated domains.  For example, _dmarc.youtube.com has a rua mailto
> >> ending in @google.com.  We cannot infer an OD from that, but I think
> the
> >> concept is clear.>>
> >
> > I don't think this has anything to do with the PSD proposal either. Why
> do
> > you bring it up?
>
>
> If it were possible to infer OD from some kind of DNS record (or from RDAP
> responses, for another way) then we'd have a tool alternative to the PSL.
> That
> proves that the concept of OD is independent of the PSL, doesn'it?
>
>
> >>> As to the proposed "let's run this as an experiment pending DMARCbis",
> >>> I don't see how that satisfies Dave's concern about creating new work
> >>> for receivers in order to help a small set of domain (realm) owners.
> I'm
> >>> not opposed to it, but I just don't see how this solves the issue.>>
> >> Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt
> >> returns an empty NOERROR response, while _dmarc.gov.uk returns a valid
> >> record. The latter is a Nominet, already solved problem, AFAICS.>>
> >
> > If it was a solved problem, then we would not need a PSD (or realm) I-D
> and
> > this whole discussion would be moot. What ICANN does and does not allow
> is
> > out of scope for the IETF/protocol work (though I do acknowledge that
> ICANN
> > may consider protocol factors when making decisions - or I would hope
> that
> > they would).
>
>
> Oh, you meant the receivers burden of an extra lookup?  Sorry, I though it
> was
> about the need for each OD to opt out by defining its own DMARC record,
> lest
> have reports delivered to the realm.  In the latter sense, Nominet solved
> the
> problem of what rights has gov.uk on domains below it.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Tim Wicinski]

Kurt

You are absolutely correct.  We were having such discussions about the PSL
origins that I was going back over the DMARC spec and refreshing my
memory on how the PSL was defined and used. I wasn't even looking at the
PSD document.

Tim

On Mon, Nov 11, 2019 at 10:46 AM Kurt Andersen (b)  wrote:

> On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski  wrote:
>
>> Scott
>>
>> PSD DMARC does talk about organizational domains which from the original
>> DMARC spec (section 3.2)
>> does say 'Acquire a "public suffix" list'
>>
>> The addition of the preamble text shouldn't move the document in either
>> direction.
>> I do feel anything which helps focus us on moving forward on DMARC-bis is
>> a good thing.
>> The WG should be able to start writing the PSL document right away.
>>
>
> Tim,
>
> I think that you are being too liberal in applying transitive references.
> The PSD document only refers to the PSL in
>
>- Informative References
>- Appendix A.1
>- Appendix B.3
>- Appendix C.2 (implementations)
>
> I don't think that it is fair to say that anyone who refers to the org
> domain concept as cited in the DMARC spec is necessarily invoking the PSL.
>
> I do have a problem with the conflation of the org domain with a
> super-organizational "realm" (?) that may impose conditions upon
> organizations that fall within their jurisdictional purview. My main
> concerns are with the potential usurpation of the org domain's policy
> declaration rights. "Moving" the org domain up one level disenfranchises
> the organizations and that is the wrong thing to do IMO.
>
> As to the proposed "let's run this as an experiment pending DMARCbis", I
> don't see how that satisfies Dave's concern about creating new work for
> receivers in order to help a small set of domain (realm) owners. I'm not
> opposed to it, but I just don't see how this solves the issue.
>
> --Kurt
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Mon 11/Nov/2019 19:31:52 +0100 Kurt Andersen (b) wrote:
> On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely  wrote:
> 
>> For various reasons, large organizations administer many apparently 
>> unrelated domains.  For example, _dmarc.youtube.com has a rua mailto
>> ending in @google.com.  We cannot infer an OD from that, but I think the
>> concept is clear.>>
> 
> I don't think this has anything to do with the PSD proposal either. Why do
> you bring it up?


If it were possible to infer OD from some kind of DNS record (or from RDAP
responses, for another way) then we'd have a tool alternative to the PSL.  That
proves that the concept of OD is independent of the PSL, doesn'it?


>>> As to the proposed "let's run this as an experiment pending DMARCbis",
>>> I don't see how that satisfies Dave's concern about creating new work
>>> for receivers in order to help a small set of domain (realm) owners. I'm
>>> not opposed to it, but I just don't see how this solves the issue.>>
>> Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt 
>> returns an empty NOERROR response, while _dmarc.gov.uk returns a valid
>> record. The latter is a Nominet, already solved problem, AFAICS.>>
> 
> If it was a solved problem, then we would not need a PSD (or realm) I-D and
> this whole discussion would be moot. What ICANN does and does not allow is
> out of scope for the IETF/protocol work (though I do acknowledge that ICANN
> may consider protocol factors when making decisions - or I would hope that
> they would).


Oh, you meant the receivers burden of an extra lookup?  Sorry, I though it was
about the need for each OD to opt out by defining its own DMARC record, lest
have reports delivered to the realm.  In the latter sense, Nominet solved the
problem of what rights has gov.uk on domains below it.


Best
Ale
-- 
















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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 9:50 AM Alessandro Vesely  wrote:

> On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
> >
> > I don't think that it is fair to say that anyone who refers to the org
> domain
> > concept as cited in the DMARC spec is necessarily invoking the PSL.
>
> Agreed.  The PSL just happens to be the only valid tool to do that.
>

Which was not what I thought Tim W was talking about...


> For various reasons, large organizations administer many apparently
> unrelated
> domains.  For example, _dmarc.youtube.com has a rua mailto ending in
> @google.com.  We cannot infer an OD from that, but I think the concept is
> clear.
>

I don't think this has anything to do with the PSD proposal either. Why do
you bring it up?


> > As to the proposed "let's run this as an experiment pending DMARCbis", I
> don't
> > see how that satisfies Dave's concern about creating new work for
> receivers in
> > order to help a small set of domain (realm) owners. I'm not opposed to
> it, but
> > I just don't see how this solves the issue.
>
> Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt
> returns
> an empty NOERROR response, while _dmarc.gov.uk returns a valid record.
> The
> latter is a Nominet, already solved problem, AFAICS.
>

If it was a solved problem, then we would not need a PSD (or realm) I-D and
this whole discussion would be moot. What ICANN does and does not allow is
out of scope for the IETF/protocol work (though I do acknowledge that ICANN
may consider protocol factors when making decisions - or I would hope that
they would).

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Mon 11/Nov/2019 16:46:17 +0100 Kurt Andersen (b) wrote:
> 
> I don't think that it is fair to say that anyone who refers to the org domain
> concept as cited in the DMARC spec is necessarily invoking the PSL.


Agreed.  The PSL just happens to be the only valid tool to do that.

For various reasons, large organizations administer many apparently unrelated
domains.  For example, _dmarc.youtube.com has a rua mailto ending in
@google.com.  We cannot infer an OD from that, but I think the concept is clear.


> I do have a problem with the conflation of the org domain with a
> super-organizational "realm" (?) that may impose conditions upon organizations
> that fall within their jurisdictional purview. My main concerns are with the
> potential usurpation of the org domain's policy declaration rights. "Moving"
> the org domain up one level disenfranchises the organizations and that is the
> wrong thing to do IMO.


The I-D definitions are clear enough.  Section 2.5, in particular, prevents the
conflation neatly.


> As to the proposed "let's run this as an experiment pending DMARCbis", I don't
> see how that satisfies Dave's concern about creating new work for receivers in
> order to help a small set of domain (realm) owners. I'm not opposed to it, but
> I just don't see how this solves the issue.


Isn't that an ICANN problem?  For the time being, dig _dmarc.bank txt returns
an empty NOERROR response, while _dmarc.gov.uk returns a valid record.  The
latter is a Nominet, already solved problem, AFAICS.


Best
Ale
-- 














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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski  wrote:

> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
> I do feel anything which helps focus us on moving forward on DMARC-bis is
> a good thing.
> The WG should be able to start writing the PSL document right away.
>

Tim,

I think that you are being too liberal in applying transitive references.
The PSD document only refers to the PSL in

   - Informative References
   - Appendix A.1
   - Appendix B.3
   - Appendix C.2 (implementations)

I don't think that it is fair to say that anyone who refers to the org
domain concept as cited in the DMARC spec is necessarily invoking the PSL.

I do have a problem with the conflation of the org domain with a
super-organizational "realm" (?) that may impose conditions upon
organizations that fall within their jurisdictional purview. My main
concerns are with the potential usurpation of the org domain's policy
declaration rights. "Moving" the org domain up one level disenfranchises
the organizations and that is the wrong thing to do IMO.

As to the proposed "let's run this as an experiment pending DMARCbis", I
don't see how that satisfies Dave's concern about creating new work for
receivers in order to help a small set of domain (realm) owners. I'm not
opposed to it, but I just don't see how this solves the issue.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Kurt Andersen (b)]

On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski  wrote:

> Scott
>
> PSD DMARC does talk about organizational domains which from the original
> DMARC spec (section 3.2)
> does say 'Acquire a "public suffix" list'
>
> The addition of the preamble text shouldn't move the document in either
> direction.
> I do feel anything which helps focus us on moving forward on DMARC-bis is
> a good thing.
> The WG should be able to start writing the PSL document right away.
>
> Murray and I will be in Singapore if anyone wishes to speak their mind.
>
> thanks
> Tim
>
>
>
>
> On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman 
> wrote:
>
>>
>>
>> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <
>> superu...@gmail.com> wrote:
>> >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker  wrote:
>> >
>> >> > 1. The change to DMARC should be limited to permitting the query
>> >for the
>> >> > organization domain to be anywhere in the DNS tree, including a
>> >TLD.
>> >> > Within DMARC this would not look like 'extra' mechanism.
>> >> >
>> >> > 2. The mechanism that processes that query should be cast strictly
>> >as a
>> >> > PSL enhancement, independent of DMARC.
>> >>
>> >>
>> >> Trying to refine things further:
>> >>
>> >>
>> >> DMARC does not care about the PSL.
>> >>
>> >> What DMARC cares about is the Organizational Domain (OD), as a
>> >> fallback when no DMARC record is found at the desired domain name.
>> >>
>> >> That is, PSL is literally outside the scope of DMARC.
>> >>
>> >> At the least, therefore, the DMARC specification should define a
>> >> distinct interface to the outside functionality that tells DMARC
>> >where
>> >> the OD is, which will return what suffix of the full domain name is
>> >the
>> >> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>> >>
>> >> The PSL-related side of that interface should be a separate
>> >> specification, so that changes to its behavior -- such as has been
>> >> happening with the introduction of ODs that are TLDs or are otherwise
>> >> 'above' where DMARC has been guessing the OD to be -- are isolated
>> >from
>> >> DMARC.
>> >>
>> >> The current problems are that DMARC has embedded too much detail
>> >> about the PSL world, yet DMARC has no involvement in that world. The
>> >> current proposal embeds assumptions of PSL knowledge further, rather
>> >> than separating PSL knowledge out.
>> >>
>> >
>> >We (the chairs) fully agree with all of this.  What we -- I in
>> >particular
>> >-- have been struggling with is to find a path forward so the PSD
>> >experiment can still take place without being blocked by the need to
>> >first
>> >go back and overhaul RFC 7489 as you've described here, separating
>> >DMARC
>> >and the OD determination.  Because that'll take months.
>> >
>> >We are perhaps in the fortuitous position in our charter now that our
>> >very
>> >next work item is to take up the task of reopening DMARC itself, and
>> >the
>> >separation of function Dave is espousing could be made into a reality
>> >during that work.  Given this, we suggest that the PSD draft be allowed
>> >to
>> >proceed as Experimental, but with appropriate preamble text added to
>> >its
>> >Introduction explaining the deficiency Dave has identified.  So the
>> >order
>> >of operations becomes:
>> >
>> >* add text to the PSD draft making it clear that what it's describing
>> >is an
>> >experiment whose outcome will be taken only as feedback to the revision
>> >of
>> >the standard (i.e., this is not intended to be the final form of
>> >anything),
>> >and it is not intended to be deployed outside of the experiment's
>> >participants;
>> >* publish the experiment with those cautions and allow the experiment
>> >to
>> >begin
>> >* while the experiment is running, spin up the work on two new
>> >standards
>> >track documents, in line with our charter:
>> >a) DMARC, with PSL references replaced by the abstract notion of the OD
>> >that's determined in some non-specific way, as Dave suggests
>> >b) a PSL document that satisfies the abstract notion of OD in the DMARC
>> >document, also as Dave suggests
>> >* when the experiment completes, either augment (b) if it's still in
>> >development, or publish a revision to it, based on what the experiment
>> >has
>> >revealed
>> >
>> >Can this be made to work?
>> >
>> >Honestly, the experiment could start anyway without an RFC published,
>> >but a
>> >formal record of the experiment and its caveats doesn't strike me as a
>> >wrong thing to do.
>>
>> The current revision of the PSD DMARC draft makes no reference to the PSL
>> in the body of the draft (it only comes up in Appendix A and C).It
>> seems like an odd choice to continue to insist PSD DMARC is specifically
>> tied to the PSL when the text indicating so has been removed (Dave's email
>> was two months ago and things have changed in the interim).
>>
>> I don't think the proposed note says anything the status of experimental
>> shouldn't already communicate.  Given the current 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Tim Wicinski]

Scott

PSD DMARC does talk about organizational domains which from the original
DMARC spec (section 3.2)
does say 'Acquire a "public suffix" list'

The addition of the preamble text shouldn't move the document in either
direction.
I do feel anything which helps focus us on moving forward on DMARC-bis is a
good thing.
The WG should be able to start writing the PSL document right away.

Murray and I will be in Singapore if anyone wishes to speak their mind.

thanks
Tim




On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman 
wrote:

>
>
> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker  wrote:
> >
> >> > 1. The change to DMARC should be limited to permitting the query
> >for the
> >> > organization domain to be anywhere in the DNS tree, including a
> >TLD.
> >> > Within DMARC this would not look like 'extra' mechanism.
> >> >
> >> > 2. The mechanism that processes that query should be cast strictly
> >as a
> >> > PSL enhancement, independent of DMARC.
> >>
> >>
> >> Trying to refine things further:
> >>
> >>
> >> DMARC does not care about the PSL.
> >>
> >> What DMARC cares about is the Organizational Domain (OD), as a
> >> fallback when no DMARC record is found at the desired domain name.
> >>
> >> That is, PSL is literally outside the scope of DMARC.
> >>
> >> At the least, therefore, the DMARC specification should define a
> >> distinct interface to the outside functionality that tells DMARC
> >where
> >> the OD is, which will return what suffix of the full domain name is
> >the
> >> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
> >>
> >> The PSL-related side of that interface should be a separate
> >> specification, so that changes to its behavior -- such as has been
> >> happening with the introduction of ODs that are TLDs or are otherwise
> >> 'above' where DMARC has been guessing the OD to be -- are isolated
> >from
> >> DMARC.
> >>
> >> The current problems are that DMARC has embedded too much detail
> >> about the PSL world, yet DMARC has no involvement in that world. The
> >> current proposal embeds assumptions of PSL knowledge further, rather
> >> than separating PSL knowledge out.
> >>
> >
> >We (the chairs) fully agree with all of this.  What we -- I in
> >particular
> >-- have been struggling with is to find a path forward so the PSD
> >experiment can still take place without being blocked by the need to
> >first
> >go back and overhaul RFC 7489 as you've described here, separating
> >DMARC
> >and the OD determination.  Because that'll take months.
> >
> >We are perhaps in the fortuitous position in our charter now that our
> >very
> >next work item is to take up the task of reopening DMARC itself, and
> >the
> >separation of function Dave is espousing could be made into a reality
> >during that work.  Given this, we suggest that the PSD draft be allowed
> >to
> >proceed as Experimental, but with appropriate preamble text added to
> >its
> >Introduction explaining the deficiency Dave has identified.  So the
> >order
> >of operations becomes:
> >
> >* add text to the PSD draft making it clear that what it's describing
> >is an
> >experiment whose outcome will be taken only as feedback to the revision
> >of
> >the standard (i.e., this is not intended to be the final form of
> >anything),
> >and it is not intended to be deployed outside of the experiment's
> >participants;
> >* publish the experiment with those cautions and allow the experiment
> >to
> >begin
> >* while the experiment is running, spin up the work on two new
> >standards
> >track documents, in line with our charter:
> >a) DMARC, with PSL references replaced by the abstract notion of the OD
> >that's determined in some non-specific way, as Dave suggests
> >b) a PSL document that satisfies the abstract notion of OD in the DMARC
> >document, also as Dave suggests
> >* when the experiment completes, either augment (b) if it's still in
> >development, or publish a revision to it, based on what the experiment
> >has
> >revealed
> >
> >Can this be made to work?
> >
> >Honestly, the experiment could start anyway without an RFC published,
> >but a
> >formal record of the experiment and its caveats doesn't strike me as a
> >wrong thing to do.
>
> The current revision of the PSD DMARC draft makes no reference to the PSL
> in the body of the draft (it only comes up in Appendix A and C).It
> seems like an odd choice to continue to insist PSD DMARC is specifically
> tied to the PSL when the text indicating so has been removed (Dave's email
> was two months ago and things have changed in the interim).
>
> I don't think the proposed note says anything the status of experimental
> shouldn't already communicate.  Given the current state of the draft, I
> don't think it's necessary to have such a note.
>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker  wrote:
>
>> > 1. The change to DMARC should be limited to permitting the query
>for the
>> > organization domain to be anywhere in the DNS tree, including a
>TLD.
>> > Within DMARC this would not look like 'extra' mechanism.
>> >
>> > 2. The mechanism that processes that query should be cast strictly
>as a
>> > PSL enhancement, independent of DMARC.
>>
>>
>> Trying to refine things further:
>>
>>
>> DMARC does not care about the PSL.
>>
>> What DMARC cares about is the Organizational Domain (OD), as a
>> fallback when no DMARC record is found at the desired domain name.
>>
>> That is, PSL is literally outside the scope of DMARC.
>>
>> At the least, therefore, the DMARC specification should define a
>> distinct interface to the outside functionality that tells DMARC
>where
>> the OD is, which will return what suffix of the full domain name is
>the
>> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>>
>> The PSL-related side of that interface should be a separate
>> specification, so that changes to its behavior -- such as has been
>> happening with the introduction of ODs that are TLDs or are otherwise
>> 'above' where DMARC has been guessing the OD to be -- are isolated
>from
>> DMARC.
>>
>> The current problems are that DMARC has embedded too much detail
>> about the PSL world, yet DMARC has no involvement in that world. The
>> current proposal embeds assumptions of PSL knowledge further, rather
>> than separating PSL knowledge out.
>>
>
>We (the chairs) fully agree with all of this.  What we -- I in
>particular
>-- have been struggling with is to find a path forward so the PSD
>experiment can still take place without being blocked by the need to
>first
>go back and overhaul RFC 7489 as you've described here, separating
>DMARC
>and the OD determination.  Because that'll take months.
>
>We are perhaps in the fortuitous position in our charter now that our
>very
>next work item is to take up the task of reopening DMARC itself, and
>the
>separation of function Dave is espousing could be made into a reality
>during that work.  Given this, we suggest that the PSD draft be allowed
>to
>proceed as Experimental, but with appropriate preamble text added to
>its
>Introduction explaining the deficiency Dave has identified.  So the
>order
>of operations becomes:
>
>* add text to the PSD draft making it clear that what it's describing
>is an
>experiment whose outcome will be taken only as feedback to the revision
>of
>the standard (i.e., this is not intended to be the final form of
>anything),
>and it is not intended to be deployed outside of the experiment's
>participants;
>* publish the experiment with those cautions and allow the experiment
>to
>begin
>* while the experiment is running, spin up the work on two new
>standards
>track documents, in line with our charter:
>a) DMARC, with PSL references replaced by the abstract notion of the OD
>that's determined in some non-specific way, as Dave suggests
>b) a PSL document that satisfies the abstract notion of OD in the DMARC
>document, also as Dave suggests
>* when the experiment completes, either augment (b) if it's still in
>development, or publish a revision to it, based on what the experiment
>has
>revealed
>
>Can this be made to work?
>
>Honestly, the experiment could start anyway without an RFC published,
>but a
>formal record of the experiment and its caveats doesn't strike me as a
>wrong thing to do.

The current revision of the PSD DMARC draft makes no reference to the PSL in 
the body of the draft (it only comes up in Appendix A and C).It seems like 
an odd choice to continue to insist PSD DMARC is specifically tied to the PSL 
when the text indicating so has been removed (Dave's email was two months ago 
and things have changed in the interim).

I don't think the proposed note says anything the status of experimental 
shouldn't already communicate.  Given the current state of the draft, I don't 
think it's necessary to have such a note.

Scott K

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker  wrote:

> > 1. The change to DMARC should be limited to permitting the query for the
> > organization domain to be anywhere in the DNS tree, including a TLD.
> > Within DMARC this would not look like 'extra' mechanism.
> >
> > 2. The mechanism that processes that query should be cast strictly as a
> > PSL enhancement, independent of DMARC.
>
>
> Trying to refine things further:
>
>
> DMARC does not care about the PSL.
>
> What DMARC cares about is the Organizational Domain (OD), as a
> fallback when no DMARC record is found at the desired domain name.
>
> That is, PSL is literally outside the scope of DMARC.
>
> At the least, therefore, the DMARC specification should define a
> distinct interface to the outside functionality that tells DMARC where
> the OD is, which will return what suffix of the full domain name is the
> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>
> The PSL-related side of that interface should be a separate
> specification, so that changes to its behavior -- such as has been
> happening with the introduction of ODs that are TLDs or are otherwise
> 'above' where DMARC has been guessing the OD to be -- are isolated from
> DMARC.
>
> The current problems are that DMARC has embedded too much detail
> about the PSL world, yet DMARC has no involvement in that world. The
> current proposal embeds assumptions of PSL knowledge further, rather
> than separating PSL knowledge out.
>

We (the chairs) fully agree with all of this.  What we -- I in particular
-- have been struggling with is to find a path forward so the PSD
experiment can still take place without being blocked by the need to first
go back and overhaul RFC 7489 as you've described here, separating DMARC
and the OD determination.  Because that'll take months.

We are perhaps in the fortuitous position in our charter now that our very
next work item is to take up the task of reopening DMARC itself, and the
separation of function Dave is espousing could be made into a reality
during that work.  Given this, we suggest that the PSD draft be allowed to
proceed as Experimental, but with appropriate preamble text added to its
Introduction explaining the deficiency Dave has identified.  So the order
of operations becomes:

* add text to the PSD draft making it clear that what it's describing is an
experiment whose outcome will be taken only as feedback to the revision of
the standard (i.e., this is not intended to be the final form of anything),
and it is not intended to be deployed outside of the experiment's
participants;
* publish the experiment with those cautions and allow the experiment to
begin
* while the experiment is running, spin up the work on two new standards
track documents, in line with our charter:
  a) DMARC, with PSL references replaced by the abstract notion of the OD
that's determined in some non-specific way, as Dave suggests
  b) a PSL document that satisfies the abstract notion of OD in the DMARC
document, also as Dave suggests
* when the experiment completes, either augment (b) if it's still in
development, or publish a revision to it, based on what the experiment has
revealed

Can this be made to work?

Honestly, the experiment could start anyway without an RFC published, but a
formal record of the experiment and its caveats doesn't strike me as a
wrong thing to do.

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Chudow, Eric B CIV NSA DSAW (USA)]

On September 5, 2019 8:22:27 PM UTC, Dave Crocker  wrote:
>On 9/4/2019 6:28 AM, Dave Crocker wrote:
>> ence my current view that:
>> 
>> 1. The change to DMARC should be limited to permitting the query for
>the
>> organization domain to be anywhere in the DNS tree, including a TLD. 
>> Within DMARC this would not look like 'extra' mechanism.
>> 

An additional DMARC query at one level above the organizational domain should 
be an additional query, rather than more simply being able to have the 
organizational domain higher up the DNS tree and not having an extra DMARC 
query.  This is particularly the case for reporting so that even if the 
organizational domain and the PSD domain one level above the organizational 
domain have the same DMARC requested handling policy, they can have different 
DMARC reporting addresses.

For DoD and the .mil TLD, we support this PSD DMARC effort and believe that it 
would be beneficial to have an additional DMARC query at the PSD level.

Thanks,
-Eric

Eric Chudow
DoD Cybersecurity Mitigations
eric.b.chudow@mail.mil


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Thu 05/Sep/2019 15:35:29 +0200 Scott Kitterman wrote:
>>> If we didn't care about privacy, this would be easy.  That's the hard
>>> part that does not have a clear solution.  One thing that is clear is
>>> that it's not the PSL.  PSL is a collector of assertions from operators,
>>> so it fails to meet the attributes laid out in A.1.>>
>> Failure reports are considerably less implemented than aggregate ones. 
>> The current spec doesn't mention any privacy risk in its Security 
>> Considerations section.  However, some concern must exist, otherwise the
>> difference in implementations cannot be easily explained.  The I-D at hand
>> touches on this point marginally.  A general consideration would better
>> fit in DMARCbis.>
> That's because there's an entire separate section on privacy considerations.


My bad English.  By "current spec" I meant rfc7489.


Best
Ale
-- 






























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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Thursday, September 5, 2019 9:02:45 PM EDT Dave Crocker wrote:
> On 9/5/2019 2:49 PM, Scott Kitterman wrote:
> > I don't think so.  The draft defines PSD as org - 1.
> 
> Writing a definition for something you don't control and that can (and
> has) change tends to be problematic.
> 
> As it is here.

Now that I'm at a computer where I can review the draft as it stands (as 
opposed to the draft as I remember it), I agree the current definition is 
problematic.  However, I think it's easily fixable.  Here's where I see a 
problem:

> 2.3.  Longest PSD
> 
>The longest PSD is the PSD matching more labels in the domain name
>under evaluation than any other public suffix list entry.

As you suggest, it leverages PSL in a way that's sub-optimal at best.  
Fortunately I think we can fix it.  I'd suggest this instead:

2.3.  Longest PSD

   The longest PSD is the Organizational Domain with one label removed.

With that change, PSD DMARC makes no claims based on use of the PSL that 
aren't inherited from DMARC.

How's that?

Scott K



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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 9/5/2019 2:49 PM, Scott Kitterman wrote:

I don't think so.  The draft defines PSD as org - 1.



Writing a definition for something you don't control and that can (and 
has) change tends to be problematic.


As it is here.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On September 5, 2019 8:22:27 PM UTC, Dave Crocker  wrote:
>On 9/4/2019 6:28 AM, Dave Crocker wrote:
>> ence my current view that:
>> 
>> 1. The change to DMARC should be limited to permitting the query for
>the 
>> organization domain to be anywhere in the DNS tree, including a TLD. 
>> Within DMARC this would not look like 'extra' mechanism.
>> 
>> 2. The mechanism that processes that query should be cast strictly as
>a 
>> PSL enhancement, independent of DMARC.
>
>
>Trying to refine things further:
>
>
>DMARC does not care about the PSL.
>
>What DMARC cares about is the Organizational Domain (OD), as a 
>fallback when no DMARC record is found at the desired domain name.
>
>That is, PSL is literally outside the scope of DMARC.
>
>At the least, therefore, the DMARC specification should define a 
>distinct interface to the outside functionality that tells DMARC where 
>the OD is, which will return what suffix of the full domain name is the
>
>OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>
>The PSL-related side of that interface should be a separate 
>specification, so that changes to its behavior -- such as has been 
>happening with the introduction of ODs that are TLDs or are otherwise 
>'above' where DMARC has been guessing the OD to be -- are isolated from
>
>DMARC.
>
>The current problems are that DMARC has embedded too much detail 
>about the PSL world, yet DMARC has no involvement in that world. The 
>current proposal embeds assumptions of PSL knowledge further, rather 
>than separating PSL knowledge out.

I don't think so.  The draft defines PSD as org - 1.  However you figure out 
org (currently PSL, but whatever).  If there's some place in the draft that 
doesn't say that, it's a mistake to fix.

I'm currently writing on my phone, so draft review isn't easy.  I'll look at it 
again later today and report back on details.  If you have specific suggestions 
on making this clearer, please let me know.

Scott K

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 9/4/2019 6:28 AM, Dave Crocker wrote:

ence my current view that:

1. The change to DMARC should be limited to permitting the query for the 
organization domain to be anywhere in the DNS tree, including a TLD. 
Within DMARC this would not look like 'extra' mechanism.


2. The mechanism that processes that query should be cast strictly as a 
PSL enhancement, independent of DMARC.



Trying to refine things further:


   DMARC does not care about the PSL.

   What DMARC cares about is the Organizational Domain (OD), as a 
fallback when no DMARC record is found at the desired domain name.


   That is, PSL is literally outside the scope of DMARC.

   At the least, therefore, the DMARC specification should define a 
distinct interface to the outside functionality that tells DMARC where 
the OD is, which will return what suffix of the full domain name is the 
OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix


   The PSL-related side of that interface should be a separate 
specification, so that changes to its behavior -- such as has been 
happening with the introduction of ODs that are TLDs or are otherwise 
'above' where DMARC has been guessing the OD to be -- are isolated from 
DMARC.


   The current problems are that DMARC has embedded too much detail 
about the PSL world, yet DMARC has no involvement in that world. The 
current proposal embeds assumptions of PSL knowledge further, rather 
than separating PSL knowledge out.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On September 5, 2019 8:28:05 AM UTC, Alessandro Vesely  wrote:
>On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote:
>> On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote:
>>> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
 
 construction of an augmented PSL (i.e., the actual PSL coupled with
>the
 queryable registry described in Appendix B), which DMARC then can
 consume to resolve the use cases that have appeared which now need
>to be
 addressed.  The portion of the experiment comprising an
>augmentation to
 DMARC’s algorithm would therefore not be part of DMARC permanently.
 Then, if the experiment proves effective, that would become prima
>facie
 evidence that the PSL, augmented with this additional information,
>would
 enable DMARC to resolve those use cases.  Such an augmented PSL
>would
 still conform to the desirable separation of functions to which you
 alluded.
>>> 
>>> With respect to the use of this work as a model for changes to the
>PSL,
>>> unfortunately the spec is not written in a fashion to support that.
>>> This really is a core concern, in my view: the work needs to have a
>>> basic model that really is expected to be appropriate for the long
>term;
>>> hence my suggestion to highly limit any changes to DMARC and,
>instead,
>>> cast the bulk of the work as augmenting the PSL.
>>> 
>>> That said, and as for getting changes to the PSL, based on my
>>> interactions with that community, I think it unlikely.  There does
>not
>>> seem to be the interest or resources for such work.  Strategically,
>>> that's the biggest hurdle to overcome, IMO.
>>> 
>>> ..
>>> 
>>> Hence my current view that:
>>> 
>>> 1. The change to DMARC should be limited to permitting the query for
>the
>>> organization domain to be anywhere in the DNS tree, including a TLD.
>>> Within DMARC this would not look like 'extra' mechanism.
>>> 
>>> 2. The mechanism that processes that query should be cast strictly
>as a
>>> PSL enhancement, independent of DMARC.
>> 
>> I think some related, but distinct issues are conflated in your
>analysis.
>> 
>> The core PSD check doesn't need a PSL change.  The current PSL works
>fine.  The 
>> sequence is:
>> 
>> 1.  Check at the From domain level.
>> 2.  If no record, check at the org level.
>> 3.  [New] if no record check one level above the org level (PSD).
>> 
>> That's all doable with the current PSL.  I don't think we want to
>force 
>> additional lookups between 1 and 2 for lower level domains. 
>Currently for 
>> something like:
>> 
>> a.b.c.d.org.example where only example is in the PSL the queries
>would be:
>> 
>> 1.   a.b.c.d.org.example
>> 2.   org.example
>> 3.   example
>> 
>> As I read your proposal we've have to add in queries for:
>> 
>> b.c.d.org.example
>> c.d.org.example
>> d.org.example
>> 
>> I don't think querying anywhere in the DNS treee is an improvement
>for 
>> scalability of DMARC.
>
>
>Besides scalability, the question is whether b, c, or d have the right
>to
>override the DMARC policy of org.example.  The current spec clearly
>says no.
>
>My reading of Dave's proposal differs.  Modifying the PSL has the
>implicit
>objective to skip step 2.  That is, to limit queries to:
>
>1.   a.b.c.d.org.example
>3.   example
>
>Thereby slashing org.example's privilege to establish its own domain
>policy.
>
>
>> Adding the single additional PSD lookup works fine with the existing
>PSL.  
>> There are two reasons to go beyond this:
>> 
>> 1.  Since most PSDs won't publish DMARC records, as an efficiency,
>let's not do 
>> that third lookup unless we have to.
>> 
>> 2.  PSD DMARC without some constraints on the additional lookup
>automatically 
>> opts in all organizational domains that do not publish DMARC records,
>which 
>> has privacy implications.  This is discussed in Section 4.1 of the
>draft.
>
>
>We should also consider updates:
>
>How often is/should be the PSL updated at average mail servers?
>
>How often would then the extra list at psddmarc.org have to be updated?
>
>
>> As it says at the start of Appendix B, the options proposed there are
>to 
>> mitigate the privacy risks described in Section 4.1.  The related
>requirements 
>> discussion is in Appendix A, Section A.1.
>> 
>> It is a beneficial side effect that they also reduce the need for DNS
>lookups 
>> and thus provide an efficiency enhancement.
>> 
>> If we didn't care about privacy, this would be easy.  That's the hard
>part 
>> that does not have a clear solution.  One thing that is clear is that
>it's not 
>> the PSL.  PSL is a collector of assertions from operators, so it
>fails to meet 
>> the attributes laid out in A.1.
>
>
>Failure reports are considerably less implemented than aggregate ones. 
>The
>current spec doesn't mention any privacy risk in its Security
>Considerations
>section.  However, some concern must exist, otherwise the difference in
>implementations cannot be easily explained.  The I-D at hand touches on
>this

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote:
> On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote:
>> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
>>> 
>>> construction of an augmented PSL (i.e., the actual PSL coupled with the
>>> queryable registry described in Appendix B), which DMARC then can
>>> consume to resolve the use cases that have appeared which now need to be
>>> addressed.  The portion of the experiment comprising an augmentation to
>>> DMARC’s algorithm would therefore not be part of DMARC permanently.
>>> Then, if the experiment proves effective, that would become prima facie
>>> evidence that the PSL, augmented with this additional information, would
>>> enable DMARC to resolve those use cases.  Such an augmented PSL would
>>> still conform to the desirable separation of functions to which you
>>> alluded.
>> 
>> With respect to the use of this work as a model for changes to the PSL,
>> unfortunately the spec is not written in a fashion to support that.
>> This really is a core concern, in my view: the work needs to have a
>> basic model that really is expected to be appropriate for the long term;
>> hence my suggestion to highly limit any changes to DMARC and, instead,
>> cast the bulk of the work as augmenting the PSL.
>> 
>> That said, and as for getting changes to the PSL, based on my
>> interactions with that community, I think it unlikely.  There does not
>> seem to be the interest or resources for such work.  Strategically,
>> that's the biggest hurdle to overcome, IMO.
>> 
>> ..
>> 
>> Hence my current view that:
>> 
>> 1. The change to DMARC should be limited to permitting the query for the
>> organization domain to be anywhere in the DNS tree, including a TLD.
>> Within DMARC this would not look like 'extra' mechanism.
>> 
>> 2. The mechanism that processes that query should be cast strictly as a
>> PSL enhancement, independent of DMARC.
> 
> I think some related, but distinct issues are conflated in your analysis.
> 
> The core PSD check doesn't need a PSL change.  The current PSL works fine.  
> The 
> sequence is:
> 
> 1.  Check at the From domain level.
> 2.  If no record, check at the org level.
> 3.  [New] if no record check one level above the org level (PSD).
> 
> That's all doable with the current PSL.  I don't think we want to force 
> additional lookups between 1 and 2 for lower level domains.  Currently for 
> something like:
> 
> a.b.c.d.org.example where only example is in the PSL the queries would be:
> 
> 1.   a.b.c.d.org.example
> 2.   org.example
> 3.   example
> 
> As I read your proposal we've have to add in queries for:
> 
> b.c.d.org.example
> c.d.org.example
> d.org.example
> 
> I don't think querying anywhere in the DNS treee is an improvement for 
> scalability of DMARC.


Besides scalability, the question is whether b, c, or d have the right to
override the DMARC policy of org.example.  The current spec clearly says no.

My reading of Dave's proposal differs.  Modifying the PSL has the implicit
objective to skip step 2.  That is, to limit queries to:

1.   a.b.c.d.org.example
3.   example

Thereby slashing org.example's privilege to establish its own domain policy.


> Adding the single additional PSD lookup works fine with the existing PSL.  
> There are two reasons to go beyond this:
> 
> 1.  Since most PSDs won't publish DMARC records, as an efficiency, let's not 
> do 
> that third lookup unless we have to.
> 
> 2.  PSD DMARC without some constraints on the additional lookup automatically 
> opts in all organizational domains that do not publish DMARC records, which 
> has privacy implications.  This is discussed in Section 4.1 of the draft.


We should also consider updates:

How often is/should be the PSL updated at average mail servers?

How often would then the extra list at psddmarc.org have to be updated?


> As it says at the start of Appendix B, the options proposed there are to 
> mitigate the privacy risks described in Section 4.1.  The related 
> requirements 
> discussion is in Appendix A, Section A.1.
> 
> It is a beneficial side effect that they also reduce the need for DNS lookups 
> and thus provide an efficiency enhancement.
> 
> If we didn't care about privacy, this would be easy.  That's the hard part 
> that does not have a clear solution.  One thing that is clear is that it's 
> not 
> the PSL.  PSL is a collector of assertions from operators, so it fails to 
> meet 
> the attributes laid out in A.1.


Failure reports are considerably less implemented than aggregate ones.  The
current spec doesn't mention any privacy risk in its Security Considerations
section.  However, some concern must exist, otherwise the difference in
implementations cannot be easily explained.  The I-D at hand touches on this
point marginally.  A general consideration would better fit in DMARCbis.


Best
Ale
-- 























___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Scott Kitterman]

On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote:
> Murray,
> 
> Thanks for the diligent reply.
> 
> (As a matter of etiquette, I will again apologize for not having
> submitted my concerns earlier.  Partially, this was because my
> assessment of the work did not gel until recently.)
> 
> 
> Some responses:
> 
> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
> >  From a higher level view, the experiment can be seen as the temporary
> > 
> > construction of an augmented PSL (i.e., the actual PSL coupled with the
> > queryable registry described in Appendix B), which DMARC then can
> > consume to resolve the use cases that have appeared which now need to be
> > addressed.  The portion of the experiment comprising an augmentation to
> > DMARC’s algorithm would therefore not be part of DMARC permanently.
> > Then, if the experiment proves effective, that would become prima facie
> > evidence that the PSL, augmented with this additional information, would
> > enable DMARC to resolve those use cases.  Such an augmented PSL would
> > still conform to the desirable separation of functions to which you
> > alluded.
> This model of iterative design does not match my own sense of IETF work,
> experimental or otherwise.
> 
> Simply put, 'temporary' is an appealing but highly misleading construct,
> in the form and scale of a standards body.[*]  The closest reality comes
> to matching that term is when the 'experiment' fails utterly and the
> effort must completely restart. When work like this operates over a
> period of years and at Internet scale, nothing is temporary.
> 
> If an experiment succeeds, the specified work will have become
> entrenched and there will be significant resistance to making major changes.
> 
> With respect to the use of this work as a model for changes to the PSL,
> unfortunately the spec is not written in a fashion to support that.
> This really is a core concern, in my view: the work needs to have a
> basic model that really is expected to be appropriate for the long term;
> hence my suggestion to highly limit any changes to DMARC and, instead,
> cast the bulk of the work as augmenting the PSL.
> 
> That said, and as for getting changes to the PSL, based on my
> interactions with that community, I think it unlikely.  There does not
> seem to be the interest or resources for such work.  Strategically,
> that's the biggest hurdle to overcome, IMO.
> 
> > In addition, there are a few very large players in the space who are
> > unfortunately reticent to declare publicly that they are interested in
> > seeing this evolutionary experiment proceed.  These include large email
> > providers and operators of sizable TLDs in need of the capabilities
> > pursued here. This provides some weight to the idea that this will not
> > be simply a niche experiment.
> 
> Good to hear.
> 
> > Lastly, we note that the idea of “walk up one node” came from an email
> > thread in December[1] wherein you suggested that approach, and which the
> > PSD draft now follows.  We are thus a little surprised by the assertion
> > that it should not proceed at all. Was there some content of that thread
> > that was not taken into account that would make it palatable?
> 
> ..
> 
> > [1]
> > https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI
> 
> Sigh.  Yeah.  Still again, sorry.  Mostly this is a case of letting an
> idea simmer for a while, to think about it more.  My feeling is that the
> idea does not adequately attend to the items 1 and 2 I listed in that note.
> 
> Hence my current view that:
> 
> 1. The change to DMARC should be limited to permitting the query for the
> organization domain to be anywhere in the DNS tree, including a TLD.
> Within DMARC this would not look like 'extra' mechanism.
> 
> 2. The mechanism that processes that query should be cast strictly as a
> PSL enhancement, independent of DMARC.

I think some related, but distinct issues are conflated in your analysis.

The core PSD check doesn't need a PSL change.  The current PSL works fine.  The 
sequence is:

1.  Check at the From domain level.
2.  If no record, check at the org level.
3.  [New] if no record check one level above the org level (PSD).

That's all doable with the current PSL.  I don't think we want to force 
additional lookups between 1 and 2 for lower level domains.  Currently for 
something like:

a.b.c.d.org.example where only example is in the PSL the queries would be:

1.   a.b.c.d.org.example
2 .  org.example
3.  example

As I read your proposal we've have to add in queries for:

b.c.d.org.example
c.d.org.example
d.org.example

I don't think querying anywhere in the DNS treee is an improvement for 
scalability of DMARC.

Adding the single additional PSD lookup works fine with the existing PSL.  
There are two reasons to go beyond this:

1.  Since most PSDs won't publish DMARC records, as an efficiency, let's not do 
that third lookup unless we have to.

2.  PSD DMARC without some constraints 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Hector Santos]

We need to use the QUERY for the DMARC record to get compliant clients 
to try (explore) different things. Let the record tell the client what 
to do. We need an expanded language for the possible tags.   SPF was 
very flexible.  DMARC is not because it removed 3rd party 
capabilities. It is too limited.  In the end, this is still about 3rd 
party AA (authentication/authorization) and in this case what is being 
labeled PSD domains.  Just define/refine the BASE lookup mechanism, 
and the possible extensions.


ATPS offers an extended protocol mechanism for 3rd party domain 
authorization.  This is basically what is wanted for PSD.




On 9/4/2019 9:28 AM, Dave Crocker wrote:

Murray,

Thanks for the diligent reply.

(As a matter of etiquette, I will again apologize for not having
submitted my concerns earlier.  Partially, this was because my
assessment of the work did not gel until recently.)


Some responses:

On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:

 From a higher level view, the experiment can be seen as the
temporary construction of an augmented PSL (i.e., the actual PSL
coupled with the queryable registry described in Appendix B), which
DMARC then can consume to resolve the use cases that have appeared
which now need to be addressed.  The portion of the experiment
comprising an augmentation to DMARC’s algorithm would therefore not
be part of DMARC permanently. Then, if the experiment proves
effective, that would become prima facie evidence that the PSL,
augmented with this additional information, would enable DMARC to
resolve those use cases.  Such an augmented PSL would still conform
to the desirable separation of functions to which you alluded.


This model of iterative design does not match my own sense of IETF
work, experimental or otherwise.

Simply put, 'temporary' is an appealing but highly misleading
construct, in the form and scale of a standards body.[*]  The closest
reality comes to matching that term is when the 'experiment' fails
utterly and the effort must completely restart. When work like this
operates over a period of years and at Internet scale, nothing is
temporary.

If an experiment succeeds, the specified work will have become
entrenched and there will be significant resistance to making major
changes.

With respect to the use of this work as a model for changes to the
PSL, unfortunately the spec is not written in a fashion to support
that. This really is a core concern, in my view: the work needs to
have a basic model that really is expected to be appropriate for the
long term; hence my suggestion to highly limit any changes to DMARC
and, instead, cast the bulk of the work as augmenting the PSL.

That said, and as for getting changes to the PSL, based on my
interactions with that community, I think it unlikely.  There does not
seem to be the interest or resources for such work.  Strategically,
that's the biggest hurdle to overcome, IMO.




In addition, there are a few very large players in the space who are
unfortunately reticent to declare publicly that they are interested
in seeing this evolutionary experiment proceed.  These include large
email providers and operators of sizable TLDs in need of the
capabilities pursued here. This provides some weight to the idea
that this will not be simply a niche experiment.


Good to hear.



Lastly, we note that the idea of “walk up one node” came from an
email thread in December[1] wherein you suggested that approach, and
which the PSD draft now follows.  We are thus a little surprised by
the assertion that it should not proceed at all. Was there some
content of that thread that was not taken into account that would
make it palatable?

..

[1]
https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI


Sigh.  Yeah.  Still again, sorry.  Mostly this is a case of letting an
idea simmer for a while, to think about it more.  My feeling is that
the idea does not adequately attend to the items 1 and 2 I listed in
that note.

Hence my current view that:

1. The change to DMARC should be limited to permitting the query for
the organization domain to be anywhere in the DNS tree, including a
TLD. Within DMARC this would not look like 'extra' mechanism.

2. The mechanism that processes that query should be cast strictly as
a PSL enhancement, independent of DMARC.


d/

[*] Note the 'obsolete' construct in RFC 5322.  It was introduced in
RFC 2822, as a revision to RFC 822, 20 years ago.  As is obvious, it's
intent was to eliminate use of the portions of RFC 822 deemed
obsolete. Yet these portions still haven't been eliminated from the
specification.  Twenty years later.



--
HLS


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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Tim Wicinski]

Dave

I've had discussions with folks within the W3C on the PSL and the
possibility of extending it,
and there is always interest in considering requests from the IETF, but
they are the final
decision makers.

The whole idea of running an experiment would be to produce data that can
be shared and
can help the W3C modify the PSL.  Suggesting changes without understanding
their effects sounds would concern me.

Tim
(hats/no hats/I apologize for not knowing)


On Wed, Sep 4, 2019 at 9:29 AM Dave Crocker  wrote:

> Murray,
>
> Thanks for the diligent reply.
>
> (As a matter of etiquette, I will again apologize for not having
> submitted my concerns earlier.  Partially, this was because my
> assessment of the work did not gel until recently.)
>
>
> Some responses:
>
> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
> >  From a higher level view, the experiment can be seen as the temporary
> > construction of an augmented PSL (i.e., the actual PSL coupled with the
> > queryable registry described in Appendix B), which DMARC then can
> > consume to resolve the use cases that have appeared which now need to be
> > addressed.  The portion of the experiment comprising an augmentation to
> > DMARC’s algorithm would therefore not be part of DMARC permanently.
> > Then, if the experiment proves effective, that would become prima facie
> > evidence that the PSL, augmented with this additional information, would
> > enable DMARC to resolve those use cases.  Such an augmented PSL would
> > still conform to the desirable separation of functions to which you
> alluded.
>
> This model of iterative design does not match my own sense of IETF work,
> experimental or otherwise.
>
> Simply put, 'temporary' is an appealing but highly misleading construct,
> in the form and scale of a standards body.[*]  The closest reality comes
> to matching that term is when the 'experiment' fails utterly and the
> effort must completely restart. When work like this operates over a
> period of years and at Internet scale, nothing is temporary.
>
> If an experiment succeeds, the specified work will have become
> entrenched and there will be significant resistance to making major
> changes.
>
> With respect to the use of this work as a model for changes to the PSL,
> unfortunately the spec is not written in a fashion to support that.
> This really is a core concern, in my view: the work needs to have a
> basic model that really is expected to be appropriate for the long term;
> hence my suggestion to highly limit any changes to DMARC and, instead,
> cast the bulk of the work as augmenting the PSL.
>
> That said, and as for getting changes to the PSL, based on my
> interactions with that community, I think it unlikely.  There does not
> seem to be the interest or resources for such work.  Strategically,
> that's the biggest hurdle to overcome, IMO.
>
>
>
> > In addition, there are a few very large players in the space who are
> > unfortunately reticent to declare publicly that they are interested in
> > seeing this evolutionary experiment proceed.  These include large email
> > providers and operators of sizable TLDs in need of the capabilities
> > pursued here. This provides some weight to the idea that this will not
> > be simply a niche experiment.
>
> Good to hear.
>
>
> > Lastly, we note that the idea of “walk up one node” came from an email
> > thread in December[1] wherein you suggested that approach, and which the
> > PSD draft now follows.  We are thus a little surprised by the assertion
> > that it should not proceed at all. Was there some content of that thread
> > that was not taken into account that would make it palatable?
> ..
> > [1]
> https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI
>
> Sigh.  Yeah.  Still again, sorry.  Mostly this is a case of letting an
> idea simmer for a while, to think about it more.  My feeling is that the
> idea does not adequately attend to the items 1 and 2 I listed in that note.
>
> Hence my current view that:
>
> 1. The change to DMARC should be limited to permitting the query for the
> organization domain to be anywhere in the DNS tree, including a TLD.
> Within DMARC this would not look like 'extra' mechanism.
>
> 2. The mechanism that processes that query should be cast strictly as a
> PSL enhancement, independent of DMARC.
>
>
> d/
>
> [*] Note the 'obsolete' construct in RFC 5322.  It was introduced in RFC
> 2822, as a revision to RFC 822, 20 years ago.  As is obvious, it's
> intent was to eliminate use of the portions of RFC 822 deemed obsolete.
> Yet these portions still haven't been eliminated from the specification.
>   Twenty years later.
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Craig Schwartz]

Murray,



Thanks for the thorough summary of where this work stands and the
constructive feedback to Dave Crocker’s comment on 14 August 2019 (see
https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg).



I previously commented on this work on 15 July 2019 (see
https://mailarchive.ietf.org/arch/msg/dmarc/sw50iND6rZqbEEm16rFDKFsgERU)
and voiced support for the technical solution outlined in the Internet
Draft so will not repeat it again here as it’s not changed.



On behalf of fTLD, our internal DMARC Working Group and the thousands of
registrants in the .BANK and .INSURANCE TLDs, I support the continuation of
this work.



Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .INSURANCE
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

Murray,

Thanks for the diligent reply.

(As a matter of etiquette, I will again apologize for not having 
submitted my concerns earlier.  Partially, this was because my 
assessment of the work did not gel until recently.)



Some responses:

On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote:
 From a higher level view, the experiment can be seen as the temporary 
construction of an augmented PSL (i.e., the actual PSL coupled with the 
queryable registry described in Appendix B), which DMARC then can 
consume to resolve the use cases that have appeared which now need to be 
addressed.  The portion of the experiment comprising an augmentation to 
DMARC’s algorithm would therefore not be part of DMARC permanently. 
Then, if the experiment proves effective, that would become prima facie 
evidence that the PSL, augmented with this additional information, would 
enable DMARC to resolve those use cases.  Such an augmented PSL would 
still conform to the desirable separation of functions to which you alluded.


This model of iterative design does not match my own sense of IETF work, 
experimental or otherwise.


Simply put, 'temporary' is an appealing but highly misleading construct, 
in the form and scale of a standards body.[*]  The closest reality comes 
to matching that term is when the 'experiment' fails utterly and the 
effort must completely restart. When work like this operates over a 
period of years and at Internet scale, nothing is temporary.


If an experiment succeeds, the specified work will have become 
entrenched and there will be significant resistance to making major changes.


With respect to the use of this work as a model for changes to the PSL, 
unfortunately the spec is not written in a fashion to support that. 
This really is a core concern, in my view: the work needs to have a 
basic model that really is expected to be appropriate for the long term; 
hence my suggestion to highly limit any changes to DMARC and, instead, 
cast the bulk of the work as augmenting the PSL.


That said, and as for getting changes to the PSL, based on my 
interactions with that community, I think it unlikely.  There does not 
seem to be the interest or resources for such work.  Strategically, 
that's the biggest hurdle to overcome, IMO.




In addition, there are a few very large players in the space who are 
unfortunately reticent to declare publicly that they are interested in 
seeing this evolutionary experiment proceed.  These include large email 
providers and operators of sizable TLDs in need of the capabilities 
pursued here. This provides some weight to the idea that this will not 
be simply a niche experiment.


Good to hear.


Lastly, we note that the idea of “walk up one node” came from an email 
thread in December[1] wherein you suggested that approach, and which the 
PSD draft now follows.  We are thus a little surprised by the assertion 
that it should not proceed at all. Was there some content of that thread 
that was not taken into account that would make it palatable?

..

[1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI


Sigh.  Yeah.  Still again, sorry.  Mostly this is a case of letting an 
idea simmer for a while, to think about it more.  My feeling is that the 
idea does not adequately attend to the items 1 and 2 I listed in that note.


Hence my current view that:

1. The change to DMARC should be limited to permitting the query for the 
organization domain to be anywhere in the DNS tree, including a TLD. 
Within DMARC this would not look like 'extra' mechanism.


2. The mechanism that processes that query should be cast strictly as a 
PSL enhancement, independent of DMARC.



d/

[*] Note the 'obsolete' construct in RFC 5322.  It was introduced in RFC 
2822, as a revision to RFC 822, 20 years ago.  As is obvious, it's 
intent was to eliminate use of the portions of RFC 822 deemed obsolete. 
Yet these portions still haven't been eliminated from the specification. 
 Twenty years later.


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Murray S. Kucherawy]

On Tue, Aug 13, 2019 at 7:02 PM Dave Crocker  wrote:

> Review of:DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) Extension For PSDs (Public Suffix Domains)
> I-D:  draft-ietf-dmarc-psd-06
> Reviewer: D. Crocker
> Review Date:  12 August 2019
>



Dave,

Thanks for your feedback about draft-ietf-dmarc-psd on August 13.  Though
Working Group Last Call closed on July 17th, the chairs have taken careful
consideration of your feedback before allowing the document to proceed.

We take these as the main points of your comments (and please correct us if
we have missed any):


   1.

   The current design of DMARC observes a clear division of functions
   between itself and the PSL.  Specifically, as you point out, DMARC relies
   on a PSL existing and being available as input, but provides no guidance
   regarding selection of a PSL source nor of its content management policy..
   Also, the only operation available on the list is a test of membership
   (i.e., “is this domain on the list?”). Both of these tenets contribute to
   simplicity in DMARC’s current design.
   2.

   The PSD proposal attempts to resolve use cases that have appeared since
   the publication of RFC7489 by prescribing the conditions under which an
   additional check for a policy record at a new (related) location should be
   done.  This violates the tenets of (1) above.
   3.

   This additional lookup, in those cases where it is done, increases
   substantially the complexity of DMARC implementations, and that complexity
   comes with non-trivial cost.
   4.

   The use case(s) sustained by this change are not clearly substantial or
   beneficial enough to warrant enshrining this as a change to DMARC, even
   with only Experimental status.  There has also been very little indication
   of interest for implementation of the experiment.


On review (and our apologies for the duration of that review), we believe
the current draft does attempt to address your concerns, but does not make
this clear in its current form.  Given our responses to your points below,
and if you agree, perhaps you can help us to compose alternative text that
improves that situation.

For the first two points, we concur.  On the issue of the second violating
the tenets of the first, we suggest that the outcome of the experiment can
be used to drive an evolution of the PSL into a new form and perhaps new
update policies.  That is, rather than driving a change to DMARC itself,
the experiment’s results (if successful) can drive a change to the PSL, or
perhaps inform development of an alternative to it.

>From a higher level view, the experiment can be seen as the temporary
construction of an augmented PSL (i.e., the actual PSL coupled with the
queryable registry described in Appendix B), which DMARC then can consume
to resolve the use cases that have appeared which now need to be
addressed.  The portion of the experiment comprising an augmentation to
DMARC’s algorithm would therefore not be part of DMARC permanently. Then,
if the experiment proves effective, that would become prima facie evidence
that the PSL, augmented with this additional information, would enable
DMARC to resolve those use cases.  Such an augmented PSL would still
conform to the desirable separation of functions to which you alluded.

The working group originally discussed other alternative ways to augment or
even replace the PSL, such as creating a queryable IANA registry controlled
under our own terms.  The WG did not achieve consensus on such a proposal.
Should this experiment bear fruit, that discussion could (and should) be
revisited. Also, to be clear, any effort to augment the format, content, or
management of the PSL would require collaboration with the Mozilla
Foundation, as they are its de facto maintainers; absent such
collaboration, or if our proposal is not accepted, we must revisit the
notion of creating our own version of it and coming up with workable query
and update mechanisms and policies.

On the third point, we respectfully disagree.  An informal canvassing of
some members of the DNS community has been done and the consensus opinion
suggests that the additional operational overhead proposed here is
negligible.  This is, indeed, a far cry from the resistance with which the
original DKIM policy work was met, wherein even a one-level tree walk
upward drew heavy criticism. Code-wise, DNS queries are well understood
processes by now, and adding one more to the implementations of those
packages with active representation in the working group has not been seen
as costly enough to be a concern.  And it seems logical that conducting
this experiment will indeed help to confirm whether the additional query is
an apparent burden on either implementers or operators.

On the final point, we suggest that the WG considers this an intentional
part of the experiment’s design.  The set of use cases to which the
experiment applies is 

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

On 8/15/2019 3:20 AM, Alessandro Vesely wrote:

I hope
large fragments of it will make their way to either the PSD draft or
the reviewed DMARC spec itself.



Thanks for the kind words, but they actually run counter to the larger 
message I meant to impart:  The entire PSD approach is problematic. 
This is not fixable.  A different approach is needed.


Making the draft Experimental is actually counter-productive, in that 
regard.  It puts a stamp of IETF approval.  The fact of Experimental is 
less significant than the fact of an IETF consensus stamp of encouragement.


There is also the small matter of a small (actually tiny) base of 
demonstrated support for this proposal.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Alessandro Vesely]

On Wed 14/Aug/2019 04:01:59 +0200 Dave Crocker wrote:
> 
> 
> Review of:    DMARC (Domain-based Message Authentication, Reporting, and
>   Conformance) Extension For PSDs (Public Suffix Domains)
> I-D:  draft-ietf-dmarc-psd-06
> Reviewer: D. Crocker
> Review Date:  12 August 2019


I like very much Dave's prose, especially the background.  I hope
large fragments of it will make their way to either the PSD draft or
the reviewed DMARC spec itself.

For brevity, however, I only quote the passages I comment on:


> This approach is problematic in several ways.
> 
> It is a substantial increase in DMARC's operational overhead.  It adds
> a query that will often be needed -- especially in the face of limited
> DMARC adoption.  If a domain is not already a 'popular' DMARC
> reference -- that is, frequently encountered by the querying site --
> it is likely that there will be no DMARC record for any of the three
> needed queries. That means a 50% increase from two (failed) DNS
> queries to three (failed) queries.


That's actually a bit better.  After the second (failed) query, the
receiver consults the "augmented PSD".  IMHO, the latter should be a
local lookup, just like the PSD itself.  The third query is only
issued if the prefix matches.  Then, the likelihood that it fails is
very low.


> Arguably for DMARC purposes, an association domain can be treated the
> same as an organization domain, since the scope of the domain's
> authority over its sub-domains is an internal matter, to be determined
> by its agreements with association members.
> 
> What this means is that the real requirement here is to improve the
> mechanism for identifying the organizational domain, and that
> requirement is outside of DMARC.  This does not reduce the necessity
> of identifying these domains; rather it moves the task to where it
> belongs: This requires modification to the public suffix list
> operation, possibly with a parallel "private TLD" registry.


Right.  However, consulting the augmented PSD still has to be done in
two steps, the first one to give the organizational domain a chance to
override the association domain policy, the second step if no override
was published.

Let me add that the relevant case is NXDOMAIN.  For existing domains,
the association can see if a lazy organization misses a record and
force them to comply.  However inconsiderately, the association could
even publish itself a txt record at _dmarc\.lazy.example.  The
annoyance is trying wildcards to cover any non-existent domain name.


> An added benefit to this alternate view is that it eliminates the
> privacy concern about the draft specification:  only upper-level
> domains operating as organizational domains will be able to publish a
> domain-wide DMARC policy record.  Domains that really are classic
> public suffixes won't be able to.


Certainly, A.bank and B.bank shall not be conflated as far as
exchanging cookies and access rights is concerned, so a fine-grained
PSD will continue to exist.

I'm not sure flattening that structure for DMARC is a benefit.  By
skipping the second query, we'd deny organizations the possibility to
have subdomain email addresses like mana...@branch.a.bank, unless
branch.A.bank either replicates or overrides the DMARC record of A.bank.




Best
Ale
-- 







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

[dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker]

Review of:DMARC (Domain-based Message Authentication, Reporting, and
  Conformance) Extension For PSDs (Public Suffix Domains)
I-D:  draft-ietf-dmarc-psd-06
Reviewer: D. Crocker
Review Date:  12 August 2019



The draft specification's intent is to address a basic operational 
limitation in the current use of DMARC. There are domains in the 
upper-reaches of the DNS space that are not accessible for obtaining 
organization-wide policy records, but which need to become accessible. 
Per the PSD draft:



For domains listed in a public suffix list, i.e. TLDs and domains
that exist between TLDs and organization level domains, policy can
only be published for the exact domain.  No method is available for
these domains to express policy or receive feedback reporting for
sub-domains.




Background
--

The operational history is that the upper reaches of the Domain Name 
System have been restricted to administration by organizations that all 
strictly served as constrained registries. Their domain names were 
allocated by ICANN or by another public agency (such as a government). 
They all were distinct as organizations registering sub-domain names for 
other, independent organizations.  Unfortunately there is no algorithm 
that can distinguish between these public registries from their 
sub-domains; hence they must be manually determined.  In the DMARC 
specification, the aggregation of these registries is referred to as a 
"public suffix list", after the primary Internet service offering such a 
list.  The term 'public' here is mostly taken to mean that the registry 
for such a domain operates as a public service.(*)


DMARC's use of a public suffix is to permit finding the "organizational 
domain", which is the domain name that is delegated from a public suffix 
registry and is the name highest up a branch while having the same 
administrative authority as the full (DMARC "aligned") domain name being 
evaluated by DMARC. The next-higher domain name above the organizational 
domain -- a public registry -- is under separate operational authority.


DMARC needs to know the organizational domain so that the organizational 
authority can assert a DMARC policy for all subordinate domains, notably 
those that do not publish their own DMARC record and domains that do not 
exist.  This capability overcomes a downgrade attack on DMARC, where an 
organization's intent to have all of its subdomains subject to DMARC 
evaluation can be bypassed by using a name that does not have an 
associated DMARC record.



 The focus on these two terms is important to highlight. They refer
 to the operational role of the domain name.

 A Public Suffix serves as a public registry.

 An Organizational Domain operates as a 'master' authority over a
 branch of related names.


While the popular public suffix listing example is cited, a specific 
public suffix list is not normatively incorporated into the DMARC 
specification:  That is, there is normative use of 'some' public suffix 
list, but no normative details for choosing it.  Determination of what 
is a public suffix and what is not is, therefore, outside the scope of 
the DMARC specification.  This is a very useful separation of functions, 
especially given operational concerns about the status quo for public 
suffix determination.  Decoupling moves those concerns away from DMARC, 
per se.  This both simplifies the DMARC specification and improves its 
stability, since it does not have to change when details of the public 
suffix functionality changes.


However there is now a requirement to extend DMARC's ability to assert 
an organizational policy record to include names in the upper levels of 
the DNS, which have classically been viewed as public suffixes.


Indeed, the draft specification calls them public suffixes.

Historically, domain names listed in these upper levels did not 
participate in the assertion of DMARC policies for their sub-domains. 
Now, some of these domains want to.


Specifically, some upper-level domain names need to be able to publish a 
DMARC record that asserts a policy for all sub-domains under them, in 
particular to cover domain names that do not exist or that have not 
published a DMARC record. This requirement even applies to some 
top-level domains.


That is, names that are typically classed as 'public suffix' names need 
to operate as 'organizational domains' for DMARC.




Draft PSD Specification
---

The PSD draft seeks to address this requirement.  Within the DMARC 
sandbox, it is important to have a way to communicate a domain owner's 
DMARC policy, for sub-domains that do not exist or do not publish a 
DMARC record directly.


For upper-level domains, the draft does this by introducing an 
additional query, to the domain name that is one level higher than the 
determined organizational domain.  The perspective of the draft is that 
it is adding a query into a