Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Nov 2018 13:23:08 +0700

> I'd like to recommend that we (DMARC-WG) accept https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00
> into our work queue. It aligns with our charter already.

I've seen three agreements and no objections, so here's an official
call for objections.  If there are none by 16 November, we will create
draft-ietf-dmarc-psd-00 as a new working group item.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Nov 2018 17:07:33 +0900

No objection.  I've already got opinions ready to go when it gets
accepted.  :-)

On Mon, Nov 5, 2018 at 3:23 PM Barry Leiba <[email-masked]> wrote:

> > I'd like to recommend that we (DMARC-WG) accept
> https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 5 Nov 2018 15:14:46 +0700

No objection here

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 6 Nov 2018 20:17:10 +0100

> draft-ietf-dmarc-psd-00 as a new working group item.

Can we have a brief discussion on what exactly is the purpose of the I-D?

At a first glance, it seems an attempt to override the Public Suffix List with
a IANA registry.  The PSL is based on IANA root zones, taking into account PSO
policies.  So, we're requiring PSOs to register their email policies at IANA,
while their web policies will continue to be "registered" at PSL.  Does that
sound somewhat curious or is it me?

BTW, I see
"v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:[email-masked];ruf=mailto:[email-masked]",
but neither .bank nor .insurance.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Nov 2018 19:39:14 +0000

>sound somewhat curious or is it me?

Only in a very limited sense.  DMARC currently stops at the organizational domain.  This sets up processing and structure for the limited cases where DMARC 'above' the organizational domain makes sense.  

To pick one notional example (real domains, but not reflective of any knowledge of domain owner plans or policies):

Why shouldn't Google be able to assert DMARC policy over subdomains of .google the same way it does over .google.com?  Currently they can't and this draft provides policy and mechanism for them to do so if they want.

Does that clarify it for you?

Scott K

---

From: Craig Schwartz <[email-masked]>
Date: Tue, 6 Nov 2018 17:03:01 -0500

>>BTW, I see
"v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:[email-masked]
rvice.gov.uk;ruf=mailto:[email-masked]",
but neither .bank nor .insurance.<<

The reason for this is that gov.uk is effectively a second-level domain name
and its administrator has a DMARC policy. DMARC at the top-level (e.g.,
.BANK, .INSURANCE) doesn't currently exist hence the rationale for the
proposed work.  

Craig Schwartz
Managing Director
fTLD Registry Services | .BANK & .INSURANCE

-----Original Message-----
From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
Sent: Tuesday, November 6, 2018 2:17 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Request to accept a new I-D into the WG work items

At a first glance, it seems an attempt to override the Public Suffix List
with a IANA registry.  The PSL is based on IANA root zones, taking into
account PSO policies.  So, we're requiring PSOs to register their email
policies at IANA, while their web policies will continue to be "registered"
at PSL.  Does that sound somewhat curious or is it me?

BTW, I see
"v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:[email-masked]
rvice.gov.uk;ruf=mailto:[email-masked]",
but neither .bank nor .insurance.

Best
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 7 Nov 2018 09:33:28 +0700

> Can we have a brief discussion on what exactly is the purpose of the I-D?

The intent is to allow the expression of a DMARC policy which would cover
non-existent org domains under a "longest public suffix". Right now, there
is no way to do that.

> with
> a IANA registry.

The IANA registry listing is to constrain which LPSs are exerting such
claims and to prevent abuse such as happened a few years ago on web
wildcards.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Nov 2018 10:08:50 +0700

My concern with this approach (which doesn't rise to the level of objecting
to its application as a WG document, though perhaps it should) is that it
is trending toward needing an IANA registry to be queryable in real-time,
and I don't believe they are equipped with the infrastructure to provide
that kind of service, nor is that likely to happen anytime soon.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Nov 2018 11:37:24 +0700

On Wed, Nov 7, 2018 at 10:08 AM Murray S. Kucherawy <[email-masked]>
wrote:

> My concern with this approach (which doesn't rise to the level of
> objecting to its application as a WG document, though perhaps it should) is
> that it is trending toward needing an IANA registry to be queryable in
> real-time, and I don't believe they are equipped with the infrastructure to
> provide that kind of service, nor is that likely to happen anytime soon.
>

This issue or something like it came up when I was chairing WEIRDS, so
that's where this is coming from.

There are IANA folks here at IETF this week.  I'll ask them.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Nov 2018 23:54:08 -0500

> There are IANA folks here at IETF this week.  I'll ask them.

Thanks,

My estimation is that this would change very rarely.  If I were developing 
software for this, I'd probably check at build time and use that unless there 
are some reason to update.  Not that people won't try, but I think not very 
real time is sufficient.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Nov 2018 14:56:14 +0700

> are some reason to update.  Not that people won't try, but I think not

Sure, but:

(a) You are probably a more reasonable and thoughtful implementer than
average; and

(b) It only takes one large operator to, through neglect or a desire to
ensure up-to-the-minute data, disregard any query rate advice we give and
accidentally DoS IANA off the 'net.

If IANA doesn't have a highly scalable CDN in front of it, which I doubt,
then this is something the IESG would legitimately raise (as they did with
WEIRDS) when this goes up for formal review.

DBOUND tried to do this inside the DNS, which solves the CDN problem, but
it couldn't reach consensus on the preferred approach, and shut down not
long ago without producing anything.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Nov 2018 12:25:52 +0000

On November 7, 2018 7:56:14 AM UTC, "Murray S. Kucherawy" <[email-masked]> wrote:
>> software for this, I'd probably check at build time and use that
>unless
>> there
>> are some reason to update.  Not that people won't try, but I think
>not
>> very
>> real time is sufficient.
>>
>
>Sure, but:
>

Unfortunately, I didn't come up with an idea for how to do this in DNS.  This seems like a legitimate issue for the WG to work through.

There are lots of ways to do denial of service attack protection without a CDN.  I would hope it's not so trivial to bounce IANA off the net.  

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 7 Nov 2018 14:42:42 +0100

On Tue 06/Nov/2018 20:39:14 +0100 Scott Kitterman wrote:
> On November 6, 2018 7:17:10 PM UTC, Alessandro Vesely wrote:
>>
>> policies at IANA, while their web policies will continue to be
>> "registered" at PSL.  Does that sound somewhat curious or is it me?>
> Only in a very limited sense.  DMARC currently stops at the organizational
> domain.  This sets up processing and structure for the limited cases where
> DMARC 'above' the organizational domain makes sense.
I appreciate DMARC's concept of "Organizational domain", which is central for
alignment (and reputation tracking, although the latter is unspecified).  This
is Section 3.2 of rfc7489, where the Public Suffix List is introduced.

However, I'm not clear what security concerns, if any, are implied in Section
6.6.3.  For the web case —the Storage Model of rfc6265— the PSL is necessary to
avoid session fixation attacks.  Rfc7849 is rather worried by the opposite
concern, _sub_domains which send evil mail in order to disrupt the reputation
of a parent domain (Section 10.4).  How can a parent domain attack a subdomain
using an evil policy?

> To pick one notional example (real domains, but not reflective of any
> knowledge of domain owner plans or policies):>
> Why shouldn't Google be able to assert DMARC policy over subdomains of
> .google the same way it does over .google.com?  Currently they can't and
> this draft provides policy and mechanism for them to do so if they want.

And what's wrong if Verisign publish a _dmarc.com record?  Section 6.6.3 of
DMARC is meant to avoid too many DNS queries or are there security issues to
worry about?  Which ones?

> Does that clarify it for you?

Only in part.  If the I-D must involve a IANA registry, I'm opposed.  If the
intent is to refine policy discovery algorithms otherwise, possibly in general,
then I'm wholly in favor.

Best
Ale

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Nov 2018 14:41:25 +0000

>then I'm wholly in favor.
The registry is meant to be a solution to the 'what about .com' problem you mention.  It's a solution, not necessarily the best or only one.

I'd suggest we adopt the draft/work item and then try to figure it out.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 8 Nov 2018 07:23:10 +0700

On Wed, Nov 7, 2018 at 9:42 PM Scott Kitterman <[email-masked]> wrote:

>
> The registry is meant to be a solution to the 'what about .com' problem
> you mention.  It's a solution, not necessarily the best or only one.
>

+1 - this is a good problem for the WG to wrestle with; and maybe it can
solve the "PSL problem" if we can constrain the problem space to just the
DMARC issues instead of recreating the DBOUND-solve-for-all morass.

--Kurt

---

From: Steven M Jones <[email-masked]>
Date: Thu, 8 Nov 2018 10:00:30 +0900

> I'd suggest we adopt the draft/work item and then try to figure it out.

+1. We should see where we can get with this topic.

--S.

---

From: tjw ietf <[email-masked]>
Date: Thu, 8 Nov 2018 10:20:05 +0900

Total +1 on this. 

From my high tech gadget

> On Nov 8, 2018, at 10:00, Steven M Jones <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 8 Nov 2018 13:16:50 +0700

>for the WG to work through.

There were two DNS proposals in DBOUND, a more complex one from Casey
Deccio and a simpler one from me.  Mine would certainly work for identifying
org domains.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 8 Nov 2018 13:19:34 +0700

On Thu, Nov 8, 2018 at 1:17 PM John Levine <[email-masked]> wrote:

> >Unfortunately, I didn't come up with an idea for how to do this in DNS.
> This seems like a legitimate issue
> >for the WG to work through.
>

I thought that there was a third one from Andrew too, but let's defer
getting into the discussion until we get this proposal adopted into the WG.

--Kurt

---

From: tjw ietf <[email-masked]>
Date: Thu, 8 Nov 2018 15:42:38 +0900

I remember the two hog mentioned but there could of been a third. 

From my high tech gadget

> On Nov 8, 2018, at 15:19, Kurt Andersen (b) <[email-masked]> wrote:
> 
> I thought that there was a third one from Andrew too, but let's defer getting into the discussion until we get this proposal adopted into the WG.
> 
> --Kurt

---

From: "John R Levine" <[email-masked]>
Date: 8 Nov 2018 13:47:27 +0700

> I remember the two hog mentioned but there could of been a third.

At this point I can't find any of the drafts other than mine, and a 
problem statement mostly by Andrew Sullivan.

In any event, I agree it's worth having the WG take a whack at this, 
keeping in mind that its history is not encouraging.

R's,
John

---

From: tjw ietf <[email-masked]>
Date: Thu, 8 Nov 2018 15:55:34 +0900

Agree with John but from the dns side, simpler solutions tend to get traction faster. 

John May agree with that. 

From my high tech gadget

> On Nov 8, 2018, at 15:47, John R Levine <[email-masked]> wrote:
> 
> At this point I can't find any of the drafts other than mine, and a problem statement mostly by Andrew Sullivan.
> 
> In any event, I agree it's worth having the WG take a whack at this, keeping in mind that its history is not encouraging.
> 
> R's,
> John
> 
>> From my high tech gadget
>>

---

From: tjw ietf <[email-masked]>
Date: Thu, 8 Nov 2018 15:57:12 +0900

Also totally willing to tackle this. 

From my high tech gadget

---

From: "John R Levine" <[email-masked]>
Date: 8 Nov 2018 13:57:15 +0700

> John May agree with that.

Sure.  My DBOUND approach was pretty simple, using no new rrtypes or other 
magic.

>>>> I thought that there was a third one from Andrew too, but let's defer getting into the discussion until we get this proposal adopted into the WG.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 8 Nov 2018 09:53:40 +0100

On Thu 08/Nov/2018 01:23:10 +0100 Kurt Andersen (b) wrote:
> +1 - this is a good problem for the WG to wrestle with;

Agreed

> and maybe it can solve the "PSL problem" if we can constrain the problem
> space to just the DMARC issues instead of recreating the
> DBOUND-solve-for-all morass.

This problem is simpler than DBOUND.  Looking up text policies is common to a
handful of protocols.  A careful wording might make some statements reusable in
general, even if the focus is kept on DMARC.

Best
Ale

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2018 01:19:38 +0700

> general, even if the focus is kept on DMARC.

Sure, the DMARC case is half of what DBOUND tried to tackle.  If DBOUND had
focused just on the DMARC use case, it would've succeeded.

If possible, we should be careful to create a solution that's extensible to
other use cases, not exclusive of them.  Reviewing what DBOUND tried to do
might be very instructive here.

-MSK

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 8 Nov 2018 13:36:53 -0500

On Thu, Nov 8, 2018 at 1:20 PM Murray S. Kucherawy <[email-masked]>
wrote:

> Sure, the DMARC case is half of what DBOUND tried to tackle.  If DBOUND
> had focused just on the DMARC use case, it would've succeeded.
>
> If possible, we should be careful to create a solution that's extensible
> to other use cases, not exclusive of them.  Reviewing what DBOUND tried to
> do might be very instructive here.
>
> -MSK

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 8 Nov 2018 13:37:37 -0500

Stated Very elegantly Murray.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 Nov 2018 01:05:04 +0000

On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" <[email-masked]> wrote:
>> This problem is simpler than DBOUND.  Looking up text policies is
>common
>> to a
>had

Independent of the current discussion about the new PSD DMARC draft, I think this would be a great idea.  

DBOUND was set up to provide, among other things, a specific input that DMARC needs.  The failure of that working group left DMARC with a hole in its design.  Operators use the Mozilla PSL as an ad hoc mechanism to fill that hole.

If we can actually solve the problem in a useful way, then that's great for DMARC.  I propose we add a second work item for this piece of work, since it's independent of PSD DMARC.  If no one else wants to define the work item, I can do it.

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 9 Nov 2018 04:06:02 -0500

I dug up John's old DBOUND draft to refresh myself and it's nice and
straightforward.  I could not find if John shard the link
so here it is:

https://www.ietf.org/archive/id/draft-levine-dbound-dns-01.txt

(hope that is OK John)

t\m

On Thu, Nov 8, 2018 at 8:06 PM Scott Kitterman <[email-masked]> wrote:

> DBOUND was set up to provide, among other things, a specific input that
> DMARC needs.  The failure of that working group left DMARC with a hole in
> its design.  Operators use the Mozilla PSL as an ad hoc mechanism to fill
> that hole.
>
> If we can actually solve the problem in a useful way, then that's great
> for DMARC.  I propose we add a second work item for this piece of work,
> since it's independent of PSD DMARC.  If no one else wants to define the
> work item, I can do it.
>
> Scott K
>

---

From: "John Levine" <[email-masked]>
Date: 9 Nov 2018 17:12:11 +0700

In article <[email-masked]> you write:
>-=-=-=-=-=-

That is fine.  I thought it was pretty straightforward, too.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 9 Nov 2018 05:58:18 -0500

John's document reminded me of how CAA records are done,  They
push all the processing outside the DNS servers.
Like CAA, we should make the RRTYPE require no special resolver processing
and
then we can get the RRTYPE fairly quickly to start.

On Fri, Nov 9, 2018 at 5:12 AM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> >-=-=-=-=-=-
> >

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 9 Nov 2018 12:38:06 +0100

On Fri 09/Nov/2018 02:05:04 +0100 Scott Kitterman wrote:
> On November 8, 2018 6:19:38 PM UTC, "Murray S. Kucherawy" wrote:
>> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely wrote:
>>>
>>> This problem is simpler than DBOUND.
>>>
>>
"Half of DBOUND" is exact.  Apparently, DBOUND tried to simultaneously solve
both the concept of Organizational domain (which is also related to reputation,
responsibility, and possibly liability) and the concept of establishing a
default, easily overridden policy.  We only need the latter half.

>> [...]
By its very nature, PSL defines Organizational domains —the first half.  If you
can exchange session cookies, you share liability.

We don't need to define a topology in the DNS.  We only need a default policy,
established by the parent domain.  Top level TXT RRs can allow some TLD's own
semantics.

DMARC policies also feature reporting addresses.  They are quite different
from, say, the point of contact (POC) linked to IP address space allocations,
but let's note the concept of assigning some responsibility to the entity
owning the first allocation.  So, again, what's wrong with, for example:

_dmarc.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email-masked]"

eh?

Best
Ale
--

---

From: "A. Schulze" <[email-masked]>
Date: Fri, 09 Nov 2018 13:58:29 +0100

> That is fine.  I thought it was pretty straightforward, too.

I read the document. It's clear and simple.

one comment:

       When evaluating "www.foo.example.com", the first query would be to
       "www.foo.example._bound.com".  If the reply to this is "BOUND 0 0
       com", then the second query would go to
       "www.foo._bound.example.com".

I ask myself if DNS query minimisation could be contrary to the query  
sequence for subdomains.
QNAME minimization is normally performed by recursive resolvers. So it  
should not disturb.
But for cases where an application implement that logic it would be  
good to point to RFC 7616.
(in a next document version, if any will happen)

Andreas

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2018 11:32:19 -0500

On 11/8/2018 1:19 PM, Murray S. Kucherawy wrote:
> On Thu, Nov 8, 2018 at 3:53 PM Alessandro Vesely <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     common to a
> Sure, the DMARC case is half of what DBOUND tried to tackle.  If
> DBOUND had focused just on the DMARC use case, it would've succeeded.
>
> If possible, we should be careful to create a solution that's
> extensible to other use cases, not exclusive of them.  Reviewing what
> DBOUND tried to do might be very instructive here.

+1 (although I am not too keen on depending on a new RRTYPE)

I think we should be focusing on working on a DMARC proposed standard, 
Standard Track status document and codify the many implementation 
issues, including:

   - The Author Domain identity (ADID) policy Lookup procedure with
     support for minimal organizational lookup concepts,

   - alignment issues (clarifications),

   - rejection logic (clarifications), and

   - ADID Rewriting implementation logic for List Systems, in order to
     maintain (as much as possible) the original organizational POLICY
     security.

The above are the key implementation issues I am currently going 
through as I am updating/migration/augmenting DMARC into my existing 
ADSP/ATPS/DKIM package but one where we would like to finally add and 
honor the (risky) policy disposition logic (rejection, quarantine).

For all these years, we did the Auth-Res header generation/recording 
with the idea of using a future filtering module. We are at this point 
now, especially since the industry has finally "accepted" after more 
than a decade, the original proof of concept, DKIM Author Domain 
Policy model.

Anyway, there is good new proposed work, but in my opinion, since this 
is really all time consuming (and costly), and it will take a long 
time, I think we should view the new work as part of DMARC and finally 
focus on working on the IETF-sanctioned DMARC "Standard Track" status 
specification and get all the learned implementation details codified 
and worked out.

Have a good weekend,

Hector Santos/CTO
Santronics Software, Inc.

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2018 03:57:49 -0000

In article <[email-masked]>,
>good to point to RFC 7616.

I worry that if we try to enumerate every possible dumb way someone might
implement even a very simple design, we will end up with a very very very
long document.

R's,
John

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2018 11:38:50 +0700

In article <[email-masked]> you write:
>and then we can get the RRTYPE fairly quickly to start.

In my proposal it's just a container, nothing special.

The magic all comes from the closest encloser rule for wildcards, which is
unrelated to rrtype.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Nov 2018 17:08:59 -0500

> draft-ietf-dmarc-psd-00 as a new working group item.

Lots of discussion, and no objections to working on this and starting
with Scott's draft.  So, Scott, please post draft-ietf-dmarc-psd-00,
and let's continue the discussion.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Nov 2018 23:28:51 +0000

>and let's continue the discussion.

Will do.  I'll post it tonight or tomorrow.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Nov 2018 02:24:03 -0500

On Tuesday, November 20, 2018 11:28:51 PM Scott Kitterman wrote:
> >> call for objections.  If there are none by 16 November, we will
> >
> >create
> >

It's posted, queued for chair approval.

Scott K