Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt

[Kurt Andersen (b)]

On Wed, Apr 4, 2018 at 3:32 PM, Brandon Long  wrote:

> Hmm, I guess this means the set of required/optional fields now stretches
> between the DKIM and ARC specs, eh?
>
> Is t the only one that's now optional?
>
> For Seal, I have i, a, s, d, b, cv (removed t based on this thread)
> For AMS, I have i, a, s, c, d, d, b, h, bh
>
> Brandon
>

Looks like that was an unintended casualty of picking up more of the
DKIM-based definitions when we restructured the ARC protocol between -06
and -07. At this point, I don't feel that it's critical to the evaluation
of the ARC chain so making it optional seems reasonable.

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

Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt

[Brandon Long]

Hmm, I guess this means the set of required/optional fields now stretches
between the DKIM and ARC specs, eh?

Is t the only one that's now optional?

For Seal, I have i, a, s, d, b, cv (removed t based on this thread)
For AMS, I have i, a, s, c, d, d, b, h, bh

Brandon

On Tue, Apr 3, 2018 at 4:05 PM Kurt Andersen (b)  wrote:

> Please implement -13, but there are almost no protocol changes between -6
> and -13. It's mostly editorial. We may have made some tags optional but if
> Google wants 'em, it's probably best to include them, but that doesn't mean
> you aren't implementing -13.
>
> --Kurt
>
> On Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris  wrote:
>
>> On 21/03/18 15:18, Murray S. Kucherawy wrote:
>> > On Wed, Mar 21, 2018 at 3:00 PM,  wrote:
>> >
>> >> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt
>> >> has been successfully submitted by Kurt Andersen and posted to the
>> >> IETF repository.
>>
>> I see that Google are still listed as implementing Version 6 -
>> and indeed, if you don't supply a t= tag in the AS (which is not
>> required, as far as I can find in Version 13) then gmail.com says:
>>
>>   "arc=fail (missing mandatory fields);"
>>
>> in it's A-R.
>>
>> Which should I implement?
>> De-jure, or de-facto (and too-big-to-fail)?
>>
>> --
>> Cheers,
>>   Jeremy
>>
>> ___
>> 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 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

[Peter M. Goldstein]

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.

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.

Best,

Peter

On Wed, Apr 4, 2018 at 10:45 AM, Kurt Andersen (b)  wrote:

> 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 > g > wrote:
>>
>>> Currently defined policy discovery https://tools.ietf.org/html/rf
>>> c7489#section-6.6.3
>>>
>>> This begs the question (for which a real example now exists): what if a
>>> listed suffix (TLD?) itself has a DMARC record?  Is the intent and expected
>>> behaviour that the TLD entry override all instances where a record is not
>>> explicitly defined?  Or should there also be an Organizational level check
>>> along the way?  Or something else?
>>>
>>> Current use case:
>>> qld.gov.au is in the PSL, *and* has a DMARC record of its own.  When
>>> looking up whether company.qld.gov.au  has
>>> a DMARC record, all public tools I tried say 'no record' except MXtoolbox,
>>> which shows that the entry inherits from qld.gov.au
>>>
>>>
>>>
>>> ___
>>> dmarc mailing list
>>> dmarc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>>>
>>
>>
>> --
>> PAUL ROCK
>> *Sr Software Dev Engineer* | AOL Mail
>> P: 703-265-5734 | C: 703-980-8380
>> AIM: paulsrock
>> 22070 Broderick Dr.| Dulles, VA | 20166-9305
>>
>> ___
>> 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 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  > wrote:
>
>> Currently defined policy discovery https://tools.ietf.org/html/rf
>> c7489#section-6.6.3
>>
>> This begs the question (for which a real example now exists): what if a
>> listed suffix (TLD?) itself has a DMARC record?  Is the intent and expected
>> behaviour that the TLD entry override all instances where a record is not
>> explicitly defined?  Or should there also be an Organizational level check
>> along the way?  Or something else?
>>
>> Current use case:
>> qld.gov.au is in the PSL, *and* has a DMARC record of its own.  When
>> looking up whether company.qld.gov.au  has a
>> DMARC record, all public tools I tried say 'no record' except MXtoolbox,
>> which shows that the entry inherits from qld.gov.au
>>
>>
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>>
>
>
> --
> PAUL ROCK
> *Sr Software Dev Engineer* | AOL Mail
> P: 703-265-5734 | C: 703-980-8380
> AIM: paulsrock
> 22070 Broderick Dr.| Dulles, VA | 20166-9305
>
> ___
> 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

[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 
wrote:

> Currently defined policy discovery https://tools.ietf.org/html/rf
> c7489#section-6.6.3
>
> This begs the question (for which a real example now exists): what if a
> listed suffix (TLD?) itself has a DMARC record?  Is the intent and expected
> behaviour that the TLD entry override all instances where a record is not
> explicitly defined?  Or should there also be an Organizational level check
> along the way?  Or something else?
>
> Current use case:
> qld.gov.au is in the PSL, *and* has a DMARC record of its own.  When
> looking up whether company.qld.gov.au has a DMARC record, all public
> tools I tried say 'no record' except MXtoolbox, which shows that the entry
> inherits from qld.gov.au
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>


-- 
PAUL ROCK
*Sr Software Dev Engineer* | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] inheritance and public suffix list

[Tomki Camp]

Currently defined policy discovery https://tools.ietf.org/html/
rfc7489#section-6.6.3

This begs the question (for which a real example now exists): what if a
listed suffix (TLD?) itself has a DMARC record?  Is the intent and expected
behaviour that the TLD entry override all instances where a record is not
explicitly defined?  Or should there also be an Organizational level check
along the way?  Or something else?

Current use case:
qld.gov.au is in the PSL, *and* has a DMARC record of its own.  When
looking up whether company.qld.gov.au has a DMARC record, all public tools
I tried say 'no record' except MXtoolbox, which shows that the entry
inherits from qld.gov.au
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc