Re: [dmarc-ietf] Minutes from IETF 112

2021-11-30 Thread Jesse Thompson
On 11/18/2021 1:44 PM, John Levine wrote:
> It appears that Todd Herr   said:
>> It seems to me that DMARC already provides the ability for
>> security.example.edu to ensure that no other part of example.edu can send
>> mail on their behalf. To accomplish this, security.example.edu can today:
>>
>>   - Publish an SPF record listing only hosts under its direct control, a
>>   record which ends with "-all"
>>   - Ensure that only hosts under its control can DKIM sign messages using "
>>   security.example.edu" as the signing domain, by making sure that its
>>   private DKIM signing key is only deployed to hosts under its control
>>   - Publish a DMARC policy record that includes the following three tags
>>   and values:
>>  - p=reject
>>  - adkim=s
>>  - aspf=s
> 
> Agreed.  That would work fine.
> 
> An sp=reject in both security.example.edu and its org domain would also be a 
> good idea.

(Sorry, AWOL due to new employment, only tertiary involved in matters relevant 
to this discussion these days. Also haven't read this list for about a year.) 

Here's my best recollection of the issue:

p=(quarantine|reject) isn't the real issue for example.edu; just tell 
departments to use their sub.example.edu domains (localized control/branding 
makes people happy, more or less.) [1]  p=(quarantine|reject) for 
sub.example.edu isn't really an issue either; just a microcosm.

The problem is when there are departments with lots of systems all sending from 
hostname.sub.example.edu. So, sub.example.edu needs time to reconcile (or 
doesn't care to), wants to publish sp=none for sub.example.edu; but can't 
because the org domain's sp policy is the only one that matters, since there is 
no tree walk from hostname.sub.example.edu to sub.example.edu. Meanwhile, 
example.edu can't move beyond sp=none.

Also, the lack of control down the tree means that example.edu would never be 
able to use aspf=r, which is restricting a useful feature from organizations 
that could probably benefit the most from the flexibility it provides. I don't 
think that inability to use adkim=r is as much of an issue since individual 
CNAME records are easy to create under example.edu. This if off topic in my 
mind, but it was mentioned above.

Jesse

[1] most complex institutions probably aren't so willing to hand out subdomains 
like candy


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


Re: [dmarc-ietf] Minutes from IETF 112

2021-11-18 Thread Dotzero
On Thu, Nov 18, 2021 at 3:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Don't the alignment rules allow any DKIM signature for the organization to
> validate any FROM address for the organization -- up, down, or sideways?
>
> To use the sideways example, this means that an RFC 5322.From address of "
> u...@security.example.edu"  can be validated for DMARC:
> - by SPF PASS on an RFC5321.MailFrom address of "
> u...@humanities.example.edu", or
> - by a verified DKIM signature issued by d=Humanities.Example.Edu using a
> public key published in the Humanities sub-tree.
>
> That, at least, is my understanding.
>
> Doug
>

Your understanding is incorrect. Please review what the adkim and aspf tags
do. In the strict mode the domain must be an exact match. In the relaxed
mode it must either be an exact match or match the parent domain. In no
case will "sister" subdomains produce a pass.

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


Re: [dmarc-ietf] Minutes from IETF 112

2021-11-18 Thread Douglas Foster
Don't the alignment rules allow any DKIM signature for the organization to
validate any FROM address for the organization -- up, down, or sideways?

To use the sideways example, this means that an RFC 5322.From address of "
u...@security.example.edu"  can be validated for DMARC:
- by SPF PASS on an RFC5321.MailFrom address of "u...@humanities.example.edu",
or
- by a verified DKIM signature issued by d=Humanities.Example.Edu using a
public key published in the Humanities sub-tree.

That, at least, is my understanding.

Doug


On Thu, Nov 18, 2021 at 9:08 AM Todd Herr  wrote:

> On Thu, Nov 18, 2021 at 8:11 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>>
>> Do we want to provide a sub-tree alignment option?
>>
>> Suppose that “security.example.edu” does not want any other part of “
>> example.edu” to be sending emails on their behalf, so they want to limit
>> alignment to their sub-tree only.   This approach becomes feasible if (a)
>> we use tree walk and (b) we implement a clause which indicates “top of tree
>> for alignment purposes”.I suspect that this would have some appeal to
>> parts of some universities and other complex organizations, but again we
>> would need those organizations to affirm that it would be useful.
>>
>>
>>
> It seems to me that DMARC already provides the ability for
> security.example.edu to ensure that no other part of example.edu can send
> mail on their behalf. To accomplish this, security.example.edu can today:
>
>- Publish an SPF record listing only hosts under its direct control, a
>record which ends with "-all"
>- Ensure that only hosts under its control can DKIM sign messages
>using "security.example.edu" as the signing domain, by making sure
>that its private DKIM signing key is only deployed to hosts under its
>control
>- Publish a DMARC policy record that includes the following three tags
>and values:
>   - p=reject
>   - adkim=s
>   - aspf=s
>
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Minutes from IETF 112

2021-11-18 Thread John Levine
It appears that Todd Herr   said:
>It seems to me that DMARC already provides the ability for
>security.example.edu to ensure that no other part of example.edu can send
>mail on their behalf. To accomplish this, security.example.edu can today:
>
>   - Publish an SPF record listing only hosts under its direct control, a
>   record which ends with "-all"
>   - Ensure that only hosts under its control can DKIM sign messages using "
>   security.example.edu" as the signing domain, by making sure that its
>   private DKIM signing key is only deployed to hosts under its control
>   - Publish a DMARC policy record that includes the following three tags
>   and values:
>  - p=reject
>  - adkim=s
>  - aspf=s

Agreed.  That would work fine.

An sp=reject in both security.example.edu and its org domain would also be a 
good idea.

R's,
John

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


Re: [dmarc-ietf] Minutes from IETF 112

2021-11-18 Thread Todd Herr
On Thu, Nov 18, 2021 at 8:11 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> Do we want to provide a sub-tree alignment option?
>
> Suppose that “security.example.edu” does not want any other part of “
> example.edu” to be sending emails on their behalf, so they want to limit
> alignment to their sub-tree only.   This approach becomes feasible if (a)
> we use tree walk and (b) we implement a clause which indicates “top of tree
> for alignment purposes”.I suspect that this would have some appeal to
> parts of some universities and other complex organizations, but again we
> would need those organizations to affirm that it would be useful.
>
>
>
It seems to me that DMARC already provides the ability for
security.example.edu to ensure that no other part of example.edu can send
mail on their behalf. To accomplish this, security.example.edu can today:

   - Publish an SPF record listing only hosts under its direct control, a
   record which ends with "-all"
   - Ensure that only hosts under its control can DKIM sign messages using "
   security.example.edu" as the signing domain, by making sure that its
   private DKIM signing key is only deployed to hosts under its control
   - Publish a DMARC policy record that includes the following three tags
   and values:
  - p=reject
  - adkim=s
  - aspf=s


-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Minutes from IETF 112

2021-11-18 Thread Douglas Foster
Consensus on Tree Walk?

A comment in the minutes suggested that consensus was forming around Tree
Walk for Policy Discovery.   I do not have that impression.  Instead, the
"strongly favor" and "strongly oppose" voices seem about equal, with the
balance determined by those who, like myself, are tepidly in favor.


Does Tree Walk eliminate the PSL?

I am concerned that support for Tree Walk is driven by antipathy to the
PSL, rather than for the functional capabilities that Tree Walk provides.
The PSL is needed for alignment, which is essential to the determination of
the PASS or FAIL result.  Eliminating use of the PSL for policy discovery
is trivial unless it is also replaced for alignment.We have discussed
three options for alignment:

· The publicsuffix.org list which has conspicuous limitations.

· Downward-only alignment, which has been rejected as incompatible
with current practice.

· DNS flags, a topic which was apparently not pursued during the
meeting.


Do Complex Organizations want policy flexibility?

Granular DMARC policies can be achieved under DMARCv1 by using many policy
records with p=.   Tree walk simplifies that process by allowing
intermediate subtrees to be configured using sp= policies.We
need input from complex organizations to indicate whether this capability
is something that they would value and use.


Do we want to provide a sub-tree alignment option?

Suppose that “security.example.edu” does not want any other part of “
example.edu” to be sending emails on their behalf, so they want to limit
alignment to their sub-tree only.   This approach becomes feasible if (a)
we use tree walk and (b) we implement a clause which indicates “top of tree
for alignment purposes”.I suspect that this would have some appeal to
parts of some universities and other complex organizations, but again we
would need those organizations to affirm that it would be useful.


Doug Foster

On Wed, Nov 17, 2021 at 9:40 AM Barry Leiba  wrote:

> Minutes from the DMARC session at IETF 112 are posted on the meeting
> materials page:
> https://datatracker.ietf.org/meeting/112/session/dmarc
>
> Direct link to the minutes:
> https://datatracker.ietf.org/meeting/112/materials/minutes-112-dmarc.html
>
> Corrections are welcome.
>
> Barry
>
> ___
> 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] Minutes from IETF 112

2021-11-17 Thread Barry Leiba
Minutes from the DMARC session at IETF 112 are posted on the meeting
materials page:
https://datatracker.ietf.org/meeting/112/session/dmarc

Direct link to the minutes:
https://datatracker.ietf.org/meeting/112/materials/minutes-112-dmarc.html

Corrections are welcome.

Barry

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