[dmarc-ietf] dmarc - Requested session has been scheduled for IETF 110
Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmarc Session 1 (1:00 requested) Wednesday, 10 March 2021, Session II 1530-1630 Room Name: Room 2 size: 502 - iCalendar: https://datatracker.ietf.org/meeting/110/sessions/dmarc.ics Request Information: - Working Group Name: Domain-based Message Authentication, Reporting Conformance Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 76 Conflicts to Avoid: Chair Conflict: dnsop dprive cfrg kitten emailcore Technology Overlap: saag uta extra jmap cbor People who must be present: Alexey Melnikov Murray Kucherawy Seth Blank Tim Wicinski Resources Requested: Special Requests: - ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [EXTERNAL] Re: Ticket #64 - Contained Data PII Concerns
Yes, very true. Again as an individual, I think it's worth calling out explicitly in the draft, simply because it does seem to cause friction with implementations. On Fri, Feb 12, 2021 at 1:23 PM John R Levine wrote: > > In the data itself, there are summaries of IP addresses and > authentication > > statuses of mail that fall into three categories: 1) mail that is > > authenticated by the domain, 2) mail that fails to authenticate as the > > domain, and 3) mail that is wholly unauthenticated. From a domain owner > > perspective, this means they get reports of mail that is 1) authorized by > > them, 2) not authorized by them, or 3) broken by forwarding or other > > rewriting by an intermediary. ... > > All true, but more to the point, the reports include IP addresses and > domain names of mail servers and DKIM signers, not IP or e-mail addresses > of individual users. There's no PII other than in the extreme case that > the domain has only a single user so all of the mail can be attributed to > that user. > > R's, > John > > PS: updated the ticket title to say aggregate reports > > PPS: that extreme case lets me tell things like how many NANOG subscribers > get their mail at gmail. > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 ` 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] [EXTERNAL] Re: Ticket #64 - Contained Data PII Concerns
In the data itself, there are summaries of IP addresses and authentication statuses of mail that fall into three categories: 1) mail that is authenticated by the domain, 2) mail that fails to authenticate as the domain, and 3) mail that is wholly unauthenticated. From a domain owner perspective, this means they get reports of mail that is 1) authorized by them, 2) not authorized by them, or 3) broken by forwarding or other rewriting by an intermediary. ... All true, but more to the point, the reports include IP addresses and domain names of mail servers and DKIM signers, not IP or e-mail addresses of individual users. There's no PII other than in the extreme case that the domain has only a single user so all of the mail can be attributed to that user. R's, John PS: updated the ticket title to say aggregate reports PPS: that extreme case lets me tell things like how many NANOG subscribers get their mail at gmail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [EXTERNAL] Re: Ticket #64 - Contained Data PII Concerns
As an individual, part of the reason for this ticket is that some receivers do not send aggregate reports, as they're unclear on whose data is being provided to whom (which then spirals into issues of legalities). While the IETF cannot weigh in on legalities, it can make clear the intention of whose data is being transmitted in the report. I believe clarifying this will enable more reports to flow. My thoughts, quickly, with less precision than I'd like, but as a starting point: For aggregate reports, the data is intended for the domain owner to understand what is being sent in its name, as seen by the receiver. The intention is that this data is aggregated on behalf of the domain owner by the receiver, and sent if the domain owner publishes a reporting record. In the data itself, there are summaries of IP addresses and authentication statuses of mail that fall into three categories: 1) mail that is authenticated by the domain, 2) mail that fails to authenticate as the domain, and 3) mail that is wholly unauthenticated. From a domain owner perspective, this means they get reports of mail that is 1) authorized by them, 2) not authorized by them, or 3) broken by forwarding or other rewriting by an intermediary. In all cases, this is valuable information for a domain owner to have, and any PII (IP addresses specifically) either belong to the domain owner getting the report, are threat attempting to act as the domain owner, or are intermediaries being used by the domain owner. In all cases, there is nothing here that leaks or exposes someone else's PII to a domain owner, just things explicitly that are theirs or attempting to be seen as them. Seth On Fri, Feb 12, 2021 at 12:50 PM Brotman, Alex wrote: > Apologies, this is for aggregate reports. I'm would imagine the Failure > reports draft would have its own section as the questions there may be > different. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -Original Message- > > From: John Levine > > Sent: Friday, February 12, 2021 3:46 PM > > To: dmarc@ietf.org > > Cc: Brotman, Alex > > Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII > Concerns > > > > In article > > > 11.prod.outlook.com> you write: > > >Hello folks, > > > > > >In ticket #64 > > >(https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64 > > >__;!!CQl3mcHX2A!TwDVjWOh08AOGCxPZ0IKR8IxgdUb6u3LDW1Po0KbrzIgXW > > wlVm53NUB > > >Q6gqZ8IbIjUjG$ ), it was suggested that a Privacy Considerations > section may > > alleviate some concerns about the ownership of the data. I created an > initial > > attempt, and thought to get some feedback. I didn't think we should go > too far > > in depth, or raise corner cases. Felt like doing so could lead down a > rabbit hole > > of trying to cover all cases. This would go within a "Privacy > Considerations" > > section. > > > > > >* Data Contained Within Reports (#64) > > > > > >Within the reports is contained an aggregated body of anonymized data > > >pertaining to the sending domain. The data is meant to aid the report > > >processors and domain holders in verifying sources of messages > > >pertaining to the 5322.From Domain. The data should not contain any > > >identifying characteristics about individual senders or receivers. An > > >entity sending reports should not be concerned with the data contained > > >as it should not contain PII (NIST reference for PII definition), such > > >as email addresses or usernames. > > > > > >Does this seem a reasonable start? Thanks for your time. > > > > It's not clear which kind of report this is talking about. > > > > If it's aggregate reports, they contain IP addresses of mail servers and > domain > > names of SPF and DKIM identifiers, but nothing about the e-mail address > or IP of > > the original senders. > > > > If it's failure reports, they contain as much or as little as the > reporter includes, > > possibly an entire message sent by someome who may or may not be > connected > > to the domain that receives the report. > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 ` 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] [EXTERNAL] Re: Ticket #64 - Contained Data PII Concerns
Apologies, this is for aggregate reports. I'm would imagine the Failure reports draft would have its own section as the questions there may be different. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: John Levine > Sent: Friday, February 12, 2021 3:46 PM > To: dmarc@ietf.org > Cc: Brotman, Alex > Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns > > In article > 11.prod.outlook.com> you write: > >Hello folks, > > > >In ticket #64 > >(https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64 > >__;!!CQl3mcHX2A!TwDVjWOh08AOGCxPZ0IKR8IxgdUb6u3LDW1Po0KbrzIgXW > wlVm53NUB > >Q6gqZ8IbIjUjG$ ), it was suggested that a Privacy Considerations section may > alleviate some concerns about the ownership of the data. I created an initial > attempt, and thought to get some feedback. I didn't think we should go too > far > in depth, or raise corner cases. Felt like doing so could lead down a rabbit > hole > of trying to cover all cases. This would go within a "Privacy Considerations" > section. > > > >* Data Contained Within Reports (#64) > > > >Within the reports is contained an aggregated body of anonymized data > >pertaining to the sending domain. The data is meant to aid the report > >processors and domain holders in verifying sources of messages > >pertaining to the 5322.From Domain. The data should not contain any > >identifying characteristics about individual senders or receivers. An > >entity sending reports should not be concerned with the data contained > >as it should not contain PII (NIST reference for PII definition), such > >as email addresses or usernames. > > > >Does this seem a reasonable start? Thanks for your time. > > It's not clear which kind of report this is talking about. > > If it's aggregate reports, they contain IP addresses of mail servers and > domain > names of SPF and DKIM identifiers, but nothing about the e-mail address or IP > of > the original senders. > > If it's failure reports, they contain as much or as little as the reporter > includes, > possibly an entire message sent by someome who may or may not be connected > to the domain that receives the report. > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
In article you write: >Hello folks, > >In ticket #64 (https://trac.ietf.org/trac/dmarc/ticket/64), it was suggested >that a Privacy Considerations section may alleviate >some concerns about the ownership of the data. I created an initial attempt, >and thought to get some feedback. I didn't think >we should go too far in depth, or raise corner cases. Felt like doing so >could lead down a rabbit hole of trying to cover all >cases. This would go within a "Privacy Considerations" section. > >* Data Contained Within Reports (#64) > >Within the reports is contained an aggregated body of anonymized data >pertaining >to the sending domain. The data is meant to aid the report processors >and domain holders in verifying sources of messages pertaining to the >5322.From Domain. The data should not contain any identifying >characteristics about individual senders or receivers. An entity >sending reports should not be concerned with the data contained as >it should not contain PII (NIST reference for PII definition), such as email >addresses or >usernames. > >Does this seem a reasonable start? Thanks for your time. It's not clear which kind of report this is talking about. If it's aggregate reports, they contain IP addresses of mail servers and domain names of SPF and DKIM identifiers, but nothing about the e-mail address or IP of the original senders. If it's failure reports, they contain as much or as little as the reporter includes, possibly an entire message sent by someome who may or may not be connected to the domain that receives the report. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
In article you write: >-=-=-=-=-=- > >As an individual, +1000 to Scott. I've closed this ticket. One down, a zillion to go. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Ticket #64 - Contained Data PII Concerns
Hello folks, In ticket #64 (https://trac.ietf.org/trac/dmarc/ticket/64), it was suggested that a Privacy Considerations section may alleviate some concerns about the ownership of the data. I created an initial attempt, and thought to get some feedback. I didn't think we should go too far in depth, or raise corner cases. Felt like doing so could lead down a rabbit hole of trying to cover all cases. This would go within a "Privacy Considerations" section. * Data Contained Within Reports (#64) Within the reports is contained an aggregated body of anonymized data pertaining to the sending domain. The data is meant to aid the report processors and domain holders in verifying sources of messages pertaining to the 5322.From Domain. The data should not contain any identifying characteristics about individual senders or receivers. An entity sending reports should not be concerned with the data contained as it should not contain PII (NIST reference for PII definition), such as email addresses or usernames. Does this seem a reasonable start? Thanks for your time. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
As an individual, +1000 to Scott. As Chair, this thread is unproductive, and two months passed due date to resolve. Consensus seems clear that there isn't an issue here. If there's a clear use case that hasn't been communicated, share it now or move on. Seth On Fri, Feb 12, 2021 at 10:02 AM Scott Kitterman wrote: > I didn't miss it. I don't think it's meaningful. > > In the real world, outside the IETF one of three things happens: > > 1. Everything works fine. > > 2. Someone depends on HELO evaluation of SPF and discovers from > evaluating > the feedback reports that's it's a problem and then doesn't to that > anymore. > > 3. Someone depends on HELO evaluation of SPF and doesn't discover it's a > problem because they don't look at their feedback reports. > > For case 1 and 2, there's no issue. > > Case 3 doesn't care if their mail gets delivered, so its fine. > > This excessive focus on irrelevant minutia is harmful to the IETF. It > makes > participation less interesting for technically capable contributors and > reduces the overall value of the discourse. > > Many people have suggested we move on. My prediction is you won't, but > this > is my last email on the topic. > > Scott K > > On Thursday, February 11, 2021 11:24:16 PM EST Douglas Foster wrote: > > You missed my main point. I will restate it, and then address your > threat > > question. > > > > If there are N ways to establish authentication, then a recipient only > > needs to choose one of them, but a sender who wants to be validated by > all > > recipients must implement all of them. One purpose of the specification > > is to constrain that complexity. > > > > So the convenient solution would be to say that SPF HELO must be ignored, > > except for null sender, because doing so reduces the number of variables > > that must be considered by senders. It is also probably consistent with > > the logic of many current implementations. I just do not believe that > it > > is justified to tell recipients that they MUST NOT evaluate SPF HELO when > > MAILFROM is present. > > > > An alternative would be to say that SPF HELO and SPF MAILFROM should both > > be evaluated. In the long run, this is arguably the best theoretical > > solution, but the fear of short-term pain from false positives probably > > makes this unattractive. > > > > So, I am back to the only solution that seems justifiable:Senders > > SHOULD comply with both MAILFROM and HELO policies because SOME > recipients > > may evaluate both criteria, but many will only evaluate MAILFROM because > > the incremental theoretical benefit seems less than the incremental cost. > > > > - - - > > > > To your point about threat vectors: DMARC alignment is based on nested > > layers of trust, and the trust is broken if you skip layers. The server > > operator provides a mail server environment to a mail domain, and the > mail > > domain provides delivery services for an author. > > > > SPF proves that the mail domain (indicated by the MAILFROM address) > really > > uses the services of the server domain, and therefore the server > (indicated > > by IP address, HELO, and possibly ReverseDNS) is authorized to send > > messages on behalf of the mail domain. > > > > DMARC proves that the source server for the message was authorized to > speak > > on behalf of the author (indicated by the From address). > > > > You suggest that if SPF HELO passes, and aligns with FROM, then we have > > established that the server is authorized to speak for the author. This > > is true, but it does not establish that the mail domain in the MAILFROM > > address has that right. > > > > When the MAILFROM domain is different from the HELO domain, this implies > > that that MAILFROM domain is a client of the server domain. The server > > domain has the right to emit messages for the client, but the client > domain > > does not have the right to email messages claiming to be from the server > > domain. > > > > - - - > > > > It can be asserted that the server domain should be able to use its > > firewall to prevent unauthorized servers from emitting mail, and should > be > > able to use its outbound gateway to prevent client domains from emitting > > messages from the server domain, other clients, or any unrelated domain. > > These commonly implemented measures could eliminate the need for checking > > SPF HELO. Why should others check what the sender should be able to do > > for themselves? > > Are we prepared to make this argument? If so, then the existing wording > > stands, but needs a solid justification. > > > > DF > > > > On Thu, Feb 11, 2021 at 8:50 AM Scott Kitterman > > > > wrote: > > > What problem are you purporting to solve? > > > > > > By problem, I mean a case were a bad actor can get a DMARC pass result > if > > > SPF > > > HELO results are allowed to be used that they couldn't already get > with a > > > mail > > > from result. > > > > > > I don't think such a case exists which is
Re: [dmarc-ietf] Ticket #1 - SPF alignment
I didn't miss it. I don't think it's meaningful. In the real world, outside the IETF one of three things happens: 1. Everything works fine. 2. Someone depends on HELO evaluation of SPF and discovers from evaluating the feedback reports that's it's a problem and then doesn't to that anymore. 3. Someone depends on HELO evaluation of SPF and doesn't discover it's a problem because they don't look at their feedback reports. For case 1 and 2, there's no issue. Case 3 doesn't care if their mail gets delivered, so its fine. This excessive focus on irrelevant minutia is harmful to the IETF. It makes participation less interesting for technically capable contributors and reduces the overall value of the discourse. Many people have suggested we move on. My prediction is you won't, but this is my last email on the topic. Scott K On Thursday, February 11, 2021 11:24:16 PM EST Douglas Foster wrote: > You missed my main point. I will restate it, and then address your threat > question. > > If there are N ways to establish authentication, then a recipient only > needs to choose one of them, but a sender who wants to be validated by all > recipients must implement all of them. One purpose of the specification > is to constrain that complexity. > > So the convenient solution would be to say that SPF HELO must be ignored, > except for null sender, because doing so reduces the number of variables > that must be considered by senders. It is also probably consistent with > the logic of many current implementations. I just do not believe that it > is justified to tell recipients that they MUST NOT evaluate SPF HELO when > MAILFROM is present. > > An alternative would be to say that SPF HELO and SPF MAILFROM should both > be evaluated. In the long run, this is arguably the best theoretical > solution, but the fear of short-term pain from false positives probably > makes this unattractive. > > So, I am back to the only solution that seems justifiable:Senders > SHOULD comply with both MAILFROM and HELO policies because SOME recipients > may evaluate both criteria, but many will only evaluate MAILFROM because > the incremental theoretical benefit seems less than the incremental cost. > > - - - > > To your point about threat vectors: DMARC alignment is based on nested > layers of trust, and the trust is broken if you skip layers. The server > operator provides a mail server environment to a mail domain, and the mail > domain provides delivery services for an author. > > SPF proves that the mail domain (indicated by the MAILFROM address) really > uses the services of the server domain, and therefore the server (indicated > by IP address, HELO, and possibly ReverseDNS) is authorized to send > messages on behalf of the mail domain. > > DMARC proves that the source server for the message was authorized to speak > on behalf of the author (indicated by the From address). > > You suggest that if SPF HELO passes, and aligns with FROM, then we have > established that the server is authorized to speak for the author. This > is true, but it does not establish that the mail domain in the MAILFROM > address has that right. > > When the MAILFROM domain is different from the HELO domain, this implies > that that MAILFROM domain is a client of the server domain. The server > domain has the right to emit messages for the client, but the client domain > does not have the right to email messages claiming to be from the server > domain. > > - - - > > It can be asserted that the server domain should be able to use its > firewall to prevent unauthorized servers from emitting mail, and should be > able to use its outbound gateway to prevent client domains from emitting > messages from the server domain, other clients, or any unrelated domain. > These commonly implemented measures could eliminate the need for checking > SPF HELO. Why should others check what the sender should be able to do > for themselves? > Are we prepared to make this argument? If so, then the existing wording > stands, but needs a solid justification. > > DF > > On Thu, Feb 11, 2021 at 8:50 AM Scott Kitterman > > wrote: > > What problem are you purporting to solve? > > > > By problem, I mean a case were a bad actor can get a DMARC pass result if > > SPF > > HELO results are allowed to be used that they couldn't already get with a > > mail > > from result. > > > > I don't think such a case exists which is why I think this entire line of > > argument is a waste of time. > > > > Scott K > > > > On Thursday, February 11, 2021 6:35:49 AM EST Douglas Foster wrote: > > > Applying SPF to DMARC could become out of scope, if we choose to remove > > > > SPF > > > > > from DMARC and make it dependent only on DKIM. Until then, we need to > > > have a shared understanding of how SPF is applied. This question asks > > > whether that shared understanding exists. > > > > > > SPF involves two tests, which can be used together.
