Re: [dmarc-ietf] inheritance and public suffix list

[John R Levine]

On Tue, 10 Apr 2018, Kurt Andersen (b) wrote:

Registries make RSEP requests all the time.  They're tedious and fairly
expensive, but the process is straightforward.


Is this something that could be within the remit of the dmarc-wg if we
wanted to pave the way with ICANN across the board?


I believe that RSEPs have to be one registry at a time.  The registry 
can apply for all of its domains.  If we wanted it to apply to everyone, 
that would be a contract change.


On the other hand, few of the private TLDs are used much, and I see very 
little mail from any of them, real or otherwise, so it doesn't seem super 
urgent.


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] inheritance and public suffix list

[Kurt Andersen (b)]

On Tue, Apr 10, 2018 at 1:44 PM, John Levine  wrote:

> In article <91efb193-9a81-4626-92ca-bf116826f...@uniregistry.link> you
> write:
>
>  This is the relevant text from
> >https://newgtlds.icann.org/sites/default/files/
> agreements/agreement-approved-31jul17-en.html
>
> But the paragraph at the end of that section, Exhibit A, says:
>
>  If Registry Operator wishes to place any DNS resource record type or
>  class into its TLD DNS service (other than those listed in Sections
>  1.1 or 1.2 above), it must describe in detail its proposal and submit
>  a Registry Services Evaluation Process (RSEP) request.  This will be
>  evaluated per RSEP to determine whether the service would create a
>  risk of a meaningful adverse impact on security or stability of the
>  DNS.  Registry Operator recognizes and acknowledges that a service
>  based on the use of less-common DNS resource records and/or classes in
>  the TLD zone, even if approved, might not work as intended for all
>  users due to lack of software support.
>
> Registries make RSEP requests all the time.  They're tedious and fairly
> expensive, but the process is straightforward.


Is this something that could be within the remit of the dmarc-wg if we
wanted to pave the way with ICANN across the board?

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

Re: [dmarc-ietf] inheritance and public suffix list

[John Levine]

In article  you write:
>> I think _dmarc as a TXT record is fairly well known. Is there anything 
>> that would specifically prohibit this?
>
>gTLDs are not permitted to place TXT records in their zones.

That's mostly right.  There is detailed language in the registry contracts about
what's allowed in the TLD zones, dating back to the sitefinder fiasco
when Verisign put a *.com wildcard in the .com zone.  

See Exhibit A in the Base Registry Agreement:

https://www.icann.org/resources/pages/registries/registries-agreements-en

TLDs are allowed to put in txt records for zone status.  See, for example,
the TXT records at __zone_status.sharp or at total.

I doubt that anyone would object to a _dmarc. TXT record, but
it's debatable whether it would qualify as zone status.  Otherwise the
registry would have to make an RSEP request to ICANN for permission to
do so, which is expensive and slow.

https://www.icann.org/resources/pages/rsep-2014-02-19-en

R's,
John

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

Re: [dmarc-ietf] inheritance and public suffix list

[Kurt Andersen (b)]

On Thu, Apr 5, 2018 at 1:06 PM, Luis E. Muñoz  wrote:

> On 5 Apr 2018, at 13:04, MH Michael Hammer (5304) wrote:
>
> I think _dmarc as a TXT record is fairly well known. Is there anything
> that would specifically prohibit this?
>
> gTLDs are not permitted to place TXT records in their zones.
>
That seems like a regrettable limitation. Would we need further definition
around the "well known" aspect from IETF to fix this or would it require
ICANN-level changes to contractual terms?

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

Re: [dmarc-ietf] inheritance and public suffix list

[Luis E. Muñoz]

On 5 Apr 2018, at 13:04, MH Michael Hammer (5304) wrote:

I think _dmarc as a TXT record is fairly well known. Is there anything 
that would specifically prohibit this?


gTLDs are not permitted to place TXT records in their zones.

Luis Muñoz
Director, Registry Operations


http://www.uniregistry.link/
2161 San Joaquin Hills Road
Newport Beach, CA 92660

Office +1 949 706 2300 x 4242
l...@uniregistry.link
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] inheritance and public suffix list

[Luis E. Muñoz]

On 4 Apr 2018, at 11:19, Peter M. Goldstein wrote:

3. *New gTLDs* - With the recent expansion of the list of TLDs, many 
of the
new TLDs are controlled by a single organization.  It may make sense 
to
allow those gTLDs to define a DMARC record on the TLD itself or on 
some
'default' domain - both for administrative simplification and to 
ensure
against abuse.  It may be possible to handle this case outside of a 
lookup
change with wildcarded DNS records, but I know it's something that's 
come

up in discussions with some of those TLD owners.


Keep in mind that gTLD operators are restricted in the records they can 
include in their respective DNS zones. This would require the use of a 
well known name specifically for this purpose.


Best regards

Luis Muñoz
Director, Registry Operations


http://www.uniregistry.link/
2161 San Joaquin Hills Road
Newport Beach, CA 92660
l...@uniregistry.link
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] inheritance and public suffix list

[Alessandro Vesely]

On Thu 05/Apr/2018 17:19:10 +0200 Kurt Andersen (b) wrote: 
> On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein wrote:
> 
>>> Hi,
>>>
>>> These are both a species of the same problem, yes.  The solution so
>>> far has been to say that you're supposed to match the longest of the
>>> candidate set...
>>
>>
>> Right.  And the suggestion that Kurt made was to modify this to:
>>
>> 1. Check the domain itself
>> 2. Check the longest of the organizational domain candidate set
>> 3. Check the shortest of the organizational domain candidate set
>>
> 
> Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC
> spec itself):
> 
> 2.  (from 3.2 step 3) "search the PSL for the name that matches the largest
> number of labels found in the subject DNS domain. Let that number be "x". /
> (step 4) Construct a new DNS domain name using the name matched form the
> PSL and prefixing to it the "x+1"th label"...[this] is the org domain.
> 
> 3. Check the name created from the "x" labels determined in step 2 (hence
> my designation as "org-1").
> 
> These are not the same as "longest" and "shortest" names from the org
> domain candidate set unless the psl code follows that specified
> construction algorithm.

FWIW, here's the wording of the PSL(1) man page:

   --print-unreg-domain
  Returned data: the longest public suffix part for each domain.

   --print-reg-domain
  Returned data: the shortest private suffix part for each domain.

[...]
COPYRIGHT
   libpsl and `psl' are copyright © 2014-2016 Tim Ruehsen  under  an  MIT-
   style License.
   This  documentation  was  written by Daniel Kahn Gillmor for the Debian
   project, but may be used by others under the  same  license  as  libpsl
   itself.

psl 0.13.0 July 2016PSL(1)

-- 


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

Re: [dmarc-ietf] inheritance and public suffix list

[Peter M. Goldstein]

Kurt,

Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC
> spec itself):
> 2.  (from 3.2 step 3) "search the PSL for the name that matches the
> largest number of labels found in the subject DNS domain. Let that number
> be "x". / (step 4) Construct a new DNS domain name using the name matched
> form the PSL and prefixing to it the "x+1"th label"...[this] is the org
> domain.
> 3. Check the name created from the "x" labels determined in step 2 (hence
> my designation as "org-1").
> These are not the same as "longest" and "shortest" names from the org
> domain candidate set unless the psl code follows that specified
> construction algorithm.


Ah, I misunderstood the proposal.  I viewed your '-1' as subtracting an
index against the PSL set, not subtracting an actual label from the
organizational domain.

I'm also a little confused by terminology - "org-1" above is just the
largest number of labels entry on the PSL, isn't it?

In that case, yes it would address point #3, but would also potentially
introduce problems for the county code TLDs (does a country-level registrar
have the right to dictate policy for all domains in the country?) and some
of the non-sponsored generics (.com, .edu, .org, etc.)

The cardinality is still a potential issue, because you may want the DMARC
management to devolve to the most general authority in the tree.  But as I
said, it's easy enough to state "DMARC doesn't handle that case" if it's
not an effective abuse vector or a significant management problem.

Best,

Peter


On Thu, Apr 5, 2018 at 8:19 AM, Kurt Andersen (b)  wrote:

> On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein <
> peter.m.goldst...@gmail.com> wrote:
>
>> Hi,
>>
>> These are both a species of the same problem, yes.  The solution so
>>> far has been to say that you're supposed to match the longest of the
>>> candidate set...
>>
>>
>> Right.  And the suggestion that Kurt made was to modify this to:
>>
>> 1. Check the domain itself
>> 2. Check the longest of the organizational domain candidate set
>> 3. Check the shortest of the organizational domain candidate set
>>
>
> Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC
> spec itself):
>
> 2.  (from 3.2 step 3) "search the PSL for the name that matches the
> largest number of labels found in the subject DNS domain. Let that number
> be "x". / (step 4) Construct a new DNS domain name using the name matched
> form the PSL and prefixing to it the "x+1"th label"...[this] is the org
> domain.
>
> 3. Check the name created from the "x" labels determined in step 2 (hence
> my designation as "org-1").
>
> These are not the same as "longest" and "shortest" names from the org
> domain candidate set unless the psl code follows that specified
> construction algorithm.
>
> Which covers the case where that candidate set has cardinality 2 or less,
>> but leaves some question about cases where the cardinality is 3 or more.  I
>> don't know how common the latter is - not sure if we have stats on that.
>>
>
> I still don't know why the cardinality matters with the approach I've
> proposed.
>
> Do you mean this _across_ TLDs (e.g. the "variants" case such as
>>> differnet spellings of China depending on the writing system) or do
>>> you just mean that the top most label and everything flowing down from
>>> there is all under the same policy?
>>
>>
>> The latter.
>>
>> To be more clear, there are now a significant number of TLDs that are
>> managed exclusively by one entity (e.g. .microsoft, .google) as well as
>> other TLDs that make specific guarantees around DMARC (e.g. .bank). In
>> those cases it may make sense to give the registry owners some defined
>> mechanism for imposing global DMARC policy across the TLD.  This is
>> especially important for organizational domain names that don't resolve for
>> that TLD.
>>
>> So, for example, let's consider an email seemingly sent from
>> supp...@iamareal..bank .  A query to the domain iamareal.bank returns an
>> NXDOMAIN, as does the a TXT query to the corresponding DMARC record
>> _dmarc.iamareal.bank domain.  So there's no DMARC policy in place.  So a
>> receiver may wind up delivering this email to the inbox, especially if it
>> passes SPF and DKIM in an unaligned fashion.
>>
>
> If .bank, i.e. "1", is the largest number of labels found in the PSL (step
> 2), why would this approach not protect NXDOMAINs under .bank?
>
> --Kurt
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] inheritance and public suffix list

[Kurt Andersen (b)]

On Thu, Apr 5, 2018 at 7:22 AM, Peter M. Goldstein <
peter.m.goldst...@gmail.com> wrote:

> Hi,
>
> These are both a species of the same problem, yes.  The solution so
>> far has been to say that you're supposed to match the longest of the
>> candidate set...
>
>
> Right.  And the suggestion that Kurt made was to modify this to:
>
> 1. Check the domain itself
> 2. Check the longest of the organizational domain candidate set
> 3. Check the shortest of the organizational domain candidate set
>

Not quite. Steps 2 & 3 would be (adapted from the language of the DMARC
spec itself):

2.  (from 3.2 step 3) "search the PSL for the name that matches the largest
number of labels found in the subject DNS domain. Let that number be "x". /
(step 4) Construct a new DNS domain name using the name matched form the
PSL and prefixing to it the "x+1"th label"...[this] is the org domain.

3. Check the name created from the "x" labels determined in step 2 (hence
my designation as "org-1").

These are not the same as "longest" and "shortest" names from the org
domain candidate set unless the psl code follows that specified
construction algorithm.

Which covers the case where that candidate set has cardinality 2 or less,
> but leaves some question about cases where the cardinality is 3 or more.  I
> don't know how common the latter is - not sure if we have stats on that.
>

I still don't know why the cardinality matters with the approach I've
proposed.

Do you mean this _across_ TLDs (e.g. the "variants" case such as
>> differnet spellings of China depending on the writing system) or do
>> you just mean that the top most label and everything flowing down from
>> there is all under the same policy?
>
>
> The latter.
>
> To be more clear, there are now a significant number of TLDs that are
> managed exclusively by one entity (e.g. .microsoft, .google) as well as
> other TLDs that make specific guarantees around DMARC (e.g. .bank). In
> those cases it may make sense to give the registry owners some defined
> mechanism for imposing global DMARC policy across the TLD.  This is
> especially important for organizational domain names that don't resolve for
> that TLD.
>
> So, for example, let's consider an email seemingly sent from
> supp...@iamareal..bank .  A query to the domain iamareal.bank returns an
> NXDOMAIN, as does the a TXT query to the corresponding DMARC record
> _dmarc.iamareal.bank domain.  So there's no DMARC policy in place.  So a
> receiver may wind up delivering this email to the inbox, especially if it
> passes SPF and DKIM in an unaligned fashion.
>

If .bank, i.e. "1", is the largest number of labels found in the PSL (step
2), why would this approach not protect NXDOMAINs under .bank?

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

Re: [dmarc-ietf] inheritance and public suffix list

[Peter M. Goldstein]

Hi,

These are both a species of the same problem, yes.  The solution so
> far has been to say that you're supposed to match the longest of the
> candidate set...


Right.  And the suggestion that Kurt made was to modify this to:

1. Check the domain itself
2. Check the longest of the organizational domain candidate set
3. Check the shortest of the organizational domain candidate set

Which covers the case where that candidate set has cardinality 2 or less,
but leaves some question about cases where the cardinality is 3 or more.  I
don't know how common the latter is - not sure if we have stats on that.

Do you mean this _across_ TLDs (e.g. the "variants" case such as
> differnet spellings of China depending on the writing system) or do
> you just mean that the top most label and everything flowing down from
> there is all under the same policy?


The latter.

To be more clear, there are now a significant number of TLDs that are
managed exclusively by one entity (e.g. .microsoft, .google) as well as
other TLDs that make specific guarantees around DMARC (e.g. .bank). In
those cases it may make sense to give the registry owners some defined
mechanism for imposing global DMARC policy across the TLD.  This is
especially important for organizational domain names that don't resolve for
that TLD.

So, for example, let's consider an email seemingly sent from
supp...@iamareal.bank .  A query to the domain iamareal.bank returns an
NXDOMAIN, as does the a TXT query to the corresponding DMARC record
_dmarc.iamareal.bank domain.  So there's no DMARC policy in place.  So a
receiver may wind up delivering this email to the inbox, especially if it
passes SPF and DKIM in an unaligned fashion.

But to an end user it looks like this is an email from a '.bank' domain,
which undermines the .bank TLDs goal of providing a higher trust set of
domains.  And it is therefore attractive to bad actors as a possible
channel of abuse.

The question is whether the DMARC lookup scheme should somehow address this
issue.  Alternately, we could simply say that this is a case that DMARC
itself doesn't handle, and that the registry owner may choose to modify
their DNS responses to ensure they always return a DMARC record for any
organizational domain on that TLD.

Best,

Peter

On Thu, Apr 5, 2018 at 6:07 AM, Andrew Sullivan 
wrote:

> Hi,
>
> On Wed, Apr 04, 2018 at 11:19:20AM -0700, Peter M. Goldstein wrote:
>
> > it definitely seems clear that some sort of modification to the lookup
> > algorithm would be required to address the issue.
>
> Right.  We attempted to specify some system that would sort this all
> out over in the DBOUND WG, but that WG failed because of disagreement
> about whether we cared about web-type (cross-site issues, cookies,
> ) problems or anti-spam (roughly, "parent's policy wins") issues.
>
> > 1. A domain which contains two public suffixes - i.e. abc.gov.uk, which
> > contains the public suffixes .gov.uk, .uk.
>
> > 2. A domain which contains three or more public suffixes - I'm not sure
> given
> > the content of the public suffix list today that you can actually
> construct one
> > of these.
>
> These are both a species of the same problem, yes.  The solution so
> far has been to say that you're supposed to match the longest of the
> candidate set.  There is a possible hitch because of non-terminals,
> which never have any real records in them but that might have
> subordinate things that are also public suffixes.  Except for .jp (and
> I'm not sure there), I think nobody is doing that any more.  Some of
> us argued that the system ought to accommodate such uses anyway, and
> others argued that we shouldn't solve any problem nobody has today
> (and tell people who later invent this problem, "Don't do that").
>
>
> > 3. New gTLDs - With the recent expansion of the list of TLDs, many of
> the new
> > TLDs are controlled by a single organization.  It may make sense to
> allow those
> > gTLDs to define a DMARC record on the TLD itself or on some 'default'
> domain -
> > both for administrative simplification and to ensure against abuse.
>
> Do you mean this _across_ TLDs (e.g. the "variants" case such as
> differnet spellings of China depending on the writing system) or do
> you just mean that the top most label and everything flowing down from
> there is all under the same policy?
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> 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] inheritance and public suffix list

[Kurt Andersen (b)]

On Wed, Apr 4, 2018 at 11:19 AM, Peter M. Goldstein <
peter.m.goldst...@gmail.com> wrote:

> Kurt,
>
> As you note, this issue has been discussed on-list (and off) a few times.
> And it definitely seems clear that some sort of modification to the lookup
> algorithm would be required to address the issue.
>
> As part of that discussion, there are a few scenarios that I think should
> be considered:
>
> 1. *A domain which contains two public suffixes* - i.e. abc.gov.uk, which
> contains the public suffixes .gov.uk, .uk.  In the proposed lookup scheme
> we'd be assuming that the manager of the registry for the "last"
> organizational domain represented a controlling authority that should be
> able to impose DMARC policy on and view data for all subdomains.  I'm not
> sure whether that's true in all cases, and that would have bearing on your
> proposal.
>
> 2. *A domain which contains three or more public suffixes* - I'm not sure
> given the content of the public suffix list today that you can actually
> construct one of these.  But from what I can see, there's nothing
> restricting a future update of the public suffix list that would allow such
> a domain.  If we update the lookup algorithm, we should at least speak to
> this case - even if it's just to say we ignore it.
>

This is quite easily accomplished, as are scenarios where there are public
blocks embedded "down chain" with intervening private domains in between.
See the notes from the DBOUND working group if you want to delve into these
sorts of things.

3. *New gTLDs* - With the recent expansion of the list of TLDs, many of the
> new TLDs are controlled by a single organization.  It may make sense to
> allow those gTLDs to define a DMARC record on the TLD itself or on some
> 'default' domain - both for administrative simplification and to ensure
> against abuse.  It may be possible to handle this case outside of a lookup
> change with wildcarded DNS records, but I know it's something that's come
> up in discussions with some of those TLD owners.
>
> I'd suggest that if we're going to make a modification to the lookup
> algorithm that we consider each of these scenarios, and ensure there's
> consensus on how they should each be addressed.
>
> To your specific question, I think it's desirable to address these cases
> and it's worth discussing how the lookup algorithm can be modified to do so.
>

My opinion is that we should strive for simplicity and attempt to craft a
proposal which would handle both scenarios 1 & 2 in a single mechanism. It
would be even better if we can solve for case #3 with the same solution :-)

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

Re: [dmarc-ietf] inheritance and public suffix list

[Kurt Andersen (b)]

Apologies for the top-posting, but this is exactly the scenario that has
been discussed earlier on the list:
https://www.ietf.org/mail-archive/web/dmarc/current/msg04151.html as well
as during the recent IETF101 meeting:
https://datatracker.ietf.org/doc/minutes-101-dmarc/

The problem really is (at the moment) that there is no basis in the lookup
algorithm to ever query the "last public" domain (aka "org-1"). Would the
community be open to adding a third potential lookup to the algorithm?
   1 - check the domain itself
   2 - check the org domain
   3 - check org-1

--Kurt

On Wed, Apr 4, 2018 at 9:52 AM, Paul Rock  wrote:

> Considering that the qld.gov..au  record includes an
> sp tag, I'd say that they intend and expect that the TLD entry does exactly
> that - puts DMARC reporting in place for all subdomains that don't have
> their own record.
>
> On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp 

Re: [dmarc-ietf] inheritance and public suffix list

[Paul Rock]

Considering that the qld.gov.au record includes an sp tag, I'd say that
they intend and expect that the TLD entry does exactly that - puts DMARC
reporting in place for all subdomains that don't have their own record.

On Tue, Apr 3, 2018 at 3:02 PM, Tomki Camp