Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-30 Thread Seth Blank 
Hector, the chairs hear your frustration, thank you for not escalating
further, and would be happy to speak with you off list on the matter.


On Wed, Sep 30, 2020 at 8:05 PM Hector Santos  wrote:

> Seth, Selectively quoting of comments and not answering any technical
> comments or questions should also not be tolerated. It waste people
> time especially which rudely told we lack substance and credibility.
> This damages people's reputation when he torts engineers in these IETF
> forums.
>
> Did you say anything to him? Should that be tolerated?
>
> I'm trying my best to participate without the snide remarks and
> reputation hurting remarks. I take it very personal because I have
> seen how it can
> hurt people.  He should stop doing that.
>
> --
> Hector Santos, CTO/CEO
> Santronics Software, Inc.
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
> On 9/30/2020 10:37 PM, Seth Blank wrote:
> > Hector, please constrain your comments to the technical matters at
> > hand, not the actions of others.
> >
> > This thread is veering towards ad hominem attacks which will not be
> > tolerated.
> >
> > Seth, as Chair
> >
> > On Wed, Sep 30, 2020 at 7:12 PM Hector Santos
> > mailto:40isdg@dmarc.ietf.org>>
> > wrote:
> >
> > On 9/29/2020 6:54 PM, Dave Crocker wrote:
> > > On 9/29/2020 3:41 PM, Hector Santos wrote:
> > >>
> > >> Do you have an algorithm that replaces the current one?
> > >
> > > I've no idea what any of your note has to do with the DKIM protocol
> > > specification.
> >
> > wow.
> >
> > > By way of a small example, DKIM does not have o=.
> >
> > Right, you were instrumental in attempting to "separate" policy from
> > DKIM to create DKIM-BASE, a success, it allowed progress to be made
> > with DKIM, but it never separated the signer::author identity
> > association primarily because, once again, DKIM-BASE is still
> > inherently bound to the 5322.From field.  You never separated the
> > DKIM
> > anchor identity and it was stated many times, until then, we will
> > always have the signer::author relationship and policy protocols
> > based
> > on this relationship.
> >
> > Until it is changed, DKIM will always have this self-signed
> > signer::author relationship. That goes back to DomainKeys with o=,
> > early DKIM with o=, removed in DKIM-BASE as you gracefully pointed
> > out
> > but it moved to ADSP (now DMARC).
> >
> > > But really, nothing in your note concerns the published and
> approved
> > > specification.
> >
> > Published and approved, yet seeking further comments.  From I had
> > already read and understood from the start, all in once sentence:
> >
> > Extract 5322.Sender, if found, use this for DMARC lookup, if not
> > found, fall back to 5322.From
> >
> > Correct? Anything else?
> >
> > The only systems that this will work with is compliant downlink
> > receivers.  Non-compliant receivers are still a problem.  At the end
> > of the day, the Mailing List Server (MLS) still needs to support
> > DMARC
> > on the inbound side.
> >
> >
> >
> >
> >
> > --
> > Hector Santos,
> > https://secure.santronics.com
> > https://twitter.com/hectorsantos
> >
> >
> > ___
> > 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
> >
>
>
>

-- 

*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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-30 Thread Hector Santos 
Seth, Selectively quoting of comments and not answering any technical 
comments or questions should also not be tolerated. It waste people 
time especially which rudely told we lack substance and credibility. 
This damages people's reputation when he torts engineers in these IETF 
forums.


Did you say anything to him? Should that be tolerated?

I'm trying my best to participate without the snide remarks and 
reputation hurting remarks. I take it very personal because I have 
seen how it can

hurt people.  He should stop doing that.

--
Hector Santos, CTO/CEO
Santronics Software, Inc.
https://secure.santronics.com
https://twitter.com/hectorsantos

On 9/30/2020 10:37 PM, Seth Blank wrote:

Hector, please constrain your comments to the technical matters at
hand, not the actions of others.

This thread is veering towards ad hominem attacks which will not be
tolerated.

Seth, as Chair

On Wed, Sep 30, 2020 at 7:12 PM Hector Santos
mailto:40isdg@dmarc.ietf.org>>
wrote:

On 9/29/2020 6:54 PM, Dave Crocker wrote:
> On 9/29/2020 3:41 PM, Hector Santos wrote:
>>
>> Do you have an algorithm that replaces the current one?
>
> I've no idea what any of your note has to do with the DKIM protocol
> specification.

wow.

> By way of a small example, DKIM does not have o=.

Right, you were instrumental in attempting to "separate" policy from
DKIM to create DKIM-BASE, a success, it allowed progress to be made
with DKIM, but it never separated the signer::author identity
association primarily because, once again, DKIM-BASE is still
inherently bound to the 5322.From field.  You never separated the
DKIM
anchor identity and it was stated many times, until then, we will
always have the signer::author relationship and policy protocols
based
on this relationship.

Until it is changed, DKIM will always have this self-signed
signer::author relationship. That goes back to DomainKeys with o=,
early DKIM with o=, removed in DKIM-BASE as you gracefully pointed
out
but it moved to ADSP (now DMARC).

> But really, nothing in your note concerns the published and approved
> specification.

Published and approved, yet seeking further comments.  From I had
already read and understood from the start, all in once sentence:

Extract 5322.Sender, if found, use this for DMARC lookup, if not
found, fall back to 5322.From

Correct? Anything else?

The only systems that this will work with is compliant downlink
receivers.  Non-compliant receivers are still a problem.  At the end
of the day, the Mailing List Server (MLS) still needs to support
DMARC
on the inbound side.





--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


___
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




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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-30 Thread Seth Blank 
Hector, please constrain your comments to the technical matters at hand,
not the actions of others.

This thread is veering towards ad hominem attacks which will not be
tolerated.

Seth, as Chair

On Wed, Sep 30, 2020 at 7:12 PM Hector Santos  wrote:

> On 9/29/2020 6:54 PM, Dave Crocker wrote:
> > On 9/29/2020 3:41 PM, Hector Santos wrote:
> >>
> >> Do you have an algorithm that replaces the current one?
> >
> > I've no idea what any of your note has to do with the DKIM protocol
> > specification.
>
> wow.
>
> > By way of a small example, DKIM does not have o=.
>
> Right, you were instrumental in attempting to "separate" policy from
> DKIM to create DKIM-BASE, a success, it allowed progress to be made
> with DKIM, but it never separated the signer::author identity
> association primarily because, once again, DKIM-BASE is still
> inherently bound to the 5322.From field.  You never separated the DKIM
> anchor identity and it was stated many times, until then, we will
> always have the signer::author relationship and policy protocols based
> on this relationship.
>
> Until it is changed, DKIM will always have this self-signed
> signer::author relationship. That goes back to DomainKeys with o=,
> early DKIM with o=, removed in DKIM-BASE as you gracefully pointed out
> but it moved to ADSP (now DMARC).
>
> > But really, nothing in your note concerns the published and approved
> > specification.
>
> Published and approved, yet seeking further comments.  From I had
> already read and understood from the start, all in once sentence:
>
> Extract 5322.Sender, if found, use this for DMARC lookup, if not
> found, fall back to 5322.From
>
> Correct? Anything else?
>
> The only systems that this will work with is compliant downlink
> receivers.  Non-compliant receivers are still a problem.  At the end
> of the day, the Mailing List Server (MLS) still needs to support DMARC
> on the inbound side.
>
>
>
>
>
> --
> Hector Santos,
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
>
> ___
> 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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-30 Thread Dave Crocker 

On 9/30/2020 7:12 PM, Hector Santos wrote:

I've no idea what any of your note has to do with the DKIM protocol
specification.


wow.



I'll stop now.  As far as I can tell, this really has nothing to do with 
the existing DKIM specification, nor really anything to do with DMARC.


Perhaps others on the list can find something to work with, here, but I 
give up.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-30 Thread Hector Santos 

On 9/29/2020 6:54 PM, Dave Crocker wrote:

On 9/29/2020 3:41 PM, Hector Santos wrote:


Do you have an algorithm that replaces the current one?


I've no idea what any of your note has to do with the DKIM protocol
specification.


wow.


By way of a small example, DKIM does not have o=.


Right, you were instrumental in attempting to "separate" policy from 
DKIM to create DKIM-BASE, a success, it allowed progress to be made 
with DKIM, but it never separated the signer::author identity 
association primarily because, once again, DKIM-BASE is still 
inherently bound to the 5322.From field.  You never separated the DKIM 
anchor identity and it was stated many times, until then, we will 
always have the signer::author relationship and policy protocols based 
on this relationship.


Until it is changed, DKIM will always have this self-signed 
signer::author relationship. That goes back to DomainKeys with o=, 
early DKIM with o=, removed in DKIM-BASE as you gracefully pointed out 
but it moved to ADSP (now DMARC).



But really, nothing in your note concerns the published and approved
specification.


Published and approved, yet seeking further comments.  From I had 
already read and understood from the start, all in once sentence:


Extract 5322.Sender, if found, use this for DMARC lookup, if not 
found, fall back to 5322.From


Correct? Anything else?

The only systems that this will work with is compliant downlink 
receivers.  Non-compliant receivers are still a problem.  At the end 
of the day, the Mailing List Server (MLS) still needs to support DMARC 
on the inbound side.






--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-30 Thread Seth Blank 
On Wed, Sep 30, 2020 at 8:42 AM Dave Crocker  wrote:

> On 9/30/2020 8:39 AM, Seth Blank wrote:
> > *   *
>
>
> Since quibbling is always more fun than dealing with substance...
>
> Given the recent exchange about 'dispose', perhaps "handling" is a safer
> vocabulary choice?
>
> d/
>

Dave, please open a ticket about vocabulary within DMARC that you think
requires modification to be clearer and/or safer (like "dispose", which has
now been raised in two separate threads), and we'll tackle those
language changes separately with respect to the entire body of documents
instead of within the scope of singular issues.


>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>


-- 

*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] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-30 Thread Dave Crocker 

On 9/30/2020 8:39 AM, Seth Blank wrote:

*       *



Since quibbling is always more fun than dealing with substance...

Given the recent exchange about 'dispose', perhaps "handling" is a safer 
vocabulary choice?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-30 Thread Seth Blank 
On Wed, Sep 30, 2020 at 8:12 AM Seth Blank  wrote:

> On Wed, Sep 30, 2020 at 8:01 AM Kurt Andersen (b) 
> wrote:
>
>> On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker  wrote:
>>
>>> On 9/29/2020 3:08 PM, Seth Blank wrote:
>>> > I don't know of any receiver that checks DMARC, but then doesn't check
>>> > alignment
>>>
>>> It's not a matter of field statistics:
>>>
>>>   Since checking alignment is an obvious part of the DMARC
>>> procedure, if someone does not follow the specification, they are not
>>> doing DMARC.
>>>
>>
>> Does that mean that "none" is not an appropriate verdict?
>>
>
> No, per https://tools.ietf.org/html/rfc7489#appendix-C "none" is the only
> option for when a policy action is not undertaken:
>
>
>
>  
>
>
>
>  
>
>
> The point of this thread, and where consensus appears to lie, is adding
> another value to disambiguate the use cases.
>


Hit send too fast, that's only part of the relevant schema, the rest (which
uses the above) is:

   
   
 

*   *
 
   
   
 
   



>
>
>> --Kurt
>>
>
>
> --
>
> *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.
>


-- 

*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] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-30 Thread Seth Blank 
On Wed, Sep 30, 2020 at 8:01 AM Kurt Andersen (b)  wrote:

> On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker  wrote:
>
>> On 9/29/2020 3:08 PM, Seth Blank wrote:
>> > I don't know of any receiver that checks DMARC, but then doesn't check
>> > alignment
>>
>> It's not a matter of field statistics:
>>
>>   Since checking alignment is an obvious part of the DMARC
>> procedure, if someone does not follow the specification, they are not
>> doing DMARC.
>>
>
> Does that mean that "none" is not an appropriate verdict?
>

No, per https://tools.ietf.org/html/rfc7489#appendix-C "none" is the only
option for when a policy action is not undertaken:

   
   
 
   
   
   
 
   

The point of this thread, and where consensus appears to lie, is adding
another value to disambiguate the use cases.


> --Kurt
>


-- 

*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] DMARC bis: ticket 51: disposition reporting in aggregate reports

2020-09-30 Thread Kurt Andersen (b) 
On Tue, Sep 29, 2020 at 3:50 PM Dave Crocker  wrote:

> On 9/29/2020 3:08 PM, Seth Blank wrote:
> > I don't know of any receiver that checks DMARC, but then doesn't check
> > alignment
>
> It's not a matter of field statistics:
>
>   Since checking alignment is an obvious part of the DMARC
> procedure, if someone does not follow the specification, they are not
> doing DMARC.
>

Does that mean that "none" is not an appropriate verdict?

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

Re: [dmarc-ietf] Trying to understand DMARC in light of Sender/indicators

2020-09-30 Thread Dave Crocker 

On 9/29/2020 6:56 PM, Brandon Long wrote:
Although I'm not fully convinced by Dave's point on whether indicators 
are useless (they certainly are not of large value, I'm less certain 
in the margins)


I fully appreciate (and actually share) the emotional attachment to the 
belief that this is somehow useful for recipient decision-making, but it 
lacks any meaningful objective support.


Show me studies that demonstrate efficacy.  And explain away the ones 
that don't.


It took awhile for people to accept that the Earth is not the center of 
the universe.  We seem similarly stuck here.




.. I think I need to work through what DMARC is without that.


+1



DMARC is composed of three things: alignment, policy and reporting.


+1


I think the argument is that the most important thing that DMARC 
brings is message authentication.. but that's not actually what DMARC 
brings, but perhaps we can view the point of DMARC as pushing forward 
the authenticated message agenda.


It is certainly taken as essential.

But it isn't clear what you mean by "pushing forward the authenticated 
message agenda".  I can guess, but it's taking as a given something that 
has not been stated clearly and does not have any obvious documentation 
as support.


(Also, I'll anticipate the clarification and suggest that the agenda is 
actually accountability, where authentication is a mechanism to aid it. 
This is more than vocabulary quibbling.  It suggests a different focus 
that might permit more useful discussion about means and alternatives.)



In some ways, it's well defined to be such a forcing function.  Policy 
and alignment make it easy for various bodies to point to it as 
something they require entities to do, and reporting gives them the 
path to do it and measure their success against it.


Reporting does more than that.

(And fwiw, from the start, I've felt that the reporting capability was, 
by far, the most important feature of this work.)



Alignment makes policy application easy, and it also makes reporting 
easy.


+1



The Sender proposal hijacks the alignment,


So does re-writing the From: field, but you appear to find that 
acceptable.  Why?



bringing in another possible policy to enforce and a different 
potential reporting path.


ibid.



The draft makes it clear which policy is enforced


No it doesn't.  Again, I suspect you are working from the original 
draft, rather than the current one.



(though of course that only works if the receiver supports the Sender 
extension), but various folks on the list have referred to the matrix 
problem of looking at the policies of both, so at least it brings 
confusion.  It does provide confusion of "ownership".  DMARC currently 
provides very clear ownership, even if that is overly simplified for 
the pre-existing ecosystem.  Adding Sender muddies that, even if it is 
a better match.


For any filtering engine that is not simplistic and mechanical -- which 
is any competent engine that is competently operated -- The current 
DMARC merely adds a signal, rather than a trivial means of resolution, 
and adding more signal does not 'muddy' anything.




If both Sender & From fail evaluation, do we report to both?


Possibly.  So?



Should we report Sender overrides to the From,


There are no overrides.  So this characterization is meaningful.

But since I can see a possibly-interesting point lurking here, I'll 
offer a re-casting:


   If both Sender: and From: have domain names subject to DMARC
   processing, and one succeeds while the other fails, what, if any,
   reporting should be made to the one that failed?

My quick reaction is that it would be appropriate and useful to report 
the failure to the domain owner AND to indicate the alternate domain 
name that succeeded.




should we report which From we're overriding to the Sender?


What do you mean "which From"?

If you meant which Sender: domain succeeded, where the From: failed, 
then I believe yes, it could be useful to report that.




How does the Sender overrider benefit from reporting?


What does this question mean?  I don't understand it.


They'll have even less opportunity to "fix" things, since presumably 
they have a more straightforward role, and without the existence of 
the header, they have no role at all, so the best it could be is 
"places we add the header but fail to sign" or all the other normal 
intermediary cases where DMARC currently fails.


I don't understand this, either.  At the least, the references in it are 
too vague.



Does DMARC that allows third party overrides via Sender provide the 
same incentive to originators?


Does From field re-writing provide the same incentives?  Why or why not?


In the sense that it makes it easier to get to p=reject as there are 
fewer false rejects, probably.  In the sense that it undermines the 
simple explanation for what DMARC does, I think it will harm DMARC 
adoption.


The simple explanation of what DMARC does is classically

Re: [dmarc-ietf] Objections to Sender header as override

2020-09-30 Thread Dave Crocker 

On 9/29/2020 5:54 PM, Brandon Long wrote:
Ie, a mailing list that adopts the Sender header still won't know when 
it can do that over rewriting.


That's correct.  It won't.  But no alternative does, either.


 I agree with others who have said that adding this makes DMARC not 
DMARC,


As with so many comments, from quite a few people, it's a good catch 
phrase, but it does not come with any technical detail to give it 
substance and credibility.


So the fact that I disagree with the assertion, about what adding this 
feature does, highlights disagreement, rather than understanding.


So, please explain what DMARC is -- yes, I know that sounds silly, but 
it appears to be necessary for this discussion -- and how the proposal 
makes it not DMARC. That's a request for technical detail, not quick 
opinion.


I'll put this meta-problem a bit differently:  People are locked into 
very narrow and mechanical views of the DMARC work.  We need, instead, 
to be thinking in pragmatic terms of threats, mitigations, effects and 
side-effects, and we need to be doing this with technical detail, not 
facile catch phrases.



though I'm willing to explore that in more depth.  I understand Dave's 
points regarding user level signals, but I think alignment benefits in 
other ways.


Please enumerate those.


If you instead wanted to add it as a separate thing, I don't think it 
should be couched as overriding DMARC like it does, but as the same 
way we expected ARC to override DMARC, as a well defined local policy 
override.


The word "override" does not appear in my draft.  Nor should it. Nor 
should it appear in these discussions.  Its use is a fundamental 
misrepresentation of what DMARC does.


If you are going to the grocery and I say you should buy healthy food 
and you come back with tasty, unhealthy food, did you "override" me?


If I am a passenger and you are driving and I say turn left here and you 
don't, did you "override" me?


The answer in both cases is no.  Advice was offered and ignored. There 
was no "override" of the advice.


That's DMARC.  The receiver has no obligation, nor even an expectation, 
of following the domain owner's request.  So "override" fundamentally 
misrepresents the role and authority of the domain owner (and of the 
receiver).




Really bad third party signing:
I've objected in the past to various third party signing approaches as 
being non-starters for high value domains. Google does not use SPF's 
include mechanism, and is not going to list hundreds of possible third 
parties as "ok" for signing to cover all possible mailing lists that 
are employees work on.


What does Google see as the long-term role and use of ARC?

Isn't it to allow From: field DMARC failure but still permit delivery of 
the message?



In some sense, the Sender override is basically third party signing 
without any actual relationship...


From: field re-writing is also a form of third-party 'override'. It's 
merely uglier, with significant recipient side-effects.


That is, it seeks to give the recipient -- the actual user -- something 
akin to what they would have gotten from the original From: field, but 
in a way that breaks assorted recipient handling benefits.



BY THE WAY...

It appears you are working from the original version of the 
specification and not the current one.


The current one treats the Sender: field enhancement as an ADDITION, not 
an ALTERNATIVE.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

[dmarc-ietf] Weakend Signatures vs Experimental draft

2020-09-30 Thread Douglas E. Foster 
Weakened signatures seem capable of getting to the desired goal more quickly 
than the draft under consideration.

Building on prior discussions of conditional signatures, I define a "weakened 
signature" as:
one where SUBJECT is omitted from the header list, and l=0 is included to 
exclude the body content.   The protected user-visible content becomes limited 
to From, To, and Date headers.

Benefits
==

Legitimate edits are allowed.
Mailing lists, auto-forwarders, and other mediators can edit subject and body 
content without invalidating the signature.
DMARC policy can still be set to p=reject or p=quarantine.

Only Mediators can use the weakened signature
To benefit from the weakened signature, a system must be in possession of a 
validly-signed message.

Time-Limited
A weak signature is only valid until is expiration time.

No specification needed
This approach can be implemented immediately, by anyone.

Disadvantages


Replay Attacks are possible.
Any attacker who gains possession of a weakened-signature message can use it to 
send an unlimited number of messages, using the same From/To/Date combination, 
until the signature expiration.   Since the SMTP Recipient address is not 
required to align with the Message To header, the attacks could include 
recipients unrelated to the original message.

Potentially-wide scope:
Every recipient of a mailing list message is a potential source for leakage of 
signature information, so the message is at risk both when in transit and when 
at rest in destination systems.

Mitigation Options
==

Sender-side mitigations by the Domain Owner

Limited Deployment
A sender could choose to only apply the weakened signature when the destination 
is a known to need to make changes and is trusted to do so.   This limits the 
opportunity for messages to be intercepted for use in a replay attack.

Dual Signatures
A sender could apply a weakened signature and a traditional signature, to 
permit recipient systems to evaluate messages based on the strength of the 
signature used.   By using different selectors for the two signatures, DMARC 
reporting would help identify which mediators are making signature-altering 
changes.  To help ensure that a traditional signature is detected and used 
first by the receiving system, the traditional signature should appear first, 
followed by the weakened one.

Recipient-side mitigations

A recipient could check signature parameters to determine whether it was 
weakened or traditional, and prefer the traditional signature when both are 
valid.When only a weakened signature is valid, the recipient can perform 
differential handling, based on the reputation of the submitting server and 
other factors.

Changes required:
==

Sending Domains
Senders would need to choose to participate in this scheme by applying a 
weakened signature.
Conditional use of a weakened signature may require software changes.
Simultaneous application of weakened and traditional signatures may require 
software changes.

Mediators
Mediators would need to test for the presence of a weakened signature, and use 
that result to decide whether From-rewrite could be avoided.

Recipient Domains
Recipients can be assumed to participate immediately, on the assumption that 
very few recipients currently apply differential handling of traditional and 
weakened.
Software changes may be needed, if recipient domains wish to implement 
differential handling of traditional and weakened signature.

Comparison to Crocker Draft
==
Draft proposal requires sender domains to opt-in by configuring a DNS entry, so 
all outbound messages are affected.
Draft proposal allows impersonation by any system which can apply a Sender 
header and a valid signature for the sender domain, so the range of possible 
spoof sources is unlimited once a domain opts-in.
Draft proposal can be used to impersonate without intercepting a valid message.
Draft proposal requires recipient domains to opt-in, and to implement new logic 
when doing so.
Draft proposal does not provide a way for mailing lists to know or assume that 
the recipient domain is participating.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc