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
On 6/20/2020 1:08 PM, Murray S. Kucherawy wrote: It wouldn't be hard to put a draft together that described the trivial things like Subject field tagging and "two dashes at the end mark the start of a signature', and maybe a couple of popular and mostly harmless mutations the popular list servers do. I might know someone who could help with such a publication. (I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...) Were I to chortle about any of this, it would be at the idea that any serious effort associated with email authentication could be considered altruistic... In terms of pragmatics, I think the issues here are time and risk. To get to a useful point will take too long for the current working group effort, and, given history and environment, its likelihood of being successful seems pretty low. That doesn't mean that none of it is worth pursuing, but rather than it might be worth considering independently of the current work and initially as IRTF-ish work, rather than IETF-ish. Perhaps if the effort were viewed as a staged sequence, over an extended time. Staging along the lines of: * Document a modest number of highly common 'patterns' of mailing list patterns. * Get reasonable community support (rough consensus) for the document -- including from MLM developers and operators * Formulate survivable authentication choices * Get reasonable community support for that approach * ... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On Fri, Jun 19, 2020 at 5:54 PM Dave Crocker wrote: > > I wish in hindsight I'd tried it > > anyway as an experiment, with maybe a couple of senders, receivers, > > and mailing lists as participants. > > While I can imagine devising something that would look appealing, I > believe it would have had a foundation of sand, in terms of operational > realities, since none of what it would be relying on was documented > standards and, again, there was (and I suspect remains) a view that > mailing list operators did not make good candidates for reliable > adherence to IETF 'standards'. All true, but if it had yielded useful results, there might have been encouragement to change that. Then, suddenly, there would be common ground from which to do future work such as this. It wouldn't be hard to put a draft together that described the trivial things like Subject field tagging and "two dashes at the end mark the start of a signature', and maybe a couple of popular and mostly harmless mutations the popular list servers do. I might know someone who could help with such a publication. (I can hear Dave and Pete, and perhaps Jim, chortling at my altruism...) -MSK ___ 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
Pete, you should see my draft folder! On 6/19/2020 5:20 PM, Pete Resnick wrote: On 19 Jun 2020, at 16:15, Pete Resnick wrote: [Offlist] Crap. My deepest apologies to Dave. I am very embarrassed by fat fingering that. It is not the worst private thing I've ever sent to a list, but still. (*Sigh*) pr -- 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] Header munging, not ARC, can solve the mailing list problem
On 6/19/2020 2:22 PM, Jim Fenton wrote:
That comes back to the question of whether the domain in the From header
is visible in the MUA, and if visible, does it alter user behavior
(e.g., discourage users from clicking phish links). Different people
have different opinions on that. A couple of messages back on this
thread, the blocking of email was discussed and that does not relate to
visibility of the domain in the MUA.
As an "MUA" author/developer, this is a matter on how aggressive the
end-user client software wishes is to be. We have seen this evolved
and increasingly employed over the years. I can them "Scare Tactics
Ponzi Schemes."
o Code Signing: Today, developers are being forced to fork up money to
order to stop scaring users that they are to install "uncertified"
software. While I believe this has good reason for FIRST TIME
installations, I considered it unethical, unfair for established
developers when the software is already installed and user is merely
upgrading.
o Self-signed SSL certs: Today, the browsers, especially Chrome, are
scaring the "manure" of the laymen users with FALSE complex page
display indications that they domain just intended to reach is not
secured. That is false. The target and common name match and it is
not expired. What remains is, once again, the lack of an authorized
3rd party signature requirement. The domain simply did not wish to
pay extortion fees to a CA that has a mechanism for an SSL trusted
chain. Thanks to Let's Encrypt, this is less of an issue today.
So do we consider advising MUA to add or don't add "Scare Tactics?"
I believe the MUA must begin to become proactive with assisting users
with the mails DKIM Policy and Trust-based indicators. I know some
cites have explored this that was before DKIM POLICY took how. How
will it play to today with DMARC. Overall, as a MUA developer, who
does have new MUA projects in the works, the perpetual mantra that "we
did that and it didn't work" and the idea that one size (one protocol)
must fit all and that is must scale, otherwise its useless, doesn't
really apply anymore.
We need to allow systems who are capable of giving the user more
confidence with what their eyeballs are seeing explore the considerations.
My take with all this since the beginning was since we don't know all
the answers on how people will use protocols, we should at least
provide the considered possible options for them to explore using
DMARC Tag Extensions. Here are few that can apply:
Proposed Tag Extensions:
-Rewrite=0|1 if 1, authorize any list system to rewrite 5322.From,
using the a "standardized" approach that helps keep the domains
original security.
-atps=0|1 if 1, the domain supports RFC6541 "DomainKeys Identified
Mail (DKIM) Authorized Third-Party Signatures"
and this one I just came up with to address this MUA display question,
just winging it now:
-MUA.From={logic to offer MUA on what to display}
The MUA can do its own lookup to see domain's desire to what to
display. Maybe the options can be:
-MUA.From=0 No advice (default)
-MUA.From=1 Display the Address with User Name
-MUA.From=2 Display just the address
-MUA.From=3 Only Display address when signer domain differs
Of course, with change comes new opportunity. If the MUA was updated
to support this tag, then we may not need the tag and just advise the
MUA to prominently display the address and/or when we have a 3rd party
resigner involved.
--
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
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
On Fri 19/Jun/2020 23:11:27 +0200 Pete Resnick wrote: > On 19 Jun 2020, at 15:07, Dave Crocker wrote: >> On 6/19/2020 12:02 PM, Pete Resnick wrote: >>> On 19 Jun 2020, at 13:38, Dave Crocker wrote: >>> But typical mediators are trying to maintain a sense and ability for the original author and the final recipient to experience an end-to-end message exchange. >>> >>> Yep. That's the point I was trying to make. >> >> Except you seem to be pressing this as essentially a requirement >> they have > > Ah, no, I think that's the crux of the misunderstanding: I was > responding to Alessandro, who I interpreted to be saying that *all* > mailing lists were, by definition, publishers, defining a publisher > like a newspaper, where the true author of the content are the folks > in the masthead, even though they acknowledge individual authors in > the by-line. I disagree with that view. Indeed, I think for most of > the mailing lists we have been referring to in this discussion, they > are not publishers in Alessandro's sense, but rather view themselves > as redistributors of author messages. As 5598 points out, there is > variance in how much "editing" is done by any given mailing list, but > again, for the discussion we've been having about how the From: field > should be used, we've been talking about mailing lists which do the > sort of minimal editing of messages. First, although the emphasis was on publishers, I didn't mean *all* mailing lists. Options 1.2 (Turn off all message modifications) and 4.5 (Have author domains sign camera-ready posts), with all in-between variations (e.g. have users manually add the subject tag on new messages, or attach a footer) are all valid alternatives. And there may be more (for this list in particular, it'd be enough for me to convert the body to base64 before signing.) Second, looking closely a the roles, what all mailing list do is keeping the list of recipients. Authors have no say on that, albeit they can add a few "direct" recipients themselves. Defining the end points is an essential point in communication, which prevents from considering the authors as agents. Also consider that authors have to keep on-topic, or they'd get reproached by the chairs. > (For mailing lists that do more substantial editing, I may not be as > motivated to keep the From: field unchanged. If we get more deeply > into the discussion, it might be useful to start drawing more distinct > circles around types of mailing lists.) 100% agreed. We should also loosely consider that in most countries there are legal constraints which practically force the addition of a footer. There are "informal" mailing list which ignore that pressure. There will always also be mailing lists which ignore DMARC. I don't think the latter should be among the possibilities specified in a standard. >> That most seek to preserve essentially all of the author's text is >> fine, but whether and how much is more of a 'business' decision than >> a technical one. > > We appear to be in violent agreement, as the quip goes. Importantly, I > think we agree that if a mailing list decides to preserve the original > From: field, in an attempt to preserve all of the author's semantics, > they are not "doing it wrong", as Alessandro's message appears to claim. What is wrong is to wittingly break DMARC. I just try for rationale. Best Ale -- ___ 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
