Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Sun, Aug 30, 2020 at 9:11 AM Alessandro Vesely  wrote:

> On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote:
> > Since we are designing a system that allows a mediator to alter Subject
> and
> > Body, it should be no surprise that the conditional signature has the
> potential
> > for re-use.   A well behaved mediator must be assumed before any such
> trust
> > delegation is granted.
> >
> > I see no way to ensure that the conditional signature is single-use. As
> long as
> > all of the signature's hashed content can be replicated onto another
> message,
> > the signature can be reused.
>
> Yes.  That's true for any DKIM signature, in particular if using l=, which
> allows to append varying content.
>

Indeed, RFC 6376 discusses replay attacks in a number of places.  It would
be nice if we could reduce that, but I suggest that's not a roadblock to
this working group's progress since it's an acknowledged property of DKIM
already.

> DKIM uses the body content in two different hash calculations.  This
> severely
> > limits the ability of an attacker to find and exploit a hash collision.
>  The
> > conditional  signatures seem unlikely to have that strength.
>
> Even if the hash covers few data, finding a collision is not any easier.
>
> According to dkim-conditional, an attacker would need a private key of the
> domain pointed by !fs=.  That limits exploits substantially.  Using
> vanilla
> weak signatures (e.g. to be compatible with v=1 verifiers) allows
> replaying at
> recipient's discretion, a state of affairs loosely comparable to p=none.
>

The draft suggests use of "x=" as a way to limit exposure.  If you do that,
then an attacker would need to be able to generate mail through your signer
with an "!fs=" tag identifying a domain they control, and exploit the
replay before the time in the "x=" tag arrives.  Sure, it's time-limited,
but it only takes seconds for such an attack to succeed, and automation of
such an attack is easy.

If you attach a "!fs=" for any old domain, then the exposure is wide; if
you can somehow constrain the domains, the attack surface is considerably
smaller.  In either case, reputation of the target domain might help,
assuming that's a service to which the author domain's signer has access.

For the cases of employers that want their staff to participate in, say,
IETF lists, they might be willing to institute a program of registering
domains where lists exist, thus limiting the attack surface.  So you
register "ietf.org" with your IT department, and they start issuing weak
signatures on mail going to that domain for six months.  As the deadline
approaches, people are warned to re-register, else the registration expires
and the conditional signatures stop; destructive results resume.
Fraudulent registrations can be traced back to who made them.

But we still have the Yahoo/GMail sized use cases to consider.  I still
don't think any kind of registration system could be reasonably expected to
scale.  Auto-detection, maybe, but that's got to be prone to false
negatives (and destructive results) while the data warm up about a new
destination.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Sun 30/Aug/2020 14:07:33 +0200 Douglas E. Foster wrote:
Since we are designing a system that allows a mediator to alter Subject and 
Body, it should be no surprise that the conditional signature has the potential 
for re-use.   A well behaved mediator must be assumed before any such trust 
delegation is granted.


I see no way to ensure that the conditional signature is single-use. As long as 
all of the signature's hashed content can be replicated onto another message, 
the signature can be reused.



Yes.  That's true for any DKIM signature, in particular if using l=, which 
allows to append varying content.



The more important question is whether conditional signature could be subject 
to third-party attacks.  Does the limited and predictable content of a 
conditional signature intcrease the risk that a bad guy could use 
guess-and-test to construct a valid  signature block for someone else?



If you have the signature, you presumably have the whole message.  So there's 
no need to guess.  It is enough to keep signed header fields, presumably From:, 
Message-Id: (which is random, btw), and Date:.  All the rest can be changed at 
will.



DKIM uses the body content in two different hash calculations.  This severely 
limits the ability of an attacker to find and exploit a hash collision.   The 
conditional  signatures seem unlikely to have that strength.



Even if the hash covers few data, finding a collision is not any easier.

According to dkim-conditional, an attacker would need a private key of the 
domain pointed by !fs=.  That limits exploits substantially.  Using vanilla 
weak signatures (e.g. to be compatible with v=1 verifiers) allows replaying at 
recipient's discretion, a state of affairs loosely comparable to p=none.




Best
Ale
--







































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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Since we are designing a system that allows a mediator to alter Subject and 
Body, it should be no surprise that the conditional signature has the potential 
for re-use.   A well behaved mediator must be assumed before any such trust 
delegation is granted.I see no way to ensure that the conditional signature is 
single-use. As long as all of the signature's hashed cntent can be replicated 
onto another message, the signature can be reused.The more important question 
is whether conditional signature could be subject to third-party attacks.  Does 
the limited and predictable content of a conditional signature intcrease the 
risk that a bad guy could use guess-and-test to construct a valid  signature 
block for someone else?  DKIM uses the body content in two different hash 
calculations.  This severely limits the ability of an attacker to find and 
exploit a hash collision.   The conditional  signatures seem unlikely to have 
that strength.Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Jim Fenton  Date: 
8/29/20  7:11 PM  (GMT-05:00) To: fost...@bayviewphysicians.com, 
dmarc@ietf.org Subject: Re: [dmarc-ietf] third party authorization, 
not, was non-mailing list 
On 8/29/20 12:42 PM, Douglas E. Foster wrote:
> To elaborate on my question and Michael Hammer's answer:
>
> To be unique, a signature needs a unique dataset from which the hash
> is computed.   The weak signature will not be unique because it will
> be computed on non-random content such as From, To, and Date.

Unique != random. A time stamp (with enough precision) might be unique,
even though it is not random. For that matter, DKIM signatures don't
include any random values either.

But what I was getting at is that the "weak" signature might not have to
be any different from any other DKIM signature (except possibly to
specify the authorized mediator). It's just that a verifier might fully
verify the mediator's signature, and verify the original signature but
not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to
the subject line, and that's usually signed.

-Jim



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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Sun 30/Aug/2020 01:11:03 +0200 Jim Fenton wrote:
The one problem is that some mediators add things like [dmarc-ietf] to the 
subject line, and that's usually signed.




Multi-mailbox To: and Cc: are also usually signed and possibly reordered by 
mediators.



Best
Ale
--
























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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Hector Santos]

On 8/26/2020 5:00 PM, Jim Fenton wrote:

On 8/26/20 10:54 AM, Dotzero wrote:



On Wed, Aug 26, 2020 at 1:32 PM Doug Foster
mailto:40bayviewphysicians@dmarc.ietf.org>> wrote:

Are the weak signatures vulnerable to a replay attack?I
thought that one of the reasons that DKIM signatures included
the whole body was to prevent the signature from being reused.

DF


Not particularly vulnerable. The requirement is that you have the
"weak signature" plus the intermediary full DKIM signature. This
let's the validator/receiver know that the originating domain knew
that the intermediary might break the originating domains DKIM
signature but the validator/receiver would have the DKIM signature
of the intermediary. The "weak signature" is only validated against
that specific message and headers it signed and that specific
intermediary. It's not a generic/general signature.



It sounds like the weak signature is just a regular DKIM signature
plus the designation of the intermediary, and the "weak" part is that
you don't check the body hash against the body. Have I got that right?


Yes.

ATPS vs Conditional Signature

The end goal is technically the same. Author Domain authorizing a 3rd 
party signer.


The key difference is DNS. ATPS uses DNS to authorize the signer. 
Conditional signature has the extra tag to define an expected 3rd 
party signature by a 3rd party domain uplink.


For the signing code, there is no change for ATPS. Conditional 
requires significant signer code change.


For the verifying code, the DMARC verifier adds ATPS DNS lookup checks 
if 1st != 3rd party domains differ or it can also add conditional 
signatures checks.


We should ALLOW both to be explored.

For conditional, you don't need a DMARC tag extension.  The existence 
of the extra tag triggers the logic.


For ATPS RFC6541, it was designed to piggyback off ADSP. So ATPS will 
need to be updated to use DMARCbis.  The Domain sets the atps=y 
extension tag to trigger the logic.



--
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] third party authorization, not, was non-mailing list

[Jim Fenton]

On 8/29/20 12:42 PM, Douglas E. Foster wrote:
> To elaborate on my question and Michael Hammer's answer:
>
> To be unique, a signature needs a unique dataset from which the hash
> is computed.   The weak signature will not be unique because it will
> be computed on non-random content such as From, To, and Date.

Unique != random. A time stamp (with enough precision) might be unique,
even though it is not random. For that matter, DKIM signatures don't
include any random values either.

But what I was getting at is that the "weak" signature might not have to
be any different from any other DKIM signature (except possibly to
specify the authorized mediator). It's just that a verifier might fully
verify the mediator's signature, and verify the original signature but
not check to see if the body hash matches.

The one problem is that some mediators add things like [dmarc-ietf] to
the subject line, and that's usually signed.

-Jim


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

To elaborate on my question and Michael Hammer's answer:

To be unique, a signature needs a unique dataset from which the hash is 
computed.   The weak signature will not be unique because it will be computed 
on non-random content such as From, To, and Date.

However, the signature can only be used by the designated domain.   So the 
worst possible "misuse" would be for the designated domain to use the signature 
on other messages.   This seems unlikely, and the worst-case use is no 
different than what ATSP would authorize.   But the weak signature has less 
information leakage, since nothing is published in DNS about the signature 
technique.   So I agree that the approach is a good one for those who want to 
provide mailing-list authorization.

The remaining challenge is to communicate between recipient domains and mailing 
lists so that the list knows whether the recipient will honor the weak 
signature system.

Doug Foster


From: Jim Fenton 
Sent: 8/26/20 5:01 PM
To: Dotzero 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On 8/26/20 10:54 AM, Dotzero wrote:

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster 
 wrote:

Are the weak signatures vulnerable to a replay attack?I thought that one of 
the reasons that DKIM signatures included the whole body was to prevent the 
signature from being reused.



DF

Not particularly vulnerable. The requirement is that you have the "weak 
signature" plus the intermediary full DKIM signature. This let's the 
validator/receiver know that the originating domain knew that the intermediary 
might break the originating domains DKIM signature but the validator/receiver 
would have the DKIM signature of the intermediary. The "weak signature" is only 
validated against that specific message and headers it signed and that specific 
intermediary. It's not a generic/general signature.

It sounds like the weak signature is just a regular DKIM signature plus the 
designation of the intermediary, and the "weak" part is that you don't check 
the body hash against the body. Have I got that right?

-Jim


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Jim Fenton]

On 8/26/20 10:54 AM, Dotzero wrote:
>
>
> On Wed, Aug 26, 2020 at 1:32 PM Doug Foster
>  > wrote:
>
> Are the weak signatures vulnerable to a replay attack?    I
> thought that one of the reasons that DKIM signatures included the
> whole body was to prevent the signature from being reused.
>
>  
>
> DF
>
>
> Not particularly vulnerable. The requirement is that you have the
> "weak signature" plus the intermediary full DKIM signature. This let's
> the validator/receiver know that the originating domain knew that the
> intermediary might break the originating domains DKIM signature but
> the validator/receiver would have the DKIM signature of the
> intermediary. The "weak signature" is only validated against that
> specific message and headers it signed and that specific intermediary.
> It's not a generic/general signature.


It sounds like the weak signature is just a regular DKIM signature plus
the designation of the intermediary, and the "weak" part is that you
don't check the body hash against the body. Have I got that right?

-Jim


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Wed, Aug 26, 2020 at 1:32 PM Doug Foster  wrote:

> Are the weak signatures vulnerable to a replay attack?I thought that
> one of the reasons that DKIM signatures included the whole body was to
> prevent the signature from being reused.
>
>
>
> DF
>

Not particularly vulnerable. The requirement is that you have the "weak
signature" plus the intermediary full DKIM signature. This let's the
validator/receiver know that the originating domain knew that the
intermediary might break the originating domains DKIM signature but the
validator/receiver would have the DKIM signature of the intermediary. The
"weak signature" is only validated against that specific message and
headers it signed and that specific intermediary. It's not a
generic/general signature.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Doug Foster]

Are the weak signatures vulnerable to a replay attack?I thought that one of 
the reasons that DKIM signatures included the whole body was to prevent the 
signature from being reused.

 

DF

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dotzero
Sent: Tuesday, August 25, 2020 1:51 PM
To: John R Levine
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list

 

 

 

On Tue, Aug 25, 2020 at 12:22 PM John R Levine  wrote:

On Tue, 25 Aug 2020, Dotzero wrote:
>> https://tools.ietf.org/html/draft-levine-dkim-conditional-00?

> Under my concept, all mail would still be signed in full. The weak
> signature would be in addition to the full signature and the intermediary
> would be expected to sign in full as well. If the original full signature
> is broken you are left with the original "weak signature" which authorizes
> the intermediary and the full signature of the intermediary.

Take another look at my old draft.  Sounds like exactly the same plan.

 

I will. 


> I would expect there to be multiple potential approaches to identifying
> acceptable intermediaries.

The harder part is to decide which intermediary gets to re-sign which 
message at the time you apply the weak signature.

 

It would have be the domain in the "To" field.  It wouldn't work with random 
unknown intermediaries. It would address the MLM issue as long as the MLM 
domain is the same as the "To" domain when the message was originally sent. It 
could also presumably work for vanity domains if they DKIM sign. It wouldn't 
work for forwards on the receiver side that the sender is unaware of.

 

Michael Hammer

 

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Tue 25/Aug/2020 20:13:46 +0200 John R Levine wrote:

On Tue, 25 Aug 2020, Dotzero wrote:

I would expect there to be multiple potential approaches to identifying
acceptable intermediaries.


The harder part is to decide which intermediary gets to re-sign which
message at the time you apply the weak signature.


It would have be the domain in the "To" field.  It wouldn't work with
random unknown intermediaries. It would address the MLM issue as long as
the MLM domain is the same as the "To" domain when the message was
originally sent. It could also presumably work for vanity domains if they
DKIM sign. It wouldn't work for forwards on the receiver side that the
sender is unaware of.


If the list is somel...@lists.foo.org, does the signature have to be 
d=lists.foo.org?  How about d=foo.org?


On the flip side, do you put a weak signature on all of your outgoing mail, 
which seems like a bad idea, or just mail that you expect to go through list 
modification?  In the latter case, how do you tell?  These are the scaling 
problems that I fear make this unworkable.



https://tools.ietf.org/html/draft-levine-dkim-conditional-03#section-4.1 looks 
quizzical.  It says:


   A small sender that doesn't know which of its mail recipients are
   likely to be forwarders might put a weak signature on all outgoing
   mail, in the expectation that few of its users correspondents are
   likely to be malicious.

If a sender has no idea, what domain would it put in fs=, the recipient's 
domain?  That entails that a signing filter acts in an advanced SMTP step, 
where the connection to the MX is established and the receiving domain known.


Also, in the previous paragraph:

   A sender that expects a message to be forwarded might put both a
   conventional DKIM signature and a signature with a !fs tag that
   refers to the domain name of the expected forwarder.  That signature
   would typically be a "weak" signature that covers the From, To, Date,
   and Message-ID headers but does not cover the Subject header or the
   message body, so that it would remain valid even if a forwarder made
   changes typical of forwarders such as mailing lists.

I understand that nobody can prevent a sender to put a conventional DKIM 
signature, even if it expects the message to be forwarded.  However, if the 
scenario gets upgraded so as to consider that the sender /knows/ that the 
message is going to be forwarded, then the conventional signature is pretty 
useless, as forwarding will break it.  How about this:


   A sender that expects a message to be forwarded might well skip putting
   a conventional DKIM signature and put just a signature with a !fs tag that
   refers to the domain name of the expected forwarder.  That signature
   would typically be a "weak" signature that covers the From, Date, and
   Message-ID headers but does not cover the Subject, To, or Cc header fields,
   nor the message body.

(To: and Cc: are often reordered, which breaks signatures.)

Finally, IMHO the Security Consideration section should compare using !fs= 
versus plain weak signatures.  In particular, consider senders who carefully 
avoid to send out weak signatures except for trusted (forwarding) recipients. 
Would it be advisable to put both a plain weak signature and a signature with 
!fs=?  Plain weak signatures might be discarded by recipients with local 
policies about l=, while v=man signatures might be discarded by unupgraded 
verifiers.  Putting two signatures together is rather common in the presence of 
new features, e.g. those who use elliptic keys do so.  What is the difference 
between the risks brought on by each kind of weak signature?  Answering such 
question justifies the version change.



Best
Ale
--













































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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Jim Fenton]

On 8/25/20 7:39 PM, John Levine wrote:
> In article  you write:
>>> If the list is somel...@lists.foo.org, does the signature have to be
>>> d=lists.foo.org?  How about d=foo.org?
>>>
>> This seems like an analogous situation to the DKIM i= flag, where the
>> domain MUST be the same as, or a subdomain of, the value of the d= flag.
>> So I'd recommend allowing d=foo.org.
> Well, OK, how about d=org?  This is the opposite of i=, superdomains rather 
> than subdomains.


I see it as being in the same direction as i=, because we're talking
about being able to sign with a superdomain of [whatever identifier] in
both cases. But it doesn't really matter.

In principle, d=org would work too. The identified domain (list domain,
i=, whatever) always has to trust all higher level domains: because they
delegate the DNS to the lower level, they could in principle add their
own selector records if they wanted to spoof the subdomain. But I
haven't ever heard of that being a problem.

-Jim



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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John Levine]

In article  you write:
>> If the list is somel...@lists.foo.org, does the signature have to be
>> d=lists.foo.org?  How about d=foo.org?
>>
>This seems like an analogous situation to the DKIM i= flag, where the
>domain MUST be the same as, or a subdomain of, the value of the d= flag.
>So I'd recommend allowing d=foo.org.

Well, OK, how about d=org?  This is the opposite of i=, superdomains rather 
than subdomains.

R's,
John

PS: I realize .org isn't likely to be signing anything, there are 25 TLDs with
top level MX or A records that plausibly could.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Jim Fenton]

On 8/25/20 11:13 AM, John R Levine wrote:
> On Tue, 25 Aug 2020, Dotzero wrote:
 I would expect there to be multiple potential approaches to
 identifying
 acceptable intermediaries.
>>>
>>> The harder part is to decide which intermediary gets to re-sign which
>>> message at the time you apply the weak signature.
>>
>> It would have be the domain in the "To" field.  It wouldn't work with
>> random unknown intermediaries. It would address the MLM issue as long as
>> the MLM domain is the same as the "To" domain when the message was
>> originally sent. It could also presumably work for vanity domains if
>> they
>> DKIM sign. It wouldn't work for forwards on the receiver side that the
>> sender is unaware of.
>
> If the list is somel...@lists.foo.org, does the signature have to be
> d=lists.foo.org?  How about d=foo.org?
>
>
This seems like an analogous situation to the DKIM i= flag, where the
domain MUST be the same as, or a subdomain of, the value of the d= flag.
So I'd recommend allowing d=foo.org.

-Jim

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Tue, Aug 25, 2020 at 2:13 PM John R Levine  wrote:

> On Tue, 25 Aug 2020, Dotzero wrote:
> >>> I would expect there to be multiple potential approaches to identifying
> >>> acceptable intermediaries.
> >>
> >> The harder part is to decide which intermediary gets to re-sign which
> >> message at the time you apply the weak signature.
> >
> > It would have be the domain in the "To" field.  It wouldn't work with
> > random unknown intermediaries. It would address the MLM issue as long as
> > the MLM domain is the same as the "To" domain when the message was
> > originally sent. It could also presumably work for vanity domains if they
> > DKIM sign. It wouldn't work for forwards on the receiver side that the
> > sender is unaware of.
>
> If the list is somel...@lists.foo.org, does the signature have to be
> d=lists.foo.org?  How about d=foo.org?
>

This is something that would have to be thought through and discussed. I
want to lean towards exact match but I could be convinced that the base
organization signature would be acceptable as a starting point. I would
recommend anyone coding this for signing to use a flag to easily switch
between the two. I'd recommend that any intermediary doing signing consider
using the CNAME approach so that all their lists can easily be signed with
an exact match signature. This is one of the areas where implementation and
operational considerations may differ from standards considerations.

>
> On the flip side, do you put a weak signature on all of your outgoing
> mail, which seems like a bad idea, or just mail that you expect to go
> through list modification?  In the latter case, how do you tell?  These
> are the scaling problems that I fear make this unworkable.
>

I think only putting the weak signature on mail you expect to be modified
would be the way to go. As I indicated in my previous post, there are
multiple ways to address identifying which mail is likely to go through an
intermediary.  Large mail providers/data gatherers probably already have an
awareness in this space. Others could probably create lists which could be
checked realtime or updated/downloaded once or twice a day. Organizations
could also enable self registration of intermediary use by their users. It
might also be a combination of these approaches. I don't see this as an
issue that makes scaling unworkable. There are plenty of folks checking for
blocklists, how does this differ significantly either operationally or in
scale?

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John R Levine]

On Tue, 25 Aug 2020, Dotzero wrote:

I would expect there to be multiple potential approaches to identifying
acceptable intermediaries.


The harder part is to decide which intermediary gets to re-sign which
message at the time you apply the weak signature.


It would have be the domain in the "To" field.  It wouldn't work with
random unknown intermediaries. It would address the MLM issue as long as
the MLM domain is the same as the "To" domain when the message was
originally sent. It could also presumably work for vanity domains if they
DKIM sign. It wouldn't work for forwards on the receiver side that the
sender is unaware of.


If the list is somel...@lists.foo.org, does the signature have to be 
d=lists.foo.org?  How about d=foo.org?


On the flip side, do you put a weak signature on all of your outgoing 
mail, which seems like a bad idea, or just mail that you expect to go 
through list modification?  In the latter case, how do you tell?  These 
are the scaling problems that I fear make this unworkable.


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] third party authorization, not, was non-mailing list

[Dotzero]

On Tue, Aug 25, 2020 at 12:22 PM John R Levine  wrote:

> On Tue, 25 Aug 2020, Dotzero wrote:
> >> https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
>
> > Under my concept, all mail would still be signed in full. The weak
> > signature would be in addition to the full signature and the intermediary
> > would be expected to sign in full as well. If the original full signature
> > is broken you are left with the original "weak signature" which
> authorizes
> > the intermediary and the full signature of the intermediary.
>
> Take another look at my old draft.  Sounds like exactly the same plan.
>

I will.

>
> > I would expect there to be multiple potential approaches to identifying
> > acceptable intermediaries.
>
> The harder part is to decide which intermediary gets to re-sign which
> message at the time you apply the weak signature.
>

It would have be the domain in the "To" field.  It wouldn't work with
random unknown intermediaries. It would address the MLM issue as long as
the MLM domain is the same as the "To" domain when the message was
originally sent. It could also presumably work for vanity domains if they
DKIM sign. It wouldn't work for forwards on the receiver side that the
sender is unaware of.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John R Levine]

On Tue, 25 Aug 2020, Dotzero wrote:

https://tools.ietf.org/html/draft-levine-dkim-conditional-00?



Under my concept, all mail would still be signed in full. The weak
signature would be in addition to the full signature and the intermediary
would be expected to sign in full as well. If the original full signature
is broken you are left with the original "weak signature" which authorizes
the intermediary and the full signature of the intermediary.


Take another look at my old draft.  Sounds like exactly the same plan.


I would expect there to be multiple potential approaches to identifying
acceptable intermediaries.


The harder part is to decide which intermediary gets to re-sign which 
message at the time you apply the weak signature.


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] third party authorization, not, was non-mailing list

[Dotzero]

On Tue, Aug 25, 2020 at 5:48 AM Laura Atkins 
wrote:

>
>
> On 24 Aug 2020, at 23:34, Douglas E. Foster <
> fosterd=40bayviewphysicians@dmarc.ietf.org> wrote:
>
> Something seems inconsistent:
>
> - The people who have implemented DMARC do not see any significant
> problems, and as a result they are not interested in a third-party
> authorization scheme.
>
> - Yet adoption is very slow, especially for anything other than p=none
>
> Are we to assume that mailing list compatibility explains the slow
> adoption?   If not, what other obstacles do we need to be considering?
>
>
> I don’t believe mailing list compatibility is a primary reason for slow
> adoption, although I do think it’s a contributing factor. To my mind the
> biggest obstacle to adoption of restrictive policies is the expense of
> implementation and the lack of return for that investment.
>
> Implementing DMARC, particularly for larger companies who want to do it
> correctly, is expensive and resource intensive. It is a multi-month process
> to identify all the legitimate sources of mail, create alignment or move
> vendors and set up the correct reporting mechanism. You can, and I do
> recommend, outsource this to one of the vendors who does this well. Not
> every company outsources or has the resources to do this correctly
> internally. A client from last year was told they had less than a week to
> go from no DMARC to p=reject. Unfortunately, the IT directive came with
> nothing more than a “publish v=DMARC1; p=reject in your DNS.” Client lost
> days worth of mail due to a lack of direct alignment even though they were
> using their own domains in SPF and DKIM. Checking now, client still isn’t
> collecting reports, but has backed down to p=quarantine.
>
> A restrictive DMARC record requires a large, up-front commitment of
> resources. It also requires ongoing resources for monitoring and
> understanding the reports and the ability to be able to address any
> problems that show up in the reports.
>
> For a lot of companies, the benefit to publishing restrictive DMARC policy
> is minor. It stops bad guys from directly forging their domain, but doesn’t
> stop your brand being phished or your executives from being spear phished
> using cousin domains or taking advantage of the 5322.from comment. It also
> disrupts normal business processes as we’ve been discussing on the list
> here. To borrow an example from John Levine, a restrictive DMARC policy is
> preventing employees at a large company from participating in industry
> specific mailing lists; participation which is part of their actual job.
>
> I believe a lot of the very slow adoption is folks inside companies
> looking at the cost of implementing restrictive DMARC records and the
> benefits to implementing restrictive DMARC records and deciding there just
> isn’t enough benefit to justify the expense. BIMI is an attempt to bring
> more benefit to the table, but I’m not sure even that is enough to justify
> the overall expense to a lot of corporations.
>
> laura
>

I agree with many of Laura's observations. One other issue is that DMARC
adoption is typically advocated by security and/or IT.  When put against
competing demands for resources and potential projects in an organization,
it often gets moved down the priority list... until the organization is
being abused in a way that they feel DMARC might help mitigate. Then there
is a rush to implement, often with painful outcomes.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Laura Atkins]

> On 24 Aug 2020, at 23:34, Douglas E. Foster 
>  wrote:
> 
> Something seems inconsistent:
> 
> - The people who have implemented DMARC do not see any significant problems, 
> and as a result they are not interested in a third-party authorization scheme.
> 
> - Yet adoption is very slow, especially for anything other than p=none
> 
> Are we to assume that mailing list compatibility explains the slow adoption?  
>  If not, what other obstacles do we need to be considering?

I don’t believe mailing list compatibility is a primary reason for slow 
adoption, although I do think it’s a contributing factor. To my mind the 
biggest obstacle to adoption of restrictive policies is the expense of 
implementation and the lack of return for that investment. 

Implementing DMARC, particularly for larger companies who want to do it 
correctly, is expensive and resource intensive. It is a multi-month process to 
identify all the legitimate sources of mail, create alignment or move vendors 
and set up the correct reporting mechanism. You can, and I do recommend, 
outsource this to one of the vendors who does this well. Not every company 
outsources or has the resources to do this correctly internally. A client from 
last year was told they had less than a week to go from no DMARC to p=reject. 
Unfortunately, the IT directive came with nothing more than a “publish 
v=DMARC1; p=reject in your DNS.” Client lost days worth of mail due to a lack 
of direct alignment even though they were using their own domains in SPF and 
DKIM. Checking now, client still isn’t collecting reports, but has backed down 
to p=quarantine. 

A restrictive DMARC record requires a large, up-front commitment of resources. 
It also requires ongoing resources for monitoring and understanding the reports 
and the ability to be able to address any problems that show up in the reports. 

For a lot of companies, the benefit to publishing restrictive DMARC policy is 
minor. It stops bad guys from directly forging their domain, but doesn’t stop 
your brand being phished or your executives from being spear phished using 
cousin domains or taking advantage of the 5322.from comment. It also disrupts 
normal business processes as we’ve been discussing on the list here. To borrow 
an example from John Levine, a restrictive DMARC policy is preventing employees 
at a large company from participating in industry specific mailing lists; 
participation which is part of their actual job. 

I believe a lot of the very slow adoption is folks inside companies looking at 
the cost of implementing restrictive DMARC records and the benefits to 
implementing restrictive DMARC records and deciding there just isn’t enough 
benefit to justify the expense. BIMI is an attempt to bring more benefit to the 
table, but I’m not sure even that is enough to justify the overall expense to a 
lot of corporations. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Tue, Aug 25, 2020 at 5:03 AM Alessandro Vesely  wrote:

> On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote:
> > In article  8qgy3wky...@mail.gmail.com> you write:
> >>> If the intermediary DKIM signs the modified message with their own
> >>> signature, that provides some assurance to the receiver.
> >>
> >> You mean like
> https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
> >>
> >> I'm pretty sure that got implemented too, but I can't recall now if it
> ever shipped.
> >
> > I don't think it ever did.  It has the scaling problem of every system
> that sends to mailing lists
> > having to decide what mail it's willing to have re-signed and what
> domain the second signature
> > will use.  Usually it's the domain name of the list except when it's not.
>
>
> Right.  The only practical implementation I see is that the sender has
> a list of recipient addresses that require weak signatures.  When it
> is about to send a message destined to a listed address, it can fork
> the message so that the weakly signed copy is sent to the (trusted)
> list address only.  Any direct copy is signed in full.
>
> To configure that, a postmaster would need an application by the list.
>   Something saying "your users A, B, and C are subscribed to list X,
> please sign weakly".  The postmaster would then verify if A, B, and C
> are trusted users and if they confirm to be subscribed to X.  In that
> case, the address of X gets enlisted.  Would that scale?
>
>
> Best
> Ale
> --
>

Under my concept, all mail would still be signed in full. The weak
signature would be in addition to the full signature and the intermediary
would be expected to sign in full as well. If the original full signature
is broken you are left with the original "weak signature" which authorizes
the intermediary and the full signature of the intermediary.

I would expect there to be multiple potential approaches to identifying
acceptable intermediaries. One might be user self enrollment. For larger
organizations it might be intermediary application/approval. A 3rd approach
might be a trusted 3rd party providing lists of known intermediaries. This
would be separate from the core signing RFC, whether it is part of DMARC or
a separate document.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Mon 24/Aug/2020 19:24:03 +0200 John Levine wrote:

In article  
you write:

If the intermediary DKIM signs the modified message with their own
signature, that provides some assurance to the receiver.


You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?

I'm pretty sure that got implemented too, but I can't recall now if it ever 
shipped.


I don't think it ever did.  It has the scaling problem of every system that 
sends to mailing lists
having to decide what mail it's willing to have re-signed and what domain the 
second signature
will use.  Usually it's the domain name of the list except when it's not.



Right.  The only practical implementation I see is that the sender has 
a list of recipient addresses that require weak signatures.  When it 
is about to send a message destined to a listed address, it can fork 
the message so that the weakly signed copy is sent to the (trusted) 
list address only.  Any direct copy is signed in full.


To configure that, a postmaster would need an application by the list. 
 Something saying "your users A, B, and C are subscribed to list X, 
please sign weakly".  The postmaster would then verify if A, B, and C 
are trusted users and if they confirm to be subscribed to X.  In that 
case, the address of X gets enlisted.  Would that scale?



Best
Ale
--



















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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Mon, Aug 24, 2020 at 6:34 PM Douglas E. Foster  wrote:

> Something seems inconsistent:
>
> - The people who have implemented DMARC do not see any significant
> problems, and as a result they are not interested in a third-party
> authorization scheme.
>
> - Yet adoption is very slow, especially for anything other than p=none
>
> Are we to assume that mailing list compatibility explains the slow
> adoption?   If not, what other obstacles do we need to be considering?
>
> DF
>

DMARC itself is easy to implement. It's getting control of your mail flows
that is the difficult part for most organizations interested in
implementing. I think the real issue for "slow adoption" is lack of
perceived need, until you believe your domain is being abused.  What is the
uptake for DNSSEC? For most IETF standards other than very core ones, the
long tail is indeed very long. My gut tells me, based on being in this
space a long time, that the overwhelming majority of people aren't thinking
about DMARC, let alone the "mailing list problem"/

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Mon, Aug 24, 2020 at 3:34 PM Douglas E. Foster  wrote:

> Something seems inconsistent:
>
> - The people who have implemented DMARC do not see any significant
> problems, and as a result they are not interested in a third-party
> authorization scheme.
>

I suspect you are conflating disinterest with being unconvinced that it is
workable, at least in any of the forms in which it's been presented.

I implemented DMARC and, unless you've been missing my commentary, I am far
from "do not see any significant problems".

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Something seems inconsistent:

- The people who have implemented DMARC do not see any significant problems, 
and as a result they are not interested in a third-party authorization scheme.

- Yet adoption is very slow, especially for anything other than p=none

Are we to assume that mailing list compatibility explains the slow adoption?   
If not, what other obstacles do we need to be considering?

DF


From: "Murray S. Kucherawy" 
Sent: 8/24/20 11:21 AM
To: Brandon Long 
Cc: IETF DMARC WG , Tim Draegen , Alessandro 
Vesely 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Thu, Aug 20, 2020 at 2:01 PM Brandon Long  wrote:
I tend to agree with the negative stance on third party auth, but SPF obviously 
has the include: statement which is third party auth at the most basic 
level...atps[1] is the obvious equivalent for DKIM.  I don't know if atps 
failed because it wasn't all that useful, or if it was tied in folks minds to 
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage across 
thousands of "relays" etc, and I don't think they should be used for that, but 
for a bunch of small to medium entities, it could be the thing that makes 
higher p= possible.

ATPS was designed as a proof of concept to see if third party policy was 
conceptually useful at all.  Scale could come later if the initial experiment 
had a positive result.  The industry, however, apparently didn't even have 
appetite to try, so we may never know.

-MSK


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John Levine]

In article  
you write:
>> message. If the intermediary DKIM signs the modified message with their own
>> signature, that provides some assurance to the receiver.
>
>You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?
>
>I'm pretty sure that got implemented too, but I can't recall now if it ever 
>shipped.

I don't think it ever did.  It has the scaling problem of every system that 
sends to mailing lists
having to decide what mail it's willing to have re-signed and what domain the 
second signature
will use.  Usually it's the domain name of the list except when it's not.

R's,
John

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Thu, Aug 20, 2020 at 2:01 PM Brandon Long  wrote:

> I tend to agree with the negative stance on third party auth, but SPF
> obviously has the include: statement which is third party auth at the most
> basic level...
> atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed
> because it wasn't all that useful, or if it was tied in folks minds to
> adps, or the failure of the follow-on reputation system stuff..
>
> Neither atps or spf include are really designed for large scale usage
> across thousands of "relays" etc, and I don't think they should be used for
> that, but for a bunch of small to medium entities, it could be the thing
> that makes higher p= possible.
>

ATPS was designed as a proof of concept to see if third party policy was
conceptually useful at all.  Scale could come later if the initial
experiment had a positive result.  The industry, however, apparently didn't
even have appetite to try, so we may never know.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Thu, Aug 20, 2020 at 4:56 PM Dotzero  wrote:

> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.


You mean like https://tools.ietf.org/html/draft-levine-dkim-conditional-00?

I'm pretty sure that got implemented too, but I can't recall now if it ever
shipped.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

Instead of immediately deciding which ideas can and cannot work, I suggest that 
we create an extension mechanism for DMARC and then let the market decide.  
Perhaps someone will find traction for an idea that is useful to a subset of 
users even if it is not useful for every sender-receiver pair.

The extension mechanism could be as simple as an "add-ons=Y" clause in the 
DMARC record.

If a receiver has implemented ANY add-on method, this flag tells him to check 
all of the options that he supports.   Most likely this will require one or 
more additional DNS lookups to determine which add-on technique is supported by 
the sender.The result of those lookups will determine if the sender and the 
receiver support any of the same techniques.   When there is a match on 
supported techniques, the logic for that technique is invoked.But when the 
flag is absent, no resources are wasted on checking add-on methods that can 
only apply to a subset of all messages.

This approach separates the DMARC spec, which focuses on two specific 
authentication strategies, from add-on methods that invoke alternate 
authentication strategies, so that the DMARC specification can move forward.

It leaves room for all of the ideas mentioned so far, and for those that have 
not yet been suggested.   It also leaves room for a good-but-neglected idea to 
gain traction based on future events.

The details of those other implementations can be determined by private 
agreement or by RFC.

DF


From: Alessandro Vesely 
Sent: 8/21/20 4:58 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote:
> On Thursday, August 20, 2020, Jesse Thompson  wrote:
>> On 8/20/20 4:00 PM, bl...@google.com wrote:
>>> Neither atps or spf include are really designed for large scale usage
>>
>> That's my conclusion, as well. I don't want to authorize every potential
>> MLM to use all addresses in all of our domains cart blanch, even if I would
>> otherwise trust them (e.g. their purported ARC results).
>>
>> I *do* want to authorize our *own* MLM(s) to use our own domains for
>> *internal* use... so I thought for a minute... maybe ATSP has merit for
>> small scale usage, as an alternative to SPF include?

Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a 
rhswl zone which can be outsourced.

>> But no, I don't know if any MLM has a way to check to see if they
>> are authorized via any mechanism, so they will continue to munge
>> the From header for our DMARC-enabled domains anyway.

That is going to be true for /any/ method we devise now. From: rewriting is not 
going to stop on the next day. We must tune aggregate reports so that MLMs can 
tell if it's still necessary. It may take decades... still better than ∞.

>> So, for this *internal* use case, maybe I'll just check the ARC
>> result from the trusted MLM and replace the From header with the
>> value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a number of 
operators. And, in case, I'd adopt John's broad brush: If I went so far as to 
whitelist the MLM, why should I take the burden to scrutinize the way it 
applied policies? It seems more sound to allow my recipients to see the same 
messages as every other subscriber.

> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.

That was described on June 26, here:
https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/

It requires modifying signer behavior. AIUI, the sender recognizes that one of 
the recipients is an allowed mailing list, and adds that tag to that copy of 
the message. It looks less outsourceable than an external whitelist.

Let me call weak signature this concept. As it is very similar to 
dkim-conditional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as 
weak signatures can all be adopted concurrently.

> I haven't seen enough favorable response to justify working on a detailed
> submission to the group. I'm not an IETF standards wonk.

I'd support weak signatures, in either embodiment. I don't think it needs to be 
linked to the Sender: field.

Best
Ale
--

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote:
> On Thursday, August 20, 2020, Jesse Thompson  wrote:
>> On 8/20/20 4:00 PM, bl...@google.com wrote:
>>> Neither atps or spf include are really designed for large scale usage
>>
>> That's my conclusion, as well.  I don't want to authorize every potential
>> MLM to use all addresses in all of our domains cart blanch, even if I would
>> otherwise trust them (e.g. their purported ARC results).
>>
>> I *do* want to authorize our *own* MLM(s) to use our own domains for
>> *internal* use... so I thought for a minute... maybe ATSP has merit for
>> small scale usage, as an alternative to SPF include?


Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a 
rhswl zone which can be outsourced.


>> But no, I don't know if any MLM has a way to check to see if they
>> are authorized via any mechanism, so they will continue to munge
>> the From header for our DMARC-enabled domains anyway.

That is going to be true for /any/ method we devise now.  From: rewriting is 
not going to stop on the next day.  We must tune aggregate reports so that MLMs 
can tell if it's still necessary.  It may take decades...  still better than ∞.


>> So, for this *internal* use case, maybe I'll just check the ARC
>> result from the trusted MLM and replace the From header with the
>> value of Reply-to/X-Original-From, and call it a day.

Restoring From: at the MDA is certainly a good idea.

However, the need to whitelist each MLM is not much viable for a number of 
operators.  And, in case, I'd adopt John's broad brush:  If I went so far as to 
whitelist the MLM, why should I take the burden to scrutinize the way it 
applied policies?  It seems more sound to allow my recipients to see the same 
messages as every other subscriber.


> This is why I proposed a tag that would have a value consisting of the
> authorized intermediary domain. It would only be valid for that message.
> Because the tag is signed separately from the rest of the message, it
> should survive even if the intermediary modifies other parts of the
> message. If the intermediary DKIM signs the modified message with their own
> signature, that provides some assurance to the receiver.


That was described on June 26, here:
https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/

It requires modifying signer behavior.  AIUI, the sender recognizes that one of 
the recipients is an allowed mailing list, and adds that tag to that copy of 
the message.  It looks less outsourceable than an external whitelist.

Let me call weak signature this concept.  As it is very similar to 
dkim-conditional, either one or the other should be adopted.

By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as 
weak signatures can all be adopted concurrently.


> I haven't seen enough favorable response to justify working on a detailed
> submission to the group. I'm not an IETF standards wonk.


I'd support weak signatures, in either embodiment.  I don't think it needs to 
be linked to the Sender: field.


Best
Ale
-- 


























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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Thursday, August 20, 2020, Jesse Thompson  wrote:

> On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote:
> > Neither atps or spf include are really designed for large scale usage
>
> That's my conclusion, as well.  I don't want to authorize every potential
> MLM to use all addresses in all of our domains cart blanch, even if I would
> otherwise trust them (e.g. their purported ARC results).
>
> I *do* want to authorize our *own* MLM(s) to use our own domains for
> *internal* use... so I thought for a minute... maybe ATSP has merit for
> small scale usage, as an alternative to SPF include?  But no, I don't know
> if any MLM has a way to check to see if they are authorized via any
> mechanism, so they will continue to munge the From header for our
> DMARC-enabled domains anyway.  So, for this *internal* use case, maybe I'll
> just check the ARC result from the trusted MLM and replace the From header
> with the value of Reply-to/X-Original-From, and call it a day.
>
> Jesse
>

This is why I proposed a tag that would have a value consisting of the
authorized intermediary domain. It would only be valid for that message.
Because the tag is signed separately from the rest of the message, it
should survive even if the intermediary modifies other parts of the
message. If the intermediary DKIM signs the modified message with their own
signature, that provides some assurance to the receiver.

I haven't seen enough favorable response to justify working on a detailed
submission to the group. I'm not an IETF standards wonk.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Jesse Thompson]

On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote:
> Neither atps or spf include are really designed for large scale usage

That's my conclusion, as well.  I don't want to authorize every potential MLM 
to use all addresses in all of our domains cart blanch, even if I would 
otherwise trust them (e.g. their purported ARC results).

I *do* want to authorize our *own* MLM(s) to use our own domains for *internal* 
use... so I thought for a minute... maybe ATSP has merit for small scale usage, 
as an alternative to SPF include?  But no, I don't know if any MLM has a way to 
check to see if they are authorized via any mechanism, so they will continue to 
munge the From header for our DMARC-enabled domains anyway.  So, for this 
*internal* use case, maybe I'll just check the ARC result from the trusted MLM 
and replace the From header with the value of Reply-to/X-Original-From, and 
call it a day.

Jesse 

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Brandon Long]

On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen  wrote:

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy 
> wrote:
>
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  wrote:
>
>> I am wondering whether companies like Dmarcian could implement third-pary
>> whitelisting.  As they receive and analyze DMARC aggregate reports on
>> behalf of many mail sites, they probably are able to distinguish various
>> level of authentication failures, from mailing lists to misaligned ESPs, to
>> actual abusers.  In that case, they could maintain a whitelist tailored for
>> any given client.  The client would set, say:
>>
>> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
>> client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"
>> [...]
>>
>
> Having spent a lot of time and energy building a DKIM-based reputation
> system that (IMHO) showed promise, I made it available for people to try
> for free.  There was no uptake, even after presenting its promising results
> in places like M3AAWG.  Times may have changed, but in retrospect I think
> there are too many "what-ifs" for add-ons of this nature to be seen as
> feasible.  The issues seem to be:
>
>
> Hi MSK, hi Ale,
>
> I can second that MSK's DKIM-based reputation system is amazing. From
> where I sit, it's like a flying saucer that humans just haven't figured out
> how to fuel quite yet. I believe that fuel comes from widespread adoption
> of domain-based email authentication aka DMARC. The challenge of getting
> the email universe to embrace something like DMARC feels at times
> impossible, but the fact is it just takes a lot of coordination,
> dedication, and consistent levels of exercise to stay sane.
>
> That said, Ale, I like the idea of a Domain Owner being able to share some
> sort of exception list for email flows that are recognized by the Domain
> Owner, but are still (for various reasons) beyond the ability of the Domain
> Owner to address. Something like, "I've got a vendor that will never send
> DMARC-compliant email on my behalf". It appeals to my fondness to be able
> to Just Fix Things without having to bother anyone. I don't think it would
> work, though, because it relies on email receivers having to widely
> implement new stuff, and it relies on Domain Owners accurately maintaining
> another thing. It's easier and more effective to get the vendor to do the
> right thing.
>
> Oh, on 2nd read (I've been consumed with the non-IETF world for a few
> months and only took this up because Ale emailed me at work).. I think
> keying off of "Sender:" is a really bad idea. Multiple policy keys into a
> single piece of email has never made sense.
> Third party authorization makes sense to me in theory as a tool for a very
> specific problem. In practice, people and organizations struggle to get
> first party authorization into place. Once they start to tackle their own
> first party authorization, the need for third party authorization tends to
> evaporate. What's left over? People that want to put together a list of
> authorized third parties but aren't quite ready to do their own first party
> auth?
>
> From a receiver's perspective, it then looks like the first party has no
> idea what it is doing (which is the default anti-spam stance for all
> Internet mail), so then the receiver is now looking at a bunch of factors
> unrelated to first-party auth.. including any third party authorization.
> EG, the receiver notes that the email is authorized by a third-party - a
> newsletter company. "First party" authorization is NOT established, so the
> receiver has to process the email based on the strength of the newsletter
> company's reputation (among other things). So then why bother at all with
> the construct of "third party authorization"?
>
> So I guess put me in the camp of not seeing utility in third party
> authorizations. Better to make the work that needs to be done as clear and
> as simple as possible.
>

I tend to agree with the negative stance on third party auth, but SPF
obviously has the include: statement which is third party auth at the most
basic level...
atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed
because it wasn't all that useful, or if it was tied in folks minds to
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage
across thousands of "relays" etc, and I don't think they should be used for
that, but for a bunch of small to medium entities, it could be the thing
that makes higher p= possible.

Brandon

[1] I just looked atps again, but I might have missed something that makes
it less useful
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Tim Draegen]

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy  wrote:
> 
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  > wrote:
> I am wondering whether companies like Dmarcian could implement third-pary 
> whitelisting.  As they receive and analyze DMARC aggregate reports on behalf 
> of many mail sites, they probably are able to distinguish various level of 
> authentication failures, from mailing lists to misaligned ESPs, to actual 
> abusers.  In that case, they could maintain a whitelist tailored for any 
> given client.  The client would set, say:
> 
> _dmarc.client.domain.example IN TXT "v=DMARC1; 
> rua=mailto:client...@ag.dmarcian.com ; 
> snd=client-id.rhswl.dmarcian.com ; 
> [...]"
> [...]
> 
> Having spent a lot of time and energy building a DKIM-based reputation system 
> that (IMHO) showed promise, I made it available for people to try for free.  
> There was no uptake, even after presenting its promising results in places 
> like M3AAWG.  Times may have changed, but in retrospect I think there are too 
> many "what-ifs" for add-ons of this nature to be seen as feasible.  The 
> issues seem to be:

Hi MSK, hi Ale,
I can second that MSK's DKIM-based reputation system is amazing. From where I 
sit, it's like a flying saucer that humans just haven't figured out how to fuel 
quite yet. I believe that fuel comes from widespread adoption of domain-based 
email authentication aka DMARC. The challenge of getting the email universe to 
embrace something like DMARC feels at times impossible, but the fact is it just 
takes a lot of coordination, dedication, and consistent levels of exercise to 
stay sane.

That said, Ale, I like the idea of a Domain Owner being able to share some sort 
of exception list for email flows that are recognized by the Domain Owner, but 
are still (for various reasons) beyond the ability of the Domain Owner to 
address. Something like, "I've got a vendor that will never send 
DMARC-compliant email on my behalf". It appeals to my fondness to be able to 
Just Fix Things without having to bother anyone. I don't think it would work, 
though, because it relies on email receivers having to widely implement new 
stuff, and it relies on Domain Owners accurately maintaining another thing. 
It's easier and more effective to get the vendor to do the right thing.

Oh, on 2nd read (I've been consumed with the non-IETF world for a few months 
and only took this up because Ale emailed me at work).. I think keying off of 
"Sender:" is a really bad idea. Multiple policy keys into a single piece of 
email has never made sense.

Third party authorization makes sense to me in theory as a tool for a very 
specific problem. In practice, people and organizations struggle to get first 
party authorization into place. Once they start to tackle their own first party 
authorization, the need for third party authorization tends to evaporate. 
What's left over? People that want to put together a list of authorized third 
parties but aren't quite ready to do their own first party auth?

From a receiver's perspective, it then looks like the first party has no idea 
what it is doing (which is the default anti-spam stance for all Internet mail), 
so then the receiver is now looking at a bunch of factors unrelated to 
first-party auth.. including any third party authorization. EG, the receiver 
notes that the email is authorized by a third-party - a newsletter company. 
"First party" authorization is NOT established, so the receiver has to process 
the email based on the strength of the newsletter company's reputation (among 
other things). So then why bother at all with the construct of "third party 
authorization"?

So I guess put me in the camp of not seeing utility in third party 
authorizations. Better to make the work that needs to be done as clear and as 
simple as possible.

=- Tim

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  wrote:

> I am wondering whether companies like Dmarcian could implement third-pary
> whitelisting.  As they receive and analyze DMARC aggregate reports on
> behalf of many mail sites, they probably are able to distinguish various
> level of authentication failures, from mailing lists to misaligned ESPs, to
> actual abusers.  In that case, they could maintain a whitelist tailored for
> any given client.  The client would set, say:
>
> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
> client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"
> [...]
>

Having spent a lot of time and energy building a DKIM-based reputation
system that (IMHO) showed promise, I made it available for people to try
for free.  There was no uptake, even after presenting its promising results
in places like M3AAWG.  Times may have changed, but in retrospect I think
there are too many "what-ifs" for add-ons of this nature to be seen as
feasible.  The issues seem to be:

- it has no hope of being universally accurate; participants have to accept
that false positives and false negatives will happen

- if it's perceived as effective, demand for this will skyrocket; the host
needs to be resilient to this

- participants have to trust the company providing the service to do so
reliably and honestly (e.g., no paying to be listed or get a reputation
boost)

- depending on failure modes, the host could become a DoS target; they need
to be resilient to this

- the "lag" to which you refer might be unacceptable in some situations;
participants need to be willing to tolerate this

- there will be demands for accuracy and timely responses; interfering with
someone's mail flow for whatever reason can draw unwanted legal attention
(e.g., MAPS)

I imagine large operators already have enough information to know where the
lists are, so for them this might be moot.  It's smaller operators without
the infrastructure to make such determinations in real time that need to
collaborate on something like this.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

Hi Tim and all,

I am wondering whether companies like Dmarcian could implement third-pary 
whitelisting.  As they receive and analyze DMARC aggregate reports on behalf of 
many mail sites, they probably are able to distinguish various level of 
authentication failures, from mailing lists to misaligned ESPs, to actual 
abusers.  In that case, they could maintain a whitelist tailored for any given 
client.  The client would set, say:

_dmarc.client.domain.example IN TXT "v=DMARC1; 
rua=mailto:client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"

A receiver seeing a failed From: user@client.domain.example, but an 
authenticated Sender: whate...@example.com could check authorization by 
querying the following record:

example.com.client-id.rhswl.dmarcian.com IN A 127.0.0.2

If the record exists, the sender is authorized.  That way, a Dmarcian client 
can run for some time with p=none.  Meanwhile Dmarcian fills the client's 
whitelist based on misaligned authentications and the client's desiderata.  
When the list is complete and receivers upgraded, the client can switch to 
p=reject or whatever they like.

Delivery would still lag in case, say, users subscribe to mailing lists not yet 
whitelisted, unless we make provisions for whitelisting requests to be 
submitted at subscription time.

For domain names longer than 200 octects (punycode), a whitelist may replace 
the domain name with a hash, á la ATPS.

The above setting overcomes the diagnosed non-trivial upkeep which prevented 
the diffusion of previous schemes.


Best
Ale

 Original Message 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
Date: Wed, 19 Aug 2020 21:18:29 GMT
From: Douglas E. Foster 
Reply-To: fost...@bayviewphysicians.com
To: dmarc@ietf.org 

My two cents.

1) What has changed since 2012 is DMARC, including the ability through DMARC to 
obtain feedback.  "New ATPS" would have to be implemented as a DMARC option, 
not a new thing.

2) A lot of organizations seem to be stick at p=none.   Maybe that means they 
want it that way.   Maybe it means that they are being courteous to mailing 
lists.   But maybe it means something about DMARC is too hard.   I am assuming 
that all of the problems with DMARC are related to third-party authorization, 
and something needs to be done to make it easier.

3) Delegation with an ATPS-type email entry seems functionally equivalent to 
DKIM scope delegation, with several benefits:
Easier and cheaper for the third-party to implement.   The third-party only 
needs to apply its own domain's signature.   Simpler means quicker 
implementation.  Private keys are never exchanged.

Third-party is only responsible for its own key.A big organization like 
Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM 
keys, and that becomes an attractive target for attackers.  If a delegated DKIM 
key store is stolen from a third party, the attacker knows every domain that 
has been compromised.   If an ATPS-delegated third party has a corporate DKIM 
key stolen, the attacker knows that he has struck pay-dirt, but he does not 
have an immediate enumeration of compromised organizations..   That enumeration 
will require an additional data collection process, which might buy time for 
the affected organizations to take evasive measures.

An ATPS-type scope delegation could be designated for a specific user, which I 
assume will represents an application. ("SMTP address must be 
applicationname@vendordomain").   This information is something that the 
receiving system can enforce and report.   It is a weak enforcement tool, but 
limiting scope of delegation seems likely to satisfy some of the auditor 
concerns associated with any third-party delegation.  This is also a new ideas 
relative to the original ATPS.   Of course, a domain level delegation should 
also be an option for situations that the authorizing domain deems appropriate. 
 ("SMTP address must be *@vendordomain")

ATPS-type delegations could be given a pre-defined expire date (if specified 
with that feature).  This would be particularly appropriate where a third-party 
authorization is linked to a time-limited contract.   When the contract lapses, 
the authorization lapses, unless both the contract and the DNS entry are 
renewed.   This limits risk associated with the possibility of 
delegated-but-forgotten authorizations.   DKIM delegations are always 
good-til-cancelled (by removing the DNS public key).

Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS 
propagation.

DKIM delegation becomes impossible if the third-party is not cooperative.   
ATPS-type delegation can be done unilaterally by the owning domain.I am 
thinking of Proofpoint in particular.   They violate my DMARC policy when my 
users, who are non-clients, respond to a secure message from one of their 
clients.   Author self-copies arrive

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Douglas E. Foster]

. Kucherawy" 
Sent: 8/19/20 2:38 PM
To: "Kurt Andersen (b)" 
Cc: "dmarc@ietf.org" , Alessandro Vesely 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b)  wrote:
On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely  wrote:
On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> The industry in general, and the IETF in particular, have chosen not
> to pursue widespread use of any kind of standards-based third party
> domain signature policy or reputation system. . .

> Both ATPS (individual submission, experimental, February 2012) and the
> REPUTE series of documents (working group, standards track, late 2013)
> saw nearly zero adoption after publication even when free reference
> implementations were provided.  They differ from basic DKIM in that
> they require non-trivial upkeep, and that appears to be a step
> function inhibiting adoption among operators.

We can still try again.  In particular, the non-trivial upkeep seems
to be a valid diagnosis.

Is there anything which has materially changed between 2012-13 and 2020 which 
would indicate that the anticipated results for such effort would be any 
different?

+1.  If anyone has some kind of creativity in this space that they've been 
hiding, now's the time.

-MSK


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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Wed, Aug 19, 2020 at 10:11 AM Kurt Andersen (b)  wrote:

> On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely  wrote:
>
>> On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
>> > The industry in general, and the IETF in particular, have chosen not
>> > to pursue widespread use of any kind of standards-based third party
>> > domain signature policy or reputation system. . .
>>
>> > Both ATPS (individual submission, experimental, February 2012) and the
>> > REPUTE series of documents (working group, standards track, late 2013)
>> > saw nearly zero adoption after publication even when free reference
>> > implementations were provided.  They differ from basic DKIM in that
>> > they require non-trivial upkeep, and that appears to be a step
>> > function inhibiting adoption among operators.
>>
>> We can still try again.  In particular, the non-trivial upkeep seems
>> to be a valid diagnosis.
>>
>
> Is there anything which has materially changed between 2012-13 and 2020
> which would indicate that the anticipated results for such effort would be
> any different?
>

+1.  If anyone has some kind of creativity in this space that they've been
hiding, now's the time.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Kurt Andersen (b)]

On Wed, Aug 19, 2020 at 1:34 AM Alessandro Vesely  wrote:

> On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
> > The industry in general, and the IETF in particular, have chosen not
> > to pursue widespread use of any kind of standards-based third party
> > domain signature policy or reputation system. . .
>
> > Both ATPS (individual submission, experimental, February 2012) and the
> > REPUTE series of documents (working group, standards track, late 2013)
> > saw nearly zero adoption after publication even when free reference
> > implementations were provided.  They differ from basic DKIM in that
> > they require non-trivial upkeep, and that appears to be a step
> > function inhibiting adoption among operators.
>
> We can still try again.  In particular, the non-trivial upkeep seems
> to be a valid diagnosis.
>

Is there anything which has materially changed between 2012-13 and 2020
which would indicate that the anticipated results for such effort would be
any different?

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On Tue 18/Aug/2020 01:21:33 +0200 Murray S. Kucherawy wrote:
The industry in general, and the IETF in particular, have chosen not 
to pursue widespread use of any kind of standards-based third party 
domain signature policy or reputation system.  That's the obvious 
consensus, and in my opinion the reasons for that fact are sound.



Based (also) on the following quoted paragraphs, I wouldn't call this 
state of affairs a choice or a consensus.  It's just a series of failures.



Both ATPS (individual submission, experimental, February 2012) and the 
REPUTE series of documents (working group, standards track, late 2013) 
saw nearly zero adoption after publication even when free reference 
implementations were provided.  They differ from basic DKIM in that 
they require non-trivial upkeep, and that appears to be a step 
function inhibiting adoption among operators.


[...]  As I said before, I'm disappointed that things like ATPS and
REPUTE never got a serious attempt, but that's not because they
were oppressed or sabotaged. That's just the reality we're in.



We can still try again.  In particular, the non-trivial upkeep seems 
to be a valid diagnosis.



Best
Ale
--




























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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Hector Santos]

On 8/13/2020 8:21 PM, Murray S. Kucherawy wrote:

On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker mailto:d...@dcrocker.net>> wrote:

> We have had a lot of attempts at third-party authorization schemes
.
> With this in mind, I cannot see any point in designing yet another
> vouching or authorization scheme unless we have evidence that an
> interesting fraction of the world's mail systems want to use it. I
> don't see that, and honestly see no chance that we ever will.

+1


I'm disappointed that the experiment never really got its day in
court,


+1  and I want to give you credit for trying. Without you, I might 
have been long gone from the DKIM project WGs. So I thank you for 
keeping it interesting, but



but the consensus is clear.  +1.


Here I have to disagree. I don't ask anyone to agree with me but to 
understand my viewpoint as a long time participant and advocate of the 
DKIM Policy Model.  Early on, we had limited policy proponents. But 
not today.


I have a different viewpoint, a viewpoint that really that was blocked 
by the two controlling cogs who had DKIM interest else where, namely 
Levine, Crocker. Crocker has been more open ended. Not Levine. Since 
day 0, Levine never liked policy and to his credit, he admitted it as 
much. He killed SSP with the "poison pill" (crippled draft) ADSP 
replacement he knew would never make it pass LC.  Levine was always 
for the 3rd party trust/list signer idea - never a 1st party 
authorization. But he narrowed down the scope to the restrictive 
policy, removing any 3rd party consideration.  The same will most 
likely be true with DMARC with the same problems. Yet, why would any 
list developer deny new security options for list operations?  I never 
got that and that was before ADSP or even ATPS.  When it comes to 
DKIM, if Levine didn't like it, it simply wasn't happening. Sad to say 
and I don't see that changing.  So now that we have the top three cogs 
DKIM agreeing, there is not much reason to even bother anymore when 
one of them is the AD. What is one to think at this point?  "Follow 
the Chieftain" syndrome?


Just consider, we are 15+ yrs into all this and nothing was 
accomplished with DKIM in regards to LIST systems.  DMARC, with the 
same exact problems as ADSP, snuck on via an informational status. 
Nothing wrong there, but it was pushed as a standard and ventures were 
started.  Who wins? who loses?


I believe it would be prudent for the AD to look at the reasons why 
the IETF has failed with this DKIM Project.  If a cog is not for ADSP 
but for DMARC with the same problems, then what is that to say about 
this process?  It has not been a fair process to say the least. A lot 
of wasted time, money and energy.  It has been a long 15+ yrs and has 
become very tiring. :-(


Despite the 3rd party authorization brush back, the concept has never 
gone away. It says a lot and it will never go away under the current 
DKIM POLICY model using the required hash bound Author Domain anchor 
as the forcing function for authorization.


At this point, I would suggest to give the new generation IETF mail 
developers a new chance at DKIM-based security.  Rewrite DKIM as v3.0 
as you guys want it for 3rd party trust.  Remove the Author Domain 
dependency so that the world can nip the Mail tampering bug opened 
with Levine's Rewrite crud.


I wouldn't worry about backward compatibility. Two different streams, 
only the newer one will matter.



--
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] third party authorization, not, was non-mailing list

[Dave Crocker]

On 8/14/2020 7:12 AM, Dotzero wrote:
      At that time there were also folks pushing for PGP, GPG, 
Personal Certificate and  S/MIME as  paths forward.


There was, by then, a long history of these failing to scale.


Even with that, it took a while for industry efforts to gain some 
sense of clarity. Notice that the general path forward was basically 
domain based and not individual user/client based.


SPF and DomainKey were informal, spontaneous, private efforts. They 
established their viability long before reaching a standards venue.  So 
there was no 'policy' 'decision' to make this approach.



There was a debate within the DKIM effort regarding i= vs d= to the 
extent that at one industry event people were walking around with 
little stickers on their badges to indicate which they supported. I 
believe that was courtesy of Dave Crocker.


This was a follow-on issue after DKIM was initially published. We 
realized that the spec said that DKIM's goal was to provide an 
identifier, but then it didn't specify which one to use, the one in the 
i= parameter or the one in the d=.  (Note that neither of these was 
requirement to correlate with any other identifier in the message.


The IETF working group debate about this was intense and was not 
converging on a choice. One of the early arrivals to the meeting walked 
through the hotel's entrance, saw me, and said "d= or i=?" and I 
realized we could have some fun both promoting the issue at this 
industry trade event, and possibly get some constructive discussion.  
The meeting staff were helpful in provide sticky dots to use.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On 2020-08-14 4:12 p.m., Dotzero wrote:

On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely  wrote:

On 2020-08-10 7:24 p.m., John Levine wrote:

In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you write:

Even an external reputation system requires recipient
participation.   That is why I suggested both a
send3="parameters" clause to indicate sender support for
third-party authorization and a verify3="parameters" clause to
indicate recipient support for third-party authentication. When
both are visible to the non-domain message source, that source
can have confidence that the message will be handled as
authorized.


We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.  Every single one of them failed,
not due to technical problems, but because nobody was interested.



We can either try and understand what was wrong in those schemes, or
abandon authorization schemes forever.

Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent
success.

PGP, GPG, and even personal CA certificates never became really
popular, so we could have concluded that digital signature aren't
worth considering for anti-spoof protocols.  Yet, someone thought
about DKIM...



There is a little bit of history behind the impetus for SPF and DKIM. In
2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on
Email Authentication and SPAM. It also let it be known that if the private
sector didn't come up with solutions it was willing to move forward with
regulation. This helped drive activity for SPF, the merger of DK and IIM
to create DKIM and Microsoft's push for SenderID. Private sector folks did
not want to risk what government regulation might look like. At that time
there were also folks pushing for PGP, GPG, Personal Certificate and
S/MIME as  paths forward. Even with that, it took a while for industry
efforts to gain some sense of clarity. Notice that the general path forward
was basically domain based and not individual user/client based. There was
a debate within the DKIM effort regarding i= vs d= to the extent that at
one industry event people were walking around with little stickers on their
badges to indicate which they supported. I believe that was courtesy of
Dave Crocker.



Thanks for that, I put a reference to your post on the wikipedia[*] 
(the original link to the FTC event expired sometimes in 2012).



Best
Ale
--

[*] https://en.wikipedia.org/wiki/Email_authentication#Rationale




































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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Fri, Aug 14, 2020 at 5:21 AM Alessandro Vesely  wrote:

> On 2020-08-10 7:24 p.m., John Levine wrote:
> > In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you
> write:
> >> Even an external reputation system requires recipient
> >> participation.   That is why I suggested both a
> >> send3="parameters" clause to indicate sender support for
> >> third-party authorization and a verify3="parameters" clause to
> >> indicate recipient support for third-party authentication. When
> >> both are visible to the non-domain message source, that source
> >> can have confidence that the message will be handled as
> >> authorized. >
> > We have had a lot of attempts at third-party authorization schemes
> > going back at least to vouch-by-reference in 2009 and ATPS in 2012,
> > and the Spamhaus Whitelist in 2010.  Every single one of them failed,
> > not due to technical problems, but because nobody was interested.
>
>
> We can either try and understand what was wrong in those schemes, or
> abandon authorization schemes forever.
>
> Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent
> success.
>
> PGP, GPG, and even personal CA certificates never became really
> popular, so we could have concluded that digital signature aren't
> worth considering for anti-spoof protocols.  Yet, someone thought
> about DKIM...
>

There is a little bit of history behind the impetus for SPF and DKIM. In
2003 and 2004 the FTC (U.S. Federal Trade Commission) held workshops on
Email Authentication and SPAM. It also let it be known that if the private
sector didn't come up with solutions it was willing to move forward with
regulation. This helped drive activity for SPF, the merger of DK and IIM
to create DKIM and Microsoft's push for SenderID. Private sector folks did
not want to risk what government regulation might look like. At that time
there were also folks pushing for PGP, GPG, Personal Certificate and
S/MIME as  paths forward. Even with that, it took a while for industry
efforts to gain some sense of clarity. Notice that the general path forward
was basically domain based and not individual user/client based. There was
a debate within the DKIM effort regarding i= vs d= to the extent that at
one industry event people were walking around with little stickers on their
badges to indicate which they supported. I believe that was courtesy of
Dave Crocker.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

On 2020-08-10 7:24 p.m., John Levine wrote:

In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you write:

Even an external reputation system requires recipient
participation.   That is why I suggested both a
send3="parameters" clause to indicate sender support for
third-party authorization and a verify3="parameters" clause to
indicate recipient support for third-party authentication. When
both are visible to the non-domain message source, that source
can have confidence that the message will be handled as
authorized. >

We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.  Every single one of them failed,
not due to technical problems, but because nobody was interested.



We can either try and understand what was wrong in those schemes, or 
abandon authorization schemes forever.


Some schemes, e.g. SPF's include mechanism, seem to enjoy a decent 
success.


PGP, GPG, and even personal CA certificates never became really 
popular, so we could have concluded that digital signature aren't 
worth considering for anti-spoof protocols.  Yet, someone thought 
about DKIM...



Best
Ale
--


























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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John Levine]

In article <2e5408af-c3c1-1b34-4600-70a355ef0...@bbiw.net> you write:
>I remember back then hearing various ideas or proposals and for many of 
>them thinking "I've no idea whether that will be useful or successful 
>but it sounds like something worth trying."  Not so much these days.  Alas.

I'm perfectly happy to try stuff but considering how concentrated the mail
business has gotten, unless a gorilla or two seems interested, "try" won't
really happen.

Also, we now have several more decades of experience about stuff that
seemed appealing but failed.  There's no shame in learning from experience.

R's,
John

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dave Crocker]

On 8/13/2020 5:21 PM, Murray S. Kucherawy wrote:
I'm disappointed that the experiment never really got its day in court, 
but the consensus is clear.  +1.


30 years ago, there was a generally adventurous tone in the community. 
Things are a lot more cautious now.


I remember back then hearing various ideas or proposals and for many of 
them thinking "I've no idea whether that will be useful or successful 
but it sounds like something worth trying."  Not so much these days.  Alas.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker  wrote:

> > We have had a lot of attempts at third-party authorization schemes
> 
> > With this in mind, I cannot see any point in designing yet another
> > vouching or authorization scheme unless we have evidence that an
> > interesting fraction of the world's mail systems want to use it. I
> > don't see that, and honestly see no chance that we ever will.
>
> +1
>

I'm disappointed that the experiment never really got its day in court, but
the consensus is clear.  +1.

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Mon, Aug 10, 2020 at 1:24 PM John Levine  wrote:

> In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you
> write:
> >>Even an external reputation system requires recipient participation.
>  That is why I suggested both a send3="parameters" clause to
> >indicate sender support for third-party authorization and a
> verify3="parameters" clause to indicate recipient support for third-party
> >authentication.When both are visible to the non-domain message
> source, that source can have confidence that the message will be
> >handled as authorized.
>
> We have had a lot of attempts at third-party authorization schemes
> going back at least to vouch-by-reference in 2009 and ATPS in 2012,
> and the Spamhaus Whitelist in 2010.  Every single one of them failed,
> not due to technical problems, but because nobody was interested.
>
> The only third party reputation systems that anyone uses are DNSBLs
> like Spamhaus that publish negative reputations, and even there you
> can count the ones with non-trivial use on the fingers of one hand.
>
> With this in mind, I cannot see any point in designing yet another
> vouching or authorization scheme unless we have evidence that an
> interesting fraction of the world's mail systems want to use it. I
> don't see that, and honestly see no chance that we ever will.
>
> R's,
> John
>
>
+1

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dave Crocker]

We have had a lot of attempts at third-party authorization schemes



With this in mind, I cannot see any point in designing yet another
vouching or authorization scheme unless we have evidence that an
interesting fraction of the world's mail systems want to use it. I
don't see that, and honestly see no chance that we ever will.


+1

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[John Levine]

In article <2ef8e773e7bf467481a05ab3fc4d9...@bayviewphysicians.com> you write:
>>Even an external reputation system requires recipient participation.   That 
>>is why I suggested both a send3="parameters" clause to
>indicate sender support for third-party authorization and a 
>verify3="parameters" clause to indicate recipient support for third-party
>authentication.When both are visible to the non-domain message source, 
>that source can have confidence that the message will be
>handled as authorized.

We have had a lot of attempts at third-party authorization schemes
going back at least to vouch-by-reference in 2009 and ATPS in 2012,
and the Spamhaus Whitelist in 2010.  Every single one of them failed,
not due to technical problems, but because nobody was interested.

The only third party reputation systems that anyone uses are DNSBLs
like Spamhaus that publish negative reputations, and even there you
can count the ones with non-trivial use on the fingers of one hand.

With this in mind, I cannot see any point in designing yet another
vouching or authorization scheme unless we have evidence that an
interesting fraction of the world's mail systems want to use it. I
don't see that, and honestly see no chance that we ever will.

R's,
John

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