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

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-

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

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 dele

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

 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 authoriz

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

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 --

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

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 sign

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,

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

> -- > *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 2

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

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, Au

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

On Wed, Aug 26, 2020 at 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 40bayviewphysicians@dmarc.ietf.org> wrote: > >> Are the weak signatures vulnerable to a replay attack?I thought that >> one of the reasons that DKIM

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 bo

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

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 requirem

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

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? >

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

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

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

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 subdom

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

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 recomm

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

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

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

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

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

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

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

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

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 origi

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

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 the

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

> 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, especia

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

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 rece

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

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

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

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

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

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

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

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

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

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

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 > be

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

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 i

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

y 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 wrot

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 pote

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

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

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

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 tru

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

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 analyz

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

> 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 beh

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

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 authen

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

iagnosed 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...@bayviewphys

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

tf.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 i

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 ki

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

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 r

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

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 th

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

On Sun, Aug 16, 2020 at 10:19 AM Hector Santos wrote: > 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 be

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

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 > vouch

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

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 cla

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

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. Th

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

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

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

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 au

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

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 p

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

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 va

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

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 o

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

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

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

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 hones

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

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"