Re: [dmarc-ietf] Mediation and controlled forwarding
On 6/20/2020 11:53 AM, John Levine wrote: It would be nice if you'd looked at my conditional signing drafts before guessing (wrong) about what they say. Here's the 2014 version: https://datatracker.ietf.org/doc/draft-levine-may-forward/ And the improved 2018 version: https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Does this mean, the author, nows support and is going to champion his proposal? I seem to recall in 2014, the author citing a lack of interest to pursue this and felt it would cause problems. As stated in the 2014 security conditions, he wrote: 6. Security Considerations DKIM was designed to provide assurances that a message with a valid signature was received in essentially the same form that it was sent. The forwarding signature condition deliberately circumvents that design, to create a loophole for messages intended to be forwarded by entities that edit the message. It opens up a variety of obvious replay attacks that may or may not be important depending on both the selection of target domains for messages to be forwarded, and the behavior of forwarders that receive messages with conditional signatures. I felt then it was another "poison pill" to kill the 3rd party authorization effort. I was not impressed but this so I putted on the proposal. Now I read in the improved 2018 version: 6. Security Considerations DKIM was designed to provide assurances that a message with a valid signature was received in essentially the same form that it was sent. The forwarding signature condition deliberately creates a loophole for messages intended to be forwarded by entities that edit the message. It opens up a variety of obvious replay attacks that may or may not be important depending on both the selection of target domains for messages to be forwarded, and the behavior of forwarders that receive messages with conditional signatures. A sender can limit the conceptual size of the loophole by being selective about what other domains it allows in its !fs tags, and by using the x= tag to limit the time during which forwarded signatures are valid. If the author still believes this loophole exist, why are we bothering? -- 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] Mediation and controlled forwarding
On 2020-06-20 5:48 p.m., John Levine wrote: > In article you write: >> For example, a water tight opt-in protocol ... > > There's no such thing, unless you can somehow ensure that the list never > sends anything that any of the subscribers don't expect. Small MTAs can trust their (not anonymously registered) users, so they could blindly accept to weakly sign messages destined to a MLM that a user of theirs has implicitly recommended by starting such a (yet unspecified[*]) water tight opt-in. >> Without that, we're back to depending on reputation, for which simple >> whitelisting suffices.> > No, please see my message a few days ago about why ARC works the way it does. Do you mean https://mailarchive.ietf.org/arch/msg/dmarc/gll_AD80SzysVJi9GDeKM12OslA ? That message proves that ARC depends on reputation too. I mentioned whitelisting because it's simpler than ARC. My point is that, if an MTA is not Google, Yahoo, or some such, that is if it doesn't have the list of all MTAs worldwide, then the mailing list problem precludes reliable DMARC inbound filtering. I don't think, as Douglas suggests, that the MLM problem stems from not wanting to seek domain owner involvement. IMHO, it stems from domain owners not being able to maintain a global reputation list. The MTAs who can do that can do ARC, can whitelist, can do DMARC filtering; they don't have a "mailing list problem". Best Ale -- [*] See rough ideas at http://fixforwarding.org/wiki/Water_tight_opt-in ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation and controlled forwarding
In article <63ffc5ec-f5e3-4e15-9a1f-09bf00036...@email.android.com> you write: >Just as significantly, tbe MLM does not want to sign the same document as what >was signed by the author. If the document is unchanged, a conditional >signature is not needed. If tbe document is alrered after the first >signature, the first signsture is not applicable to the second signature. It would be nice if you'd looked at my conditional signing drafts before guessing (wrong) about what they say. Here's the 2014 version: https://datatracker.ietf.org/doc/draft-levine-may-forward/ And the improved 2018 version: https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation and controlled forwarding
In article you write: >For example, a water tight opt-in protocol ... There's no such thing, unless you can somehow ensure that the list never sends anything that any of the subscribers don't expect. > Without that, we're back to depending on >reputation, for which simple whitelisting suffices. No, please see my message a few days ago about why ARC works the way it does. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation and controlled forwarding
If conditional signatures require the participatuon of the author's MTA, then the consent of the domain owner is implied. DKIM scopes already provide a solution for delegating authority, but the MLM problem stems from not wanting to seek domain owner involvement. Just as significantly, tbe MLM does not want to sign the same document as what was signed by the author. If the document is unchanged, a conditional signature is not needed. If tbe document is alrered after the first signature, the first signsture is not applicable to the second signature. On Jun 20, 2020 7:13 AM, Alessandro Vesely wrote:On Sat 20/Jun/2020 02:52:55 +0200 John Levine wrote: > On Fri, 19 Jun 2020, Murray S. Kucherawy wrote: > >> A number of drafts were floated, as I recall. I had a couple. > > There's always my conditional signing hack, in which one puts a very > weak signature on the message which says it only counts if it's > resigned by X, where X is the expected mediator. Conditional signatures should be paired with a mechanism that tells the author's MTA when to apply them. For example, a water tight opt-in protocol whereby author, MLM, and author's MTA can do a three-hand handshake. Without that, we're back to depending on reputation, for which simple whitelisting suffices. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation and controlled forwarding
On Sat 20/Jun/2020 02:52:55 +0200 John Levine wrote: > On Fri, 19 Jun 2020, Murray S. Kucherawy wrote: > >> A number of drafts were floated, as I recall. I had a couple. > > There's always my conditional signing hack, in which one puts a very > weak signature on the message which says it only counts if it's > resigned by X, where X is the expected mediator. Conditional signatures should be paired with a mechanism that tells the author's MTA when to apply them. For example, a water tight opt-in protocol whereby author, MLM, and author's MTA can do a three-hand handshake. Without that, we're back to depending on reputation, for which simple whitelisting suffices. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation and controlled forwarding
On Fri, 19 Jun 2020, Murray S. Kucherawy wrote: There's a chance that it is possible to specify a small range of modifications and arrange a style of signing that could survive them. A number of drafts were floated, as I recall. I had a couple. There's always my conditional signing hack, in which one puts a very weak signature on the message which says it only counts if it's resigned by X, where X is the expected mediator. 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
