Re: [dmarc-ietf] Responses to IESG review comments on draft-ietf-dmarc-interoperability
On Wed, Jun 22, 2016 at 3:08 AM, Stephen Farrell wrote: > > > While mailing lists can be adversely impacted, I don't think > > s/can/are/ above, as previously agreed. > > > that they are necessarily more impacted than the other items > > which are called out in the body of the document. > > It is IMO entirely noteworthy that the primary mechanism used > to discuss the definition of mail protocols, including this one, > has been adversely affected by this mail protocol. > > One can quite rightly and fairly claim that that trade-off is > overall a win for the mail ecosystem, but not being explicit > about what has been the biggest downside of dmarc, from the > IETF participant perspective, seems plain wrong. +1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [arc-discuss] arc-05 draft released
On Wed, Jun 29, 2016 at 5:41 PM, Brandon Long wrote: I understand the desire to simplify, but arc users are going to need an > authres parser to take advantage of the data it provides, so it seems like > a good idea to include one. Yeah, just an idea. In either case, the document needs to include an ABNF for the modified format. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [arc-discuss] arc-05 draft released
On Tue, Jun 28, 2016 at 9:35 AM, Alessandro Vesely wrote: > > What's wrong with something readable? E.g.: > > arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-instance > [ CFWS] authserv-id > [ CFWS authres-version ] > ( no-result / 1*resinfo ) [CFWS] CRLF > > arc-instance = %x69 [FWS] "=" [FWS] 1*3DIGIT ";" > ; i=N; > I didn't say there was anything wrong with it. I'm just looking for a way to have all three ARC fields be parsable by a single grammar. Currently, AAR isn', because it's not a pure DKIM-style tag-value sequence. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-usage-00.txt
A minor point: On Sat, Jun 25, 2016 at 8:36 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance of the IETF. > > Title : Recommended Usage of the Authenticated Received > Chain (ARC) > Authors : Steven Jones > John Rae-Grant > J. Trent Adams > Kurt Andersen > Filename: draft-ietf-dmarc-arc-usage-00.txt > Pages : 15 > Date: 2016-06-25 > > Abstract: >The Authentication Received Chain (ARC) provides a means to preserve >email authentication results and verify the identity of email message >handlers, each of which participates by inserting certain header >fields before passing the message on. But the specification does not >indicate how intermediaries and receivers should interpret or utilize >ARC. This document will provide guidance in these areas. > > This version shows an "Obsoletes" on the title page. It should be removed; "Obsoletes" is used when one published RFC replaces another. The draft named there in this version has already ceased to exist. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Fri, Jun 3, 2016 at 8:24 AM, Barry Leiba wrote: > Murray, I've seen no response to Ned's note (which I agree with) that > explains why we think the charter, as written, covers the ARC work. > Do you have any follow-up, or did Ned's message address your concern? I think we can call it "addressed" by me accepting that I'm in the rough in terms of consensus. If my interpretation is singular, there's no need to dwell on it. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Tue, May 17, 2016 at 9:52 PM, Murray S. Kucherawy wrote: > And I agree, but then I also mentioned that we're now operating under the > second phase of the charter, or so the chairs seemed to indicate explicitly > with their "phase 1 is done" message. This citation is in the first; the > proscription against "additional mail authentication technologies" (which > also, by the way, exactly describes ARC) that I'm worried about is in the > second. > Reducing this to my basic issue, setting aside the matter of phases: There's one clause in the charter that says ARC is fine, and one that proscribes it. You appear to be claiming that the first one wins over the second, plain and simple. I don't understand why it's plain and simple. Why do they not have equal effect? Is there some "default allow" nuance when interpreting ambiguous charters? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Tue, May 17, 2016 at 6:15 PM, Dave Crocker wrote: > > 1) It feels like a bit of a stretch to call ARC "a form of DKIM >> signature", so I have to assume ARC falls under the second bullet. >> > > You seem to have missed the second sub-bullet under Item 1: > I assure you I didn't. I even said, clearly I thought: "...so I have to assume ARC falls under the second bullet." > Collaborative or passive transitive mechanisms that enable an >> intermediary to participate in the trust sequence, propagating >> authentication directly or reporting its results. >> > > That exactly describes ARC. (Did I mention that that wasn't an accident?) > And I agree, but then I also mentioned that we're now operating under the second phase of the charter, or so the chairs seemed to indicate explicitly with their "phase 1 is done" message. This citation is in the first; the proscription against "additional mail authentication technologies" (which also, by the way, exactly describes ARC) that I'm worried about is in the second. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Tue, May 17, 2016 at 5:46 PM, Dave Crocker wrote: > Relevant charter text: > > The working group will explore possible updates and extensions to the >>> specifications in order to address limitations and/or add >>> capabilities. >>> >> ... >> >>> Specifications produced by the working group >>> >> ... >> >>> 1. Addressing the issues with indirect mail flows >>> >>> The working group will specify mechanisms for reducing or eliminating >>> the DMARC's effects on indirect mail flows, including deployed >>> behaviors of many different intermediaries, such as mailing list >>> managers, automated mailbox forwarding services, and MTAs that >>> perform enhanced message handling that results in message >>> modification. Among the choices for addressing these issues are: >>> >>> - A form of DKIM signature that is better able to survive transit >>> through intermediaries. >>> >>> - Collaborative or passive transitive mechanisms that enable an >>> intermediary to participate in the trust sequence, propagating >>> authentication directly or reporting its results. >>> >> >> as against: >> >> 2. Reviewing and improving the base DMARC specification >>> >>> The working group will not develop additional mail authentication >>> technologies, but may document authentication requirements that are >>> desirable. >>> >> > > Any interesting topic produces real challenges in charter-writing and even > more challenges in charter-reading. > Indeed, I've yet to encounter a perfect charter. > However I read Item 1 as exactly matching the issue at hand and I read > that text as being unambiguously perfect for the specific proposal at > hand. (Hint: this was not an accident.) > > The current topic has nothing to do with Item 2, which is where the > constraint is placed. So the constraint is not relevant for the current > topic. > That feels like a convenient interpretation to me, for two reasons: 1) It feels like a bit of a stretch to call ARC "a form of DKIM signature", so I have to assume ARC falls under the second bullet. 2) The section of the charter you cite enumerates three "tracks', which it later calls "phases". If we're done with the first phase by sending our sole document to the IESG (which has happened, and the chairs have explicitly declared phase one done), then we appear to have entered a phase for which the charter proscribes things like ARC. > Yes, one certainly could wish for better writing. Sorry about that. But > really... I'm not opposed to developing ARC within this WG or even within the IETF. I just want to make sure we're following our own rules here, and that someone who later decides he hates ARC has no basis to appeal. If this needs fixing, let's fix it. If nobody really cares, let's move on. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Tue, May 17, 2016 at 1:43 PM, Steven M Jones wrote: > > Seems to me you've identified a contradiction in the charter, rather > than an objection to developing ARC... > > ...and I thought that's how I'd characterized it. But if the charter says we can't take on this work, or is ambiguous on that point, I think our process dictates we have to sort that out. I don't think I made any comment resembling "We shouldn't talk about ARC here." -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Tue, May 17, 2016 at 8:08 AM, Alessandro Vesely wrote: > > Does anyone object to having the DMARC working group take on this work? > I agree with Alessandro, but for procedural reasons: I'm not sure it fits within our present charter. The charter enumerates three tracks, the first of which appears to allow discussion of new protocols; in particular, one might argue that ARC is a "form of DKIM signature that is better able to survive transit through intermediaries". However, in the second track, it says "The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable", and there are chunks of ARC that are clearly new. (Having now implemented ARC, I can attest that there was enough new code needed that I would call it "new".) Absent a desire to form a distinct working group to develop ARC, I think we need to discuss rechartering before we can entertain this motion. > Does anyone object to using the two documents above as starting points > > for that work? > Modulo the first question, no. > ARC, as currently documented and conceived, aims at "a more nuanced > interpretation to guide any local policies related to messages that arrive > with > broken domain authentication (DMARC)." It does not propose any DMARC > improvement, let alone phase 2 milestone. > It proposes to provide a new authentication method that can more accurately reflect the "true" (for some value thereof) authenticity of a message, allowing DMARC to behave more accurately. How is that not an improvement? DMARC was meant to be extensible to better authentication methods as they appear, and this is an instance of such. > Unless ARC commits to a purpose congenial with DMARC's charter, I'd find it > objectionable for this WG to take on its work. > > > Does anyone have an alternative proposal? > > The "least broken" proposal for phase 2 seems to be dkim-conditional. It > emerged as an originator protocol, so it can develop without muddying ARC. > I have an unreleased implementation of that. It also more easily qualifies under our charter, IMHO. I think we should at least allow discussion of that one. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [arc-discuss] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Wed, May 11, 2016 at 7:19 PM, Roland Turner wrote: > > I'd suggest not. AS[1] permits a receiver (or other assessor) to determine > with some confidence that the putative signer made such an assertion about > the putative originator, it provides no information about the involvement > of the putative originator except to the extent that the assessor > additionally trusts the assertions of the putative signer. Decisions to > trust are necessarily outside the specification. This argument applies > equivalently to AS[0] independent origination scenarios and to AS[>0] > forwarding scenarios. > What would an i=0 ARC Set tell you that the i=1 set does not? As I understand it, an i=0 set would be the author asserting "I validated my own mail, and it was good." How would one consume such an assertion in a meaningful way? > > Yes, AS[1] testifies to the Authenticated-Results of receiving the >> message >> > from the originator. >> >> That only proves the first receiver was involved. A final receiver may >> trust >> its results or not. >> > > What is the first receiver reporting if not the authentication claims made > by the originator? > > > They could equally be reporting fraudulent claims in order to defeat email > security systems at (a) downstream receiver(s). > ...meaning nodes 0 (originator) and 1 are in collusion? Sure, that's possible, but how would requiring an i=0 thwart such an arrangement? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Wed, May 11, 2016 at 9:54 AM, Alessandro Vesely wrote: > > [... assume ARC-Seal: i=0 still verifies ...] > > >>> ARC-0 is substantially equivalent to a weak signature. The ARC-Seal > >>> field proves that the originator was involved. ARC-Message-Signature > >>> is expected to be broken by forwarders. ARC-Authentication-Results may > >>> contain just an auth stanza, with a possibly redacted authenticated > >>> identity. > >> > >> Doesn't the i=1 ARC set also prove the originator was involved? > > No, it doesn't. > Could you say why not? It seems to me the i=1 ARC set is validating the message authentication provided by the originator. That seems to qualify to me as "involved" on the part of the originator. > > Yes, AS[1] testifies to the Authenticated-Results of receiving the > message > > from the originator. > > That only proves the first receiver was involved. A final receiver may > trust > its results or not. > What is the first receiver reporting if not the authentication claims made by the originator? Confused, -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Wed, May 11, 2016 at 4:55 AM, Alessandro Vesely wrote: > It would be silly to deny that ARC is about indirect mail flows. The > reason it > is perceived to be in the wrong camp is that DMARC focuses on originators > of > email, while ARC requires no changes for them. A possible tweak is to > introduce an ARC-0, zero for originator, an optional ARC set with i=0: > Perhaps I'm misunderstanding, but doesn't an i=0 ARC set represent a verification by the originator of its own mail? > ARC-0 is substantially equivalent to a weak signature. The ARC-Seal field > proves that the originator was involved. ARC-Message-Signature is > expected to > be broken by forwarders. ARC-Authentication-Results may contain just an > auth > stanza, with a possibly redacted authenticated identity. > Doesn't the i=1 ARC set also prove the originator was involved? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Moving on to our next phase?
On Fri, Apr 1, 2016 at 12:21 PM, Kurt Andersen (b) wrote: > Thank you! I'll do my best to attend at least the APPSWG general session > (remotely). If there are any others pertinent to this work, please let me > know. > Please note that APPSAWG is in the process of folding into DISPATCH, so the session you're looking for is the latter one. APPSAWG will cease to exist soon. -MSK, co-chair of both of those ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt
On Thu, Mar 17, 2016 at 9:58 AM, Franck Martin wrote: > -- > > Yes, it should not be normative, documented is fine. I prefer documented > than part of the secret sauce... > Is it important that it be documented in the RFC series? Best Guess SPF isn't documented in an RFC as far as I can recall, but you can find it described on plenty of web pages that turn up in a web search. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability
On Wed, Dec 9, 2015 at 9:19 AM, Stephen J. Turnbull wrote: > > > 2.1. Identifier Alignment > > > > DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message > > source validation. The DMARC [RFC7489] mechanism refers to source > > domains that are validated by DKIM or SPF as Authenticated > > Identifiers. > > I would add > > The Authenticated Identifiers defined by these specifications need > bear no relationship whatsoever to the content provided by the > author of the message or even to the system which injected the > message, though they usually do. > Do we think that's necessary here, or is that same advice which is (I'm fairly sure) present in RFC6376 and RFC7208 sufficient? I guess another way to word that is: How independent is this work from full understanding of those? I suppose in the end it can't hurt to be sure and repeat this caveat here. > > 2.1.2. SPF Identifier(s) > > > > The SPF specification [RFC7208] defines two Authenticated Identifiers > > for each message. These identifiers derive from: > > > > a. the RFC5321.mailfrom [RFC5321] domain, and > > b. the RFC5321.HELO/EHLO SMTP domain. > > > > In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is > > defined to be based on RFC5321.mailfrom unless that value is absent > > (as in the case of "bounce" messages) in which case, the second > > (RFC5321.HELO/EHLO) identifier value is used. This "fallback" > > definition has occasionally been misunderstood by senders since > > "bounce" messages are often an "automatic" feature of MTA software. > > I don't understand the last sentence, specifically why automated > bounces would lead to a misunderstanding of SPF identifiers, and who > the "sender" is (author? RFC5322.sender?) > I would also change "In the SPF" to "In that", since the context is established in the first sentence. I agree, I'm not sure what that second sentence says at all. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: New Non-WG Mailing List: Shutup -- SMTP Headers Unhealthy To User Privacy
Of likely interest to this WG. A proposed charter is under discussion. -- Forwarded message -- From: IETF Secretariat Date: Wed, Nov 25, 2015 at 7:50 AM Subject: New Non-WG Mailing List: Shutup -- SMTP Headers Unhealthy To User Privacy To: IETF Announcement List Cc: alexey.melni...@isode.com, shu...@ietf.org, li...@nordberg.se A new IETF non-working group email list has been created. List address: shu...@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=shutup To subscribe: https://www.ietf.org/mailman/listinfo/shutup Purpose: Discuss ways in which user privacy can be protected when sending email, by making changes to the way header fields are used. For additional information, please contact the list administrators. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] handful of issues with draft-ietf-dmarc-interoperability-11
On Tue, Nov 17, 2015 at 9:19 AM, Kurt Andersen wrote: > > Thank you for the suggestions. I'll work on incorporating them in the next > couple of days. If I have questions as I do that, I'll ping you (Eliot) > directly.\\ > Since this document is in WGLC, could we please do that on the list? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt
On Tue, Nov 10, 2015 at 9:40 AM, Terry Zink wrote: > > OTOH, conditional signatures have been discussed for more than five > years (my > > dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha > > (Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document > (John's > > dkim-conditional-02) which would match the charter's "form of DKIM > signature > > that is better able to survive transit through intermediaries". Can the > WG > > coordinate publication of these two I-Ds? > > -1. > > Not because I don't think conditional DKIM can't work, but that we need to > focus on one solution. When someone asks "How do I get email to survive > DMARC if forwarded" we tell them "Go do this one thing" and not "Go do > either this *or* this." It's also easier for receivers to implement, debug, > and maintain one solution rather than two. > That makes it sound like we've already picked the one thing. I don't believe that's the case. But really I think we're getting a bit ahead of ourselves here. The current focus should be on finishing the interoperability document, not which protocol project(s) ought to progress toward standardization. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt
On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: > While the I-D will likely expires they will not be removed from the > website, so references will still work, so I don't see as that bad that > they are properly referenced in this document. I however agree we should > provide a quick summary for people that do not need the details. > On the flipside, I don't see what value they add; the ones that gain consensus will be published in their own right, and the details of the ones that don't probably aren't interesting to later readers anyway. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt
On Fri, Nov 6, 2015 at 11:09 AM, Kurt Andersen (b) wrote: > > > Section 4.2: >> >> I'm generally unsure about this section. It will eventually (sooner than >> later) refer to a number of expired documents. It might be more helpful to >> the reader to just summarize the idea behind each approach in a paragraph >> rather than forcing the reader to chase down specific expired I-Ds. >> > > I don't see a good way to avoid referring to (eventually) expired I-Ds. > That's the best way to catalog the ideas, but I did take your suggestions > on rephrasing the intent of some of them into some new wording. > I don't think you actually need to cite I-Ds just to enumerate the general approaches that have been proposed. Perhaps use this for the bullet list: o Third party authorization schemes provide ways to extend identifier alignment under control of the domain owner. o A way to canonicalize messages that transit mailing lists so that their alterations can be isolated from the original signed content. o A way to record message transformations applied at each hop so they can be reversed and the original signed content recovered. o "Conditional" DKIM signatures, whereby the author domain indicates its signature is only good if accompanied by a signature from an expected downstream relay. o Mechanisms to extend Authentication-Results [RFC7601] to multiple hops, creating a provable chain of custody as well as a view to message authentication results at each handling step. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-08.txt
On Tue, Oct 20, 2015 at 5:01 AM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance Working Group of the IETF.
>
> Title : Interoperability Issues Between DMARC and
> Indirect Email Flows
> Authors : Franck Martin
> Eliot Lear
> Tim Draegen
> Elizabeth Zwicky
> Kurt Andersen
> Filename: draft-ietf-dmarc-interoperability-08.txt
> Pages : 23
> Date: 2015-10-19
>
> Abstract:
>DMARC introduces a mechanism for expressing domain-level policies and
>preferences for email message validation, disposition, and reporting.
>The DMARC mechanism can encounter interoperability issues when
>messages do not flow directly from the author's administrative domain
>to the final recipients. Collectively these email flows are referred
>to as indirect email flows. This document describes interoperability
>issues between DMARC and indirect email flows. Possible methods for
>addressing interoperability issues are presented.
>
>
Sorry it took me so long to get to this, but here's the review I managed to
crank out on my flight to Tokyo today. It's largely editorial.
Section 2:
- I think p=none should be quoted.
Section 2.1:
- s/domain the SPF analysis/domain that the SPF analysis/
...or better yet:
"domain checked by SPF"
- s/Also note that/Also note that the/
- s/different from/different from the/
Section 2.2:
I can't parse the last bullet in the list. Should it be "...will likely be
in a different organizational domain than the..." ?
Section 2.3:
- s/here mentionned/mentioned here/
- s/headers and body/header and body/ (either both singular or both plural)
- s/whitespace folding/whitespace and folding/ (we also deal with
consecutive unfolded whitespace)
- "While the prevalence is unknown" -- Do we not have stats on this by now?
- s/checkers which/verifiers that/
Section 3.1.1:
- s/domains which publish/domains that publish/
Section 3.1.2.1:
- s/domain might also/domain could also/ (just for contrast with the
previous bullet)
Section 3.1.2.2:
- s/headers to bring headers/headers to bring them/
Section 3.2:
- s/Mail From/RFC5321.MailFrom/
Section 3.2.1:
- s/freemail/free email ("freemail")/ (define on first use)
Section 3.2.3:
- The bullet list has an odd format in terms of punctuation. Suggest:
o thing1;
o thing2; and
o thing3.
- The final bullet could reference RFC6377, which talks about that very
problem in more detail.
Section 4:
- s/still used and/still used, although/
- s/Ezmlm/ezmlm/ (2x)
- s/still deployed and has not/still deployed but has not/
Section 4.1.1.1:
- define "bounces" on first use; I think RFC5321 or RFC5322 has a more
formal definition
- s/risks which should/risks that should/
- "carefully managed" -- doesn't RFC6376 discuss this? If so, a reference
would be prudent here.
Section 4.1.1.2:
- end of first bullet: doesn't RFC6376 talk about this as well?
Section 4.1.3.3:
- s/policy which/policy that/
- Is that fist bullet talking about things like "On behalf of"? Also, what
sort of collision is the concern here?
- second bullet: s/Another mitigation policy is to configure/Configuring/
(for consistency with the second bullet)
- third bullet: s/Another mitigation policy, is to configure/Configuring/
- fourth bullet: s/Another mitigation policy, is to reject/Reject/
- s/understood and adjusted to/understood and accommodated/
Section 4.2:
I'm generally unsure about this section. It will eventually (sooner than
later) refer to a number of expired documents. It might be more helpful to
the reader to just summarize the idea behind each approach in a paragraph
rather than forcing the reader to chase down specific expired I-Ds.
The description of conditional signatures is over-reaching; there's no
requirement that the forwarder's signature "fully" sign the message.
A better description for dkim-list-canon: "record a canonical list posting
format for signing, so that typical MLM changes do not invalidate
signatures” or something.
- s/provides a proposed mechanism to provide/proposes a mechanism to
provide/
Section 6:
Suggested simplifications:
Section 4.1.1.1 discusses appropriate DKIM key management with third party
email senders.
Section 4.1.3.3 warns that rewriting of the RFC5322.From header field and
changing the domain name should not be done with any domain.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-02
On Sat, Oct 3, 2015 at 6:59 PM, Dave Crocker wrote: > Yeah, and what's interesting about that is that the spec does not > explicitly specify that signatures without a v=1 need to be failed. > I believe Section 6.1.1, first paragraph, has that covered. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-02
On Sat, Oct 3, 2015 at 3:21 PM, John R Levine wrote: I think at least the latter is a minor point since the XML source for >> RFC6376 is readily available. I'm happy to pick up the editor pen again >> if >> needed. >> > > My concern is that once the can is opened, it's hard to keep some of the > worms from escaping. Can't the charter help us keep the worms in check? Changes have to be within scope, for example; some of the old worms are off-topic here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-02
This has been implemented in an experimental branch of OpenDKIM, since about May. I haven't released it yet, but it's probably time to do that. I made a post some time back about changes I made in my implementation versus the spec. I'll dig that up too. For one thing, I apparently decided I didn't like the term "forward signature" and preferred "conditional domain", so the new tag is "!cd". We can argue about that and the other stuff when I find that post. If there's generally support for serious consideration of this approach, I suggest the chairs do a Call For Adoption. -MSK On Tue, Sep 29, 2015 at 10:08 AM, John Levine wrote: > I refreshed this draft so it wouldn't expire. Not very different, > mostly changed the @fs= to !fs= per Murray's suggestion. > > I still think this is the least broken way I've seen to let > mailing lists coexist with DMARC. > > R's, > John > > ___ > 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
[dmarc-ietf] Ping?
Hey, so uh, who's waiting on whom for what here? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weaker single author signature
On Thu, May 21, 2015 at 10:56 AM, Murray S. Kucherawy wrote: > > At Facebook there are no longer any email-enabled mailbox services, so > it's not among the more interesting of the big cases except for the scale > it handles. In terms of email it's just a forwarding service now. So > inbound, it would check v=1 and v=2 and DMARC, and then hand the whole > package off to internal analysis machinery for a verdict. If the message > survives, it's relayed; then, outbound, it would sign with v=1 and be done > because it's unlikely anything past that is an MLM. > > Gmail, AOL, and Yahoo would be interesting to hear about. > Also, the vast majority of FB's outbound traffic is notifications, not stuff that's user-generated, so v=1 outbound there is again all that's probably needed. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weaker single author signature
On Thu, May 21, 2015 at 10:27 AM, Terry Zink wrote: > > Not sure how other big mailers would do it, but I would think it would be > similar (especially Gmail). > > > At Facebook there are no longer any email-enabled mailbox services, so it's not among the more interesting of the big cases except for the scale it handles. In terms of email it's just a forwarding service now. So inbound, it would check v=1 and v=2 and DMARC, and then hand the whole package off to internal analysis machinery for a verdict. If the message survives, it's relayed; then, outbound, it would sign with v=1 and be done because it's unlikely anything past that is an MLM. Gmail, AOL, and Yahoo would be interesting to hear about. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weaker single author signature
On Wed, May 20, 2015 at 10:32 AM, Terry Zink wrote: > A weak single signature makes it more vulnerable to a replay attack. With > two signatures, the MTA --> MLM is protected (which is important) and the > MLM --> MTA is also protected although there is a time window of > vulnerability. However, if the first leg is protected then it's smaller > risk if the second leg is less protected. > > Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the > first time. > Right. The trick is deciding under what circumstances to add both a v1 and v2 signature. You could do it always, which smaller operators would probably do. It's terribly simple, and that covers your bases for interacting with MLMs a priori, but exposes you to a temporary risk when any of your users sends a message to any domain containing a bad actor. You could do it only if some local secret sauce determines that the intended recipient is an MLM. But that amounts to either use of heuristics (which can be gamed or come up with the wrong answer) or some kind of local registration process (which doesn't scale). The temporary risk is still there, but the threat surface is reduced because you inherently know a little something about the recipient domain. You could do it only for domains your users have declared contain MLMs with which they want to interact, but there again is the registration problem. There's also again the smaller threat surface, but this time you're also inherently trusting your users to make true declarations, and also to declare when the MLM is no longer of interest. That seems rather a burden. You could do it for all domains until they misbehave and then stop adding v2 signatures for them, but that can be gamed ad infinitum (domains can be trivially created and discarded). All of those options for any at-scale operator seem uncomfortable to me. The most obvious advantages to me of this method over ATPS, TPA, and that family of proposals are that (1) there's no additional DNS check required because the third party endorsement is contained within the message; and (2) it's quite a bit easier to implement than the others, at least for my project. Then again, if the at-scale operators that are home to most of the problem (we meet again, Mr. Pareto) are comfortable with using whatever homegrown heuristics they use now with the commensurate risks of v2 signatures, then this approach appears to me to be quite viable. Note that in fact the MLM doesn't have to check anything, or know any of this is even going on. Neither does its MTA even need to know what a v2 signature is; it simply re-signs the message and sends it along to the list subscribers. The whole point here is to make sure the MLMs know as little as possible so that all of them can be silently accommodated. > > The double signing hack limits the opportunity for trouble to mail > > systems that have a recent real message in hand. While I can > > certainly imagine spammy scenarios, it's hard to imagine ones that > > wouldn't be fairly easy to detect and shut down. If nothing else, if > > the original sender gets spam reports about double signed mail (there > > are FBLs that key on DKIM signature) it can tell who's screwing > > around and stop putting conditional signatures on mail to them. > True, the damage is limited to the lifetime of the last v2 signature the author domain added. I'm being cautious above because I'm sure author domains would prefer to be proactive about such threats rather than reactive to them. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Wed, May 20, 2015 at 6:20 AM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > > It is fairly common for a system to shutdown while being > > patched whenever an active exploit is noticed. Undelivered > > messages are then queued and retried later. Unreasonably > > short expiry will once again make DMARC a primary cause for > > message disruption whenever DMARC asserts inappropriate > > handling requests. > > Doug rephrased my concern about short expiry times quite well. Of course > author domains are free to choose what expiry they want, but the question > is: is it OK to design a(n extension to a) protocol which don't take the > existing status quo of Internet mail into account? > I don't think it's at all the case that we're not taking the existing status quo into account. In fact I'm explicitly saying the opposite: Operators need to select expiration times that balance the expected flow of email (with its typical and atypical patterns) with the security concerns of a signature that has a risk of abuse, and we would do well to remind them of this, either explicitly or by reference. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy wrote: > On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < > r.e.sonnev...@sonnection.nl> wrote: > > >> But when somebody gets around to trying to exploit this window, sites >> with quick (re-)delivery to most of their recipients will probably want to >> cut the length of that exposure down... >> >> >> which effectively kills the SMTP retry strategy concept [1] and hence the >> store-and-forward character of Internet mail, as we know it since the late >> 70's. Please note that SMTP itself has per command timeouts [2] which make >> short t= limits in the order of sub-minutes or some minutes unrealistic for >> some parts of the Internet and for delivery to some organizations which now >> and then have outages of more than a few minutes (no monitoring, no staff >> etc.). Also, note that large mailing lists may take some time to expand the >> address list and deliver the mail to all recipients... So when an >> expiration time is chosen it has to match the real world of mail delivery, >> which is far better than 20 years ago, but still isn't perfect... >> > > To your first point: SMTP itself isn't being altered by these proposals in > any way that I can see. We're not changing the parts of SMTP you > referenced. For one thing, if a DMARC rejection is undertaken by a > receiver, that action is final; there's no retry going to happen. For > another, we're not influencing which host is being selected or what the > retry interval might be, or how long a queued message should be held before > ultimately being returned as undeliverable. If DMARC recommended 4yz SMTP > replies when failures happen, that might be different, but that's not the > case here. All of this can be thought of as happening in a layer above > SMTP, not as part of it. > > To your second point: Those timeouts recommended by SMTP should at least > be referenced by any advice a conditional signatures draft might provide in > terms of selecting an expiration time. Such a section would also be wise > to talk about header field selection and the like. More generally, any > advice we can provide about what to consider when selecting the > construction of the conditional signature would be wise to include. > We also appear to be OK with imposing delivery timeouts that extend beyond the basic timeout set described in RFC5321, given what it says in RFC2852 (from 2000). -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > > But when somebody gets around to trying to exploit this window, sites with > quick (re-)delivery to most of their recipients will probably want to cut > the length of that exposure down... > > > which effectively kills the SMTP retry strategy concept [1] and hence the > store-and-forward character of Internet mail, as we know it since the late > 70's. Please note that SMTP itself has per command timeouts [2] which make > short t= limits in the order of sub-minutes or some minutes unrealistic for > some parts of the Internet and for delivery to some organizations which now > and then have outages of more than a few minutes (no monitoring, no staff > etc.). Also, note that large mailing lists may take some time to expand the > address list and deliver the mail to all recipients... So when an > expiration time is chosen it has to match the real world of mail delivery, > which is far better than 20 years ago, but still isn't perfect... > To your first point: SMTP itself isn't being altered by these proposals in any way that I can see. We're not changing the parts of SMTP you referenced. For one thing, if a DMARC rejection is undertaken by a receiver, that action is final; there's no retry going to happen. For another, we're not influencing which host is being selected or what the retry interval might be, or how long a queued message should be held before ultimately being returned as undeliverable. If DMARC recommended 4yz SMTP replies when failures happen, that might be different, but that's not the case here. All of this can be thought of as happening in a layer above SMTP, not as part of it. To your second point: Those timeouts recommended by SMTP should at least be referenced by any advice a conditional signatures draft might provide in terms of selecting an expiration time. Such a section would also be wise to talk about header field selection and the like. More generally, any advice we can provide about what to consider when selecting the construction of the conditional signature would be wise to include. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 1:58 PM, Steven M Jones wrote: > 6. What is the proposed t= time limit? Is 30 seconds enough? Too > long? Too little? > > I would guess too little, but at this point that's strictly a guess. > You need to leave enough time for possible network or other transmission > problems between the signer and the intermediary you're trying to > accommodate. > > > I expect you'll ultimately have to leave that up to the signer, no? > Traditional practice would set it sometime between hours and days. But when > somebody gets around to trying to exploit this window, sites with quick > (re-)delivery to most of their recipients will probably want to cut the > length of that exposure down... > Yes, absolutely this is at the discretion of the signer and not something to be fixed in a protocol document except perhaps to enumerate the tradeoffs between a short expiration and a long one. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 12:00 PM, Terry Zink wrote: > I think we’re making progress here. So, a message would look like this: > > > From: joe@authordomain.example > Authentication-Results: spf=pass (sender IP is xx.xx.xx.xx) > smtp.mailfrom=mlm.example; > dkim=fail (invalid body hash) header.d=authordomain.example > dkim=pass (signature was verified) header.d=authordomain.example; > > dkim=pass (signature was verified) header.d=mlm.example; > dmarc=pass header.from=authordomain.example (action=none > cd=mlm.example) > > DKIM-Signature: v=1; d=authordomain.example; s=selector; ... > > DKIM-Signature: v=2; d=authordomain.example; s=selector; !cd=mlm.example; > l=0; t= > > DKIM-Signature: v=1; d=mlm.example; s=foobar; ... > > Some questions: > > > > 1. This should be resistant to a replay attack 12 hours in the > future because the “t=” is part of the DKIM signature for > v=2, and if a phisher copy/pastes it and changes “v=2” to “v=1”, the “t= “ > part will be long past. Right? > "t=" is the timestamp at which the signature is generated, while "x=" is the expiration timestamp. So, you'd do "x=" where "lifetime" is the number of seconds you want the signature to be valid. If a phisher changes the "v=2" to "v=1", the signature is rendered invalid because that changes the part that's hashed. That attack won't work. > 2. This will be susceptible to a replay attack for 30 seconds after > initially sending it out, but only to the mailing list. Right? > It will be replayable for whatever the difference is between "t=" and "x=", by anyone that can generate a valid signature for the "!cd" domain. > 3. Verifiers need to know (enforce?) that a DKIM signature of “v=2 > !cd=” is not enough to verify a real signature without the > corresponding “v=1 d=” additional DKIM signature. In other words “v=2 > !cd=” is useless unless paired with something else. Right? > The idea behind changing "v=" is to cause verifiers that know about "v=2" to be the only ones that understand what "!cd" means, namely that the signature is not valid unless accompanied by a valid signature from the "!cd" domain. A verifier that doesn't know about "v=2" will simply ignore that signature entirely, so the condition cannot possibly be satisfied. 4. How should reputation engines accrue this message? To > authordomain.example (the one in the header.from)? Or to mlm.example, the > one in the smtp.mailfrom and DKIM d= domain that contained the strong > signature? > That's a good question, but one outside of John's proposal. I suppose you could accrue reputation on them severally, or jointly, or perhaps in some combinations. I don't know off the top of my head which would be best. > 5. Verifiers will need to check at least 3 DKIM signatures. Is > there a limit on the amount of signatures they should check? Presumably we > wouldn’t want a verifier to check 30 signatures. > It would be unusual to check more than three or perhaps five, I would think. It might be useful to collect information on how many we're seeing in the wild. Certainly a message bearing 20 or 30 might reasonably be regarded as a possible attack because a lot of DNS and crypto has to be done. > 6. What is the proposed t= time limit? Is 30 seconds enough? Too > long? Too little? > I would guess too little, but at this point that's strictly a guess. You need to leave enough time for possible network or other transmission problems between the signer and the intermediary you're trying to accommodate. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 11:24 AM, Terry Zink wrote: > > Sure, but can it just be in a comment if you find that useful, or is > it necessary to > > make that fact something a consumer of the field can parse out? > > Putting it into a comment is fine, maybe something like “dmarc=pass > action=none header.from= conditional.to=”. I > think it’s permissible to add additional fields like that into A-R, isn’t > it? > More like: dmarc=pass header.from= (action=, cd=) > I've always found the details of how it came to that conclusion to be of > only secondary interest > > > I agree with the reasons you outline, but when debugging and > troubleshooting potentially tens, hundreds, or thousands of messages per > day, it’s no longer secondary. It’s also easier to collect statistics on > how many messages are conditionally passing DMARC and what mailing list or > forwarder it is attached to. > You can create whatever structure you want in the comment (between parentheses). -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 9:19 AM, Terry Zink wrote: > >> I would think you'd have to. There's a replay risk that's unique to > this type of > > >> signature, so I think treating them the same would be a naive approach. > > > > > But is that something that an agent downstream of a verifier needs to > know? > > A-R for SPF doesn't differentiate between "-all" and "~all", for > example, nor > > does it relate key sizes or header field selection from DKIM. > > It’s useful for debugging afterwards. Someone, somewhere, will send me a > sample message that passed DMARC when it shouldn’t have (but in reality > passed because of a conditional DKIM) and it’s useful to have this in the > results. > Sure, but can it just be in a comment if you find that useful, or is it necessary to make that fact something a consumer of the field can parse out? The idea behind A-R all along has been to be able to say "method X passed/failed/whatever for this message, and the things it authenticated are A and B". I've always found the details of how it came to that conclusion to be of only secondary interest because: a) They might no longer be true at the time an MUA processes that header field; this is supposed to reflect what the ingress MTA saw. b) The goal is specifically not to allow MUAs or downstream agents to repeat the authentications done at the ingress MTA, otherwise why bother having the border MTA do it? There's also a DDoS possibility if every MUA or downstream agent repeats checks. c) Having to keep all the MUAs current on message authentication techniques is a much bigger burden than just updating ingress MTAs, so that model is observed. See RFC7001, Appendix D, for details. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Tue, May 19, 2015 at 4:47 AM, Scott Kitterman wrote: > >Is there any use in making a distinction to your acceptance/routing of > >messages to know it was based on a conditional signature versus an > >original > >author signature? > > I would think you'd have to. There's a replay risk that's unique to this > type of signature, so I think treating them the same would be a naive > approach. > But is that something that an agent downstream of a verifier needs to know? A-R for SPF doesn't differentiate between "-all" and "~all", for example, nor does it relate key sizes or header field selection from DKIM. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Mon, May 18, 2015 at 10:56 PM, Terry Zink wrote: > Thanks, this is useful. > > What would the Authentication-Results header look like? Presumably 3 > results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC? > Show one result or two? Or maybe something like dmarc=conditionalpass? > Three DKIM results, one DMARC "pass" result. The idea is that DKIM returns a "pass" for an aligned conditional signature, which satisfies the DKIM algorithm, so long as there's also a passing signature from the "cd" domain. Is there any use in making a distinction to your acceptance/routing of messages to know it was based on a conditional signature versus an original author signature? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Mon, May 18, 2015 at 5:36 PM, Terry Zink wrote: > > I've implemented it now in libopendkim as a compile-time experimental > feature, > > and it took me about four hours including testing. I just have to add > it to the plugin > > that uses the library, and it'll be available for others to play with. > > > > Can you give an example of what the stamped headers will look like? > Ideally on receipt by a list subscriber, the message would have the following DKIM signatures: DKIM-Signature: v=1; d=authordomain.example; s=selector; ... DKIM-Signature: v=2; d=authordomain.example; s=selector; !cd=mlm.example; l=0; ... DKIM-Signature: v=1; d=mlm.example; s=foobar; ... Things of note: 1) I changed "@fs" to "!cd" versus what John specified. I prefer "!" because we're calling that a "mandatory tag", and "cd" stands for "conditional domain" rather than "forward signature". Mostly personal preference, but I'd argue they're more correct (for some value thereof); I'll change them to wherever consensus lands if we decide we want to adopt this proposal. 2) I understand there's unresolved debate about updating "v=". I'll conform to that too when we make a decision. 3) The choice to do a weak signature using "l=0" was merely exemplary. There are other choices, like which header fields to sign or use of "l=", that can result in something weaker without being that wide open. 4) Similarly, I didn't set an expiration on the !cd signature, but should. 5) I've actually listed the signatures above in the opposite order I'd expect to see them on receipt. 6) The theory is that even if the author signature fails, the conditional author signature would be more likely to pass but is not valid without the MLM signature. libopendkim would report this to the caller as valid in the crytpo sense, but also note that the condition was not satisfied, so there's an error code associated with it. 7) Ultimately the caller sees all three signatures and their respective results. If the original author signature survived, it's available to influence message disposition as well as the others. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy
On Fri, May 15, 2015 at 1:28 PM, Dave Crocker wrote: >Performing DKIM/SPF validation upon receipt > There already exist several implementations of each of these, so I would say that they are currently deployed rather widely, making our cost near-zero. Plus, any DMARC operator already has at least one of them going. DKIM-signing all outbound mail. > Let's say that's close to zero cost as well. One thing absent from your list is conditional signatures, which is John's idea, and is a special case of both of these. I've implemented it now in libopendkim as a compile-time experimental feature, and it took me about four hours including testing. I just have to add it to the plugin that uses the library, and it'll be available for others to play with. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources)
On Fri, May 15, 2015 at 8:52 AM, Dave Crocker wrote: > > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone, I encourage re-reading Section 3.4.2 of RFC 5322. > Did you mean 3.6.2? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources
On Thu, May 14, 2015 at 11:27 PM, Terry Zink wrote: > > The Sender header field when present has been defined for > > decades to represent the sending agent! > > Maybe, maybe not. Outlook desktop client shows the Sender: header as > " on behalf of <5322.from>", but neither Hotmail/outlook.com nor > Gmail do. They just show the 5322.From address regardless of whether or not > there is a Sender: header. This Sender: DMARC fix requires a change in the > way these clients render email. Given the marginal additional benefit to > receiving mailing list traffic that won't implement any of the published > workarounds (not modifying content, fiddling around with Reply-To and From > addresses, changing the From: domain to be the mailing list domain), I > can't see why Gmail or Hotmail would want to make a change like that. I > agree with Murray that it isn't worth pursuing, the cost/benefit ratio > isn't there. > The definition of Sender isn't even what I'm talking about. Its use, not its definition, are what's historically been inconsistent. In particular, as I understand it, it has not historically been the case that all message generating agents that should add Sender, to identify the "actual submittor" (RFC822), have done so. People advocating for keying DMARC on Sender in addition to or instead of >From must then necessarily imply that we should start relying on the greater Internet to begin doing correctly something that has not been done reliably for a long time. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull wrote: > > What gets added from here forward really needs to be as innocuous > > as possible. I believe we're in a position where things like SPF > > and DKIM are still young enough that their implementations are > > malleable, > > I'm not sure what you mean. Now that I actually know what those > protocols do (and DMARC itself, for that matter), I don't really see > how they can be much improved. Do you mean the policy engines that > make decisions based on the output of SPF and DKIM implementations? > I'm saying that incremental changes to DKIM, SPF, and DMARC are far more likely to succeed than anything along the lines of "Everyone start using and paying attention to Sender", "Let's register yet another Sender-type field", or "Registration scheme X". The operational changes required for those three families of solutions are too enormous and involve too many wildcards for me to believe they stand a chance of success. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Wed, May 13, 2015 at 9:05 PM, Stephen J. Turnbull wrote: > > Currently ALL DMARC policy assertions ignore the role of the > > Sender header field. > > Which seems theoretically correct to me, as (unlike From) Sender is > not arguably a field reserved to Author Domains. Of course a Mediator > can make an assertion about Sender by DKIM signing it, but it seems > rather unlikely to me that Author Domains would want to make > assertions about Sender along the lines of "if Sender is signed, > consider the message to be authentic". > +1 here, and to pretty much all of this message. Moreover, current use of Sender by both producing agents and consuming agents is inconsistent. Suddenly relying upon it in addition to or instead of From for much of anything creates the need for a lot of people to change how they do things, and that seems unlikely in anything but a long time frame. So, too, is it unlikely that anything registering a No-Really-THIS-Is-The-Really-Real-Sender header field will gain widespread adoption. What gets added from here forward really needs to be as innocuous as possible. I believe we're in a position where things like SPF and DKIM are still young enough that their implementations are malleable, but trying to get every MLM, MTA, MUA, and MSA out there to suddenly use Sender universally and in a common way seems far less likely to be successful. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: > ATPS included an onerous task for any third-party service > likely used on a gratis basis. Each third-party was expected > to learn specific hash algorithms of each From domain. A > difficult process on top of changing their structure of DKIM > signatures repeated tens of thousands of times for each > different first party domain. In addition, reputations based > on the third-party relationship could not be leveraged > because of the optional hashing. > I continue to find this repeated claim specious at best. Section 7 of ATPS describes the structure of the experiment and invites feedback from anyone who tries it. Apart from Hector's recent declaration and one hobby user of my open source implementation that enabled it, there has been no feedback from the community at large that anyone has tried it or any variant of it. Given the pain point that a widely adopted authorized third-party signatures scheme (in general, not just RFC6541) would solve, one would think we'd have heard something in this regard in the last three years. Nothing beyond what I just mentioned has materialized. If you intend to claim that this is because of specific aspects in RFC6541 of how the DNS records are generated, I suggest you consider that even small operators don't have a problem computing hashes or populating DNS zones, because computers are good at automating things. Even if they did see those things as burdens, such operators tend to be the sort to provide that kind of feedback even about a protocol they ultimately can't use. Seriously, what person in the email space that you've met in the last N years would not take an opportunity to provide feedback, constructive or otherwise? We are a rather opinionated bunch and love the sounds of our own voices. Someone would've said something by now. But it hasn't happened. TPA has existed even longer than ATPS has, and it has enjoyed similarly goose-egg-shaped amounts of adoption. DSAP was around even before that, and the story is the same. What they all have in common is that they are not even close to something that serious operators would be willing to try. They are plagued by -- you guessed it -- the registration problem. Absent a change in that posture by the community at large, this is manifestly a dead end, and we really, seriously, need to stop burning any more of our precious cycles on it. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] double signing and what DMARC actually does
On Sun, May 10, 2015 at 10:42 AM, John Levine wrote:
> I find that between the axiom and your observation that third party
> trusted entities do not scale, you can pretty quicky tell whether a
> proposed hack is likely to be workable.
>
A re-signing scheme also has to have some mechanism for deciding which
third parties get the endorsement ("@fs=") from the author domain. One
might think of that as a "registry" with similar problems to those we've
been discussing, but it's just an entirely private one. So I'm not sure we
can plainly say registries are off the table, because you always have to
have some way to decide whether to affirm the relationship. It's a matter
of the method by which you do so.
But in your case, that registry doesn't need to be published anywhere; it's
implicit in the signature parameters, and is much easier to control
tightly, because it's per-message, and DKIM has a lot of parameters to play
with.
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy wrote: > That is, for a registration scheme, you might be testing for the existence > of a DNS record called A._related._dmarc.B. For a re-signing scheme, > you're looking for a signature from A that is somehow endorsed (for some > definition thereof) by a signature from B. The beauty of that mechanism is > that the signer gets to decide when to apply that endorsement, and with > what parameters. In fact, it's possible that A doesn't even know that B is > doing it. B could do it for all messages, which is simpler but increases > exposure; it could decide to apply the aforementioned heuristics and only > include the endorsement when it feels it's appropriate, which is safer but > requires a lot more internal infrastructure to support. Both camps are > enabled. > Sorry, I sent that too quickly. A couple of other points: In both schemes, you need a "registry", which is the set A as maintained by B through whatever means B wishes. Any DNS mechanism, however, requires that all mail flows from B via A are endorsed for as long as that DNS record is published (or cached); with the re-signing scheme, B gets to choose which specific messages carry that endorsement, via whatever logic it cares to apply, and for how long the endorsements are effective, and with what cryptographic strength and other parameters. We have evidence in hand that the queryable registry solutions are not attractive, evidence in the form of ATPS (RFC6541) for which the adoption rate was above zero by only a vanishingly small amount despite three years of open publication and an open source implementation. Despite other claims, there has never been evidence shown of interoperability of ATPS. The posting at the top of this thread makes such a claim, but it describes a single pre-RFC implementation interoperating with itself, rather than distinct implementations interoperating together; it is the latter that we tend to consider probative in IETF work. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sun, May 10, 2015 at 10:40 AM, Stephen J. Turnbull wrote: > > This "How do we populate the set?" is "the registration problem". > > There are some implicit "safely" and "at scale" adverbs in there > > too, just for flavor. > > Sure, but even with the adverbs it's not a "problem" for per-message > delegation proposals like yours and John's. For those proposals, we > already have technology in place for incoming messages (eg, Gmail user > filters) which could easily be applied to collect information from > incoming messages (and optionally from the users) and add delegation > fields computed *per user* per *outgoing* message. It's a *task* with > *costs* that can be estimated, they're not outrageous, and they > provably scale because they're already implemented at scale (for > different purposes). > > Those costs may still be too big to be justified by the prospective > benefits, but we need to come to some consensus on protocols and how > much risk of abuse they entail before we can estimate benefits, and > compute benefit/cost ratios. > Right, that's also a benefit of the dual signature approaches: the decision can be made based upon the characteristics of each message, in theory, where having to consult with a registry via the DNS implies the relationship is established for all mail. In the resigning methods, the registry, if one even exists, is completely internal and detached from the protocol. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sun, May 10, 2015 at 7:05 AM, Anne Bennett wrote: > But I think that some of the "re-signing" schemes being proposed at > the moment do *not* require this type of registration, so in those > cases, the registration problem wouldn't apply. If A is not "signing > B's mail", but rather, "signing its own modifications to B's message", > then the evaluation of the two signatures doesn't require a published > or pre-existing relationship between the two domains. > Yes, exactly; re-signing in some way that is entirely self-contained (i.e., does not mandate further queries to establish a relationship between A and B) appears to be far more promising than anything requiring a registration component. The theory behind some of my proposals tries to extend the basic notion of DKIM, which "allows a domain to take some responsibility for a message"; the idea in the extensions is to allow the different actors to claim responsibility for different parts of the content, and let the receiver decide what to do with that additional information. You allude to this here: Under at least one of the proposals, it can be determined that "yes, A > signed the mods, and if the mods are removed to re-generate the original > message, B signed the original message". If we have that, then I think > the question becomes: if this is to be a DMARC-like scheme, how do we tie > A's signature to some kind of relevant header field, since the "From:" > header is already "reserved" for the original signer. > In general, what you're hoping to do is confirm a relationship between A and B. A system involving a registration scheme seeks to query a registry for such relationships. The favorite way to do this is the DNS of B, where the set A would be published somehow. These other re-signing methods (and their variants) are seeking to confirm this relationship via two signatures that are somehow associated. That is, for a registration scheme, you might be testing for the existence of a DNS record called A._related._dmarc.B. For a re-signing scheme, you're looking for a signature from A that is somehow endorsed (for some definition thereof) by a signature from B. The beauty of that mechanism is that the signer gets to decide when to apply that endorsement, and with what parameters. In fact, it's possible that A doesn't even know that B is doing it. B could do it for all messages, which is simpler but increases exposure; it could decide to apply the aforementioned heuristics and only include the endorsement when it feels it's appropriate, which is safer but requires a lot more internal infrastructure to support. Both camps are enabled. > Now despite injunctions on this list against referring to the user > interface, the fact is that DMARC uses the "holy From: header" to extract > the "alignable domain". Unless I'm gravely mistaken, the reason for > that *is* indeed that this field is shown to the user (in some form) > by every user agent out there, and the user is thought to place a fair > deal of confidence in the "truth" of that header. Unless we can state > something similar with respect to another header, I suspect that > anything we propose will be considered to be watering down DMARC to an > unacceptable extent. :-( > I agree with both your context and conclusion here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] double signing and what DMARC actually does
On Sun, May 10, 2015 at 9:53 AM, John Levine wrote: > >Under at least one of the proposals, it can be determined that "yes, A > >signed the mods, and if the mods are removed to re-generate the original > >message, B signed the original message". If we have that, then I think > >the question becomes: if this is to be a DMARC-like scheme, how do we tie > >A's signature to some kind of relevant header field, since the "From:" > >header is already "reserved" for the original signer. > > You don't even need to be able to tell what part of the message is > attributable to which party. All you need to know is that the first > signer considers it to be close enough. > > Remember the key axiom of mail reputation: you cannot say good things > about yourself, only neutral or bad things. (This should be obvious > if you think about it for a moment, since any assertion a nice sender > can make, a nasty sender can also make.) Good stuff has to come from > trusted third parties, and given the difficulty of establishing trust, > that means the number of third parties has to be small. > This is an interesting observation when compared to DKIM and SPF, where you only actually know something about the message when they report a "pass". But that's authentication, not reputation. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or other re-signer), any more than there's any > way to deterministically decide what's a legitimate originator. Those > determinations are made heuristically outside DMARC. > I suppose the tl;dr version of my last reply is: The registration problem is not a red herring because it doesn't exist, but because it is intractable. Thus, any response to the third-party problem that relies on a solution to that problem (which includes ATPS, DSAP, and TPA) is probably not viable. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or other re-signer), any more than there's any > way to deterministically decide what's a legitimate originator. Those > determinations are made heuristically outside DMARC. > Numerous proposals have appeared over the years to solve the Mediator problem and its ilk, all of which involve advertising in some way that two domains are related somehow. The favorite example is "A can sign B's mail", with the implication being "and you should act as if B signed it". There are several problems with an approach like this: 1) The favorite way to advertise and check this is DNS. There are several arguments about why this needs to be avoided, so doing it again always draws them out again. 2) There isn't a nice way so far to do this at other than the domain level. That means any actor inside "A" can sign mail that claims to come from "B". So if "A" is compromised, "B" is hosed. The "B"s of the world tend not to be so thrilled with this. 3) Very large operators have millions or even billions of users. For "A can sign B's mail" to work, the set "A" for those operators is potentially enormous. (I think Yahoo quoted numbers well into five figures.) The "B's of the world tend not to be thrilled with this at all either, because every domain in the set "A" is a potential exposure. How do we populate the set? Either we do it (a) heuristically, because as you said it's not deterministic; (b) via a central authority (trusted by whom, exactly?); or (c) by letting the users of "B" populate it (which is obviously, one would hope, a huge abuse vector). This "How do we populate the set?" is "the registration problem". There are some implicit "safely" and "at scale" adverbs in there too, just for flavor. So suppose you come up with a heuristic that works for you. It reliably (magically?) adds a domain to the set "A" when a user at your domain subscribes to a list operated by a mediator within that domain, and reliably (magically?) removes it the minute all such relationships with that domain are broken. You are still faced with (1) and (2) above. Moreover, the magic you have to come up with would presumably watch your incoming and outgoing mail looking for things that look like lists, and update "A" when such are observed. Now I'm a Bad Guy(tm). I want to be able to send people mail that they believe is at least endorsed by you. I send mail to a random user at your site that looks like list traffic coming from BadGuyDomain.com. Your heuristic adds that domain to "A" because you don't want to mess with that user's list experience. Voila, I am now able to phish as you. So yes, DMARC doesn't necessarily need to spell out a solution to the registration problem. But that's not the issue; the concern is whether endorsing a solution that requires a registration step, regardless of how it's accomplished, is a pragmatic thing to pursue in the first place. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull wrote: > > Agreed again. And as Terry has said and I think we can infer about > > other large operators, it's incorrect to assume (and plain wrong to > > assert) that this is an easy problem for them to solve in a > > reliable way. > > Please define "reliable." I gather you all think that missing some > mailing lists is a bigger problem than missing all of them, but for > the life of me, I cannot see why. > I'm having trouble coming up with a heuristic that is even certain to grab "most" of them. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Fri, May 8, 2015 at 10:29 AM, Anne Bennett wrote: > > Murray S. Kucherawy writes (with respect to ATPS if I got this right): > You did. > >> There's still that pesky registration problem to address. > > Hector Santos writes: > > [...] > > Therefore, I don't think that SPF has a "registration problem". > It has plenty of other problems, but not that one. ;-) > Agreed. > But if I understand correctly, it's being suggested that for > various proposals made here to work, either the sender's mail > system or the final receiver's mail system would have to become > aware of all of the "legitimate" (definition purposely left > out!) mailing lists to which its users subscribe. > > To me, *that* is a registration problem. > Agreed again. And as Terry has said and I think we can infer about other large operators, it's incorrect to assume (and plain wrong to assert) that this is an easy problem for them to solve in a reliable way. > I believe that some people have claimed that this problem is > easily overcome (or perhaps "worked around" would be a better > expression) by examining mail headers and gathering statistics, > and this may well be the case, but addressing the problem in > this way will always depend on heuristics, just like any other > anti-spam method. > Right; the claim is that this is a well understood problem and that the cost of implementing it is low. I don't agree. In addition to the above, no two operators will have exactly the same idea of what fits here, or what components of their local system they need to include. Punting on this as an "implementation issue" leaves a pretty substantial hole in whatever gets rolled out. To me it's like buying a car with a completely absent steering mechanism, and you have to do the research to figure out which one fits and works for you, and probably build it yourself too. At a minimum, we need to describe detailed requirements of this component. Having something open source that works in general would also be helpful, but at best we only have a rough sketch of what that would look like right now. I cannot see how it would approach a reliable pass/fail result, > which I've been told is what DMARC is all about: don't make the > users have to decide anything! Handle it all before delivery! > > What am I missing? > Not a thing. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A Modest Proposal of Two Variations
On Wed, Apr 29, 2015 at 5:04 AM, Stephen J. Turnbull wrote: > J. Gomez suggests: > > > > That would force DMARC-compliant Mediators to reject (or accept > > > > but not resend) incoming email from p=reject domains, > > > > irrespective of whether such mail passes or not the initial > > > > incoming DMARC checks. > > Something about having mediators (ie, non-MTAs) implement this check > was bothering me. I realized that the nagging thought was the > *Mediator* doesn't have to do it. > > Variation A: > > The *outgoing MTA* can do this check; it has the same information (the > "From" field, the DKIM signature, and the DNS) that the mediator does. > This outgoing check is just a variation on the spamfighting theme of > "if pretty much anybody can send from your system, you have to check > outgoing mail as well as incoming mail." > [...] > Outgoing from the Author, or outgoing from the Mediator? Either way, it seems to me that this is something a fully compliant participant might do, but that broken or hostile actors won't bother doing. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Thu, May 7, 2015 at 4:24 PM, Scott Kitterman wrote: > No, it's OK for DKIM. The trick is d=ietf.org, which doesn't align for > DMARC > purposes. > We're saying the same thing, I think. I'm presuming a post-MLM message with an author domain signature and an MLM domain signature. The aligned author signature will presumably fail, and the ietf.org signature will presumably pass. That's all pure DKIM will tell you. DKIM+ATPS would tell you the additional bit that the From: domain signer also approved the ietf.org signature, but as presently specified, DMARC doesn't care about that. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC as > specified, that's a fail. > > More precisely, for both DKIM and DMARC it's a fail. For DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that. I think it's also important to note that this only proves interoperability with a single implementation (granted, in multiple roles), unless there's data indicating multiple implementations are involved. This seems unlikely, since as far as I know there aren't any other implementations of ATPS-04 or even the RFC version. OpenDKIM did the RFC version, and it's not compatible with -04. Also, this is only part of the whole story. There's still that pesky registration problem to address. I think for ATPS or anything like it to be considered a plausible thing to pursue, that's critical. It might be interesting to know some of the characteristics of the largest operator involved in that report (total domains, total users, details about MLM traffic, etc.). -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Tue, May 5, 2015 at 1:17 PM, Terry Zink wrote: > > > What advantage does this have over John's proposal? It actually looks > more c > > complicated to me, because it spans the divide between DKIM and DMARC. > John's > > proposal is completely contained within DKIM. > > > John’s proposal changes DKIM but also requires additional changes in DMARC > to respect the changes that were made to DKIM when doing alignment (the > @fs=domain is more or less the same as the Original-To below). If I rescind > my DKIM v=2 to only v=1, then it requires changes to DMARC analysis logic > (which John’s would have required anyhow to extract the @fs and compare to > the from address); and, requires some configuration changes to senders in > DKIM but no code change (unless adding a second signature requires a code > change). > > I interpreted John's proposal to mean a DKIM verifier would not pass a signature with "@fs=" unless it was also accompanied by a signature from the "fs" domain. Thus, the modified result logic is completely within the DKIM module, which DMARC then consumes. It's a much cleaner separation of function that way. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Tue, May 5, 2015 at 1:24 PM, John R Levine wrote: > John’s proposal changes DKIM but also requires additional changes in DMARC >> to respect the changes that were made to DKIM when doing alignment (the >> @fs=domain is more or less the same as the Original-To below). ... >> > > It's not supposed to. The decision about whether a DKIM signature that > depends on a chained signature is valid is supposed to happen entirely > within the updated DKIM module. DMARC just uses that result. I assume the > DKIM module is able to look at all of the DKIM signatures on a message and > report back which ones are valid. > Other chatter on this list suggests that not all DKIM verifier implementations work that way, unfortunately. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Tue, May 5, 2015 at 12:28 PM, Terry Zink wrote: > From: Joe User > *** To: fr...@hotmail.com > Original-To: b...@birdwatchers.org > *** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast![...] > DKIM-Signature: v=1; d=yahoo.com; > h=from:date:subject:to:mime-version:message-id:content-type:original-to; > DKIM-Signature: v=2; d=yahoo.com; l=0; > h=from:date:to:mime-version:message-id:content-type:original-to; > *** DKIM-Signature: v=1; d=birdwatchers.org; > h=from:date:to:mime-version:message-id:content-type:original-to; > *** List-Id: "Birdwatchers in the Northeast" > > [...] > > - This would be an add-on to DMARC and an add-on to DKIM, but not a big > one. In fact, the DKIM-Sign v=2 could be v=1. DMARC would know not to align > a weak DKIM signature (l=0) with DMARC by itself (indeed, we are basically > saying l=0 should not be used for normal DKIM trust relationships). So it’s > no add on to DMARC. > You're either saying this change belongs in DKIM (which then ascribes special meaning to this kind of signature combination, or to "v=2" signatures, or something), or you're leaving DKIM alone and saying that the analysis logic appears in DMARC. What advantage does this have over John's proposal? It actually looks more complicated to me, because it spans the divide between DKIM and DMARC. John's proposal is completely contained within DKIM. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Tue, May 5, 2015 at 11:55 AM, John Levine wrote: > > Not so good, since there are lists that do't have list-id and spam > that does. > > There's a large class of approaches that either require registration, > the various third party signers, or would likely work better with it > like my double signing thing. But it's clear to me that if there were > an easy way to register lists globally, we would already have done it. > > Large providers have a pretty good idea of who's sending them list > mail, e.g. Google notes in in their DMARC reports, so they can use > their own list if they want. Small providers will have to do other > stuff, but ad hoc approaches like adding lists when users compiain is > probably OK. > > So I'd just note when something needs or would be aided by > registration but not waste time trying to invent a way to do it. > > My taking that run at it showed me that an example is necessary to illustrate the goal and the general idea of the mechanism, and potential problems with trivial solutions. We could try relegating it purely to prose, but even a concocted example would probably be useful. So the stuff you're talking about here would go in what I labeled as , and the whole thing should read as "A naive implementation could do this, but it's easily defeated by X, Y, Z; you have to do something better that matches your requirements" or something like that. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman wrote: > Wrapping a 'somebody else's problem field' around the registration piece > of this doesn't make it any more feasible. > Is it sufficient to say something like this?: "A participating operator needs to solve the registration problem. Different operators will have different capabilities, requirements, and limitations here. A very simple approach would be ; however, this has the following drawbacks: . Non-trivial solutions may or may not appear in later documents." This illustrates the problem and the importance of solving it in some detail which would give someone "skilled in the art" enough context to come up with something in his or her particular environment, while not constraining DMARC to something that is not universally useful. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Tue, May 5, 2015 at 9:50 AM, Scott Kitterman wrote: > >But the main point that everybody is missing is that we *do not* need > >to deal with the "registration problem" in this WG because the > >information to register a substantial fraction of mailing lists is > >distributed in the related mailflows already, and the mailbox > >providers know where to find the users for confirmation of their > >intent. There's no need for new protocols. > Doesn't this presuppose that only good actors use that information channel properly? > >I would prefer to focus on getting a signature delegation protocol > >specified and hopefully put into practice, discussing mailing list > >verification practices when potential users bring them up. > > No. I believe that entirely assumes away the hard part of the work. The > hard part isn't figuring out candidate data. That can trivially be done as > you suggest. The hard part is figuring out the subset of the data that's > worthy of special treatment. > > Approximately as soon as list-id enables DMARC bypass, the bad guys will > start adding it to everything. List-id is useless in this context. > I think that's right. I'm guessing that the Gmails of the world have heuristics that go beyond List-Id for identifying what incoming flows are legitimate lists and which are not. On the other hand, for small operators, maybe List-Id is enough of a good starting point to suggest it, without baking it into a protocol document as something normative. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow
On Fri, May 1, 2015 at 8:55 AM, Anne Bennett wrote: > > Franck Martin writes: > > Note that postfix/sendmail can DKIM sign the bounces it creates. > > A few weeks ago I searched for documentation on how to make > Sendmail sign its bounces, and I failed to find anything. > If you could point me at any document at all as a starting > point for that, I'd be grateful. DKIM signing in sendmail is done via its milter API, which is instantiated only when traffic arrives via SMTP. DSNs are generated and queued internally, not via SMTP. Thus sendmail does not sign its bounces. The only way to do that would be to have the sendmail instance generating the DSN route the DSN through a second MTA on its way out, and that second one would do the signing. I have no idea if any of that is true for postfix, but I believe it has hooks for calling milter APIs even for non-SMTP messages. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos wrote: > I downloaded OpenDKIM source code to see whats it offers. I believe I saw: > > o ADSP was no longer supported, pulled. Grep showed one instance of an > inline comment referring to ADSP. > Correct. > o ATPS was offered, but I failed to see how it was hooked into ADSP > because it ADSP was pulled. > It has nothing to do with ADSP. o DMARC was offered. > OpenDKIM doesn't know anything about DMARC other than the fact that "dmarc=" is an Authentication-Results field is not a syntax error. OpenDKIM runs in the milter stream before OpenDMARC does, and OpenDMARC consumes the results OpenDKIM provides. > ATPS was suppose to be based off the ADSP record with the optional tag > "atps=y" I believe that is how it worked. If the "atps=y" was present in > the ADSP record, then ATPS was supported and an ATPS_Hash(ADID, SDID) > lookup was done. > Nope. See RFC6541. > If OpenDKIM is popular among many big systems, it would make sense to > slightly update OpenDKIM so that the "atps=y" option is based off a DMARC > lookup. The change is small. > Sure, if that's consensus. That would also involve promoting ATPS to the Standards Track, but to do that we'd need to see some hope that widespread deployment is likely. But we still have that pesky registration problem to deal with. > Maybe Murray can explain how its setup and triggered in OpenDKIM. > If you enable it, you just have to name which domains you authorize to sign for you. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Wed, Apr 29, 2015 at 6:26 AM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote: > Right. I'd been avoiding that because I saw this as a relatively minor > change to Murray's draft-kucherawy-dkim-transform-00, but if message > wrapping is considered a nonstarter, a new I-D is in order, assuming that > there's a simple, secure, and palatable way to divide any arbitrary message > body into its "original Author part" and "list decoration part(s)", > irrespective of the Author's part being good-ol' text or MIME. Since we're just throwing out ideas, I don't mind adding your "stf" idea to the transform draft. Just send me some text. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 2:37 PM, J. Gomez wrote: > Apart from the CANNOT bit, is that different from where we are today? > > Well, the CANNOT part would impede the whole lot of problems we are trying > to solve, wouldn't it so? > Maybe. I was just confirming that that's the only part that's different in your proposal. I think there's a concern with this approach though. I don't believe we can just come up with something new on the standards track and then go hit operators over the head with it telling them they're non-compliant. That tends not to be well-received, to put it lightly. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 1:23 PM, J. Gomez wrote: > Couldn't the DMARC specification spell out that Receivers claiming to be > DMARC-compliant, when choosing to *accept* incoming messages from Senders > publishing p=reject (irrespective of whether such accepted messages passed > or not the DMARC checks), CANNOT after-the-fact reinject such received > messages into the public email infrastructure in any way that could render > them (or reveal them to be) DMARC-rejectable? > > So that if any Receiver-turned-Originator (i.e., Mediator) does otherwise, > they CANNOT claim to be DMARC-compliant? > > That would force DMARC-compliant Mediators to reject (or accept but not > resend) incoming email from p=reject domains, irrespective of whether such > mail passes or not the initial incoming DMARC checks. > > Then, if the market deems DMARC valuable by itself, pressure would be > applied by the "invisible hand" there were it needs to be applied (so that > reputable actors in the email ecosystem could claim to be DMARC-compatible). > Apart from the CANNOT bit, is that different from where we are today? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 12:27 PM, J. Gomez wrote: > > The question to me is whether the message that the MLM software emits > > is the same as the original message. If it is, then the Author ought > > to be preserved across the MLM. If it is not, then the MLM emits a > > new message, and it actually SHOULD NOT keep the Author the same, as > > described above. So we get to argue about "same", and of course the > > specs aren't particularly rigorous about this. > > > > RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that > > it doesn't change From, from which I infer it doesn't change Author, > > although it does say it's a "new" message that's emitted. > > It seems RFC5598 says 3 things: > > 1. That the Author and only the Author goes in the Header-From. Period. > 2. That mailing lists keep the "original Author" (sic) in the Header-From. > 3. That mailing lists also become an Author when they retransmit a message > (Section 5.3: "Because a Mailing List can modify the content of a message > in any way, it is responsible for that content; that is, it is an > Author."). > > I see point 1 as normative, point 3 as an arrived conclusion (logical > deduction) and therefore also normative as long as it is logically valid, > and point 2 as documenting customary practice at the time that document was > written. > > So it seems, as per RFC5598, that a message mediated by a mailing list > which alters its content has, at least, to Authors: the "original Author", > and the mailing list itself. > Keep in mind that RFC5598 is Informational. It doesn't prescribe or proscribe anything. It just describes the "current" (at the time) email architecture. RFC5322 and its ilk are Standards track, and thus normative. Even if we were all to concur that altering the From by adding the list is the right way forward here (an intriguing idea at the moment), the question of ordering would need to be addressed, and then how that applies to all the standards we're talking about, and how MUAs need to be nudged to make use of such things. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Mon, Apr 27, 2015 at 4:17 AM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote: > On Sun, 26 Apr 2015 12:21:04 +0200, > "J. Gomez" wrote: > > > On Sunday, April 26, 2015 2:25 AM [GMT+1=CET], Stephen J. Turnbull wrote: > > > > > The From header field is not in the public domain, and not available > > > for appropriation. "Taking ownership" of something that isn't yours is > > > properly called "theft" > > > > Is the message Subject in the public domain? Is the message Body in the > > public domain? Why are many mailing lists taking liberties with them? > > Sorry, but I think your analogy of email vs property does not compute. > > Whether any header field is in the public domain is a legal question on > which I won't venture an opinion, but the From header stands out as one > that is treated specially by RFC5332, section 3.6.2: > >[...] The "From:" field specifies the author(s) of the message, >that is, the mailbox(es) of the person(s) or system(s) responsible >for the writing of the message. The "Sender:" field specifies the >mailbox of the agent responsible for the actual transmission of the >message. For example, if a secretary were to send a message for >another person, the mailbox of the secretary would appear in the >"Sender:" field and the mailbox of the actual author would appear in >the "From:" field. If the originator of the message can be indicated >by a single mailbox and the author and transmitter are identical, the >"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD >appear. > >[...] > >In all cases, the "From:" field SHOULD NOT contain any mailbox that >does not belong to the author(s) of the message. [...] > > It seems clear to me that, at the very least, the mailbox of the message's > author ought not to be and replaced by the mailbox of an automaton that > added a subject tag and a list trailer. If the mailing list software has > made DKIM-breaking changes, it may make sense for it to *add* its own > mailbox to the From header (as a "coauthor"), and make itself the > Sender. > The question to me is whether the message that the MLM software emits is the same as the original message. If it is, then the Author ought to be preserved across the MLM. If it is not, then the MLM emits a new message, and it actually SHOULD NOT keep the Author the same, as described above. So we get to argue about "same", and of course the specs aren't particularly rigorous about this. RFC5598's definitions, in Section 5.3 (and indirectly 5.2) say that it doesn't change From, from which I infer it doesn't change Author, although it does say it's a "new" message that's emitted. That document is not a proposed standard and merely documents current use (as I understand it), so it's merely recording the fact that MLMs technically violate the SHOULD NOT. So it seems to me the points of contention here are: 1) Is the MLM violation of the SHOULD NOT cited above the kind of violation that we accept based on how "SHOULD NOT" is defined in RFC2119? It seems to me that it is, especially given how long they've been doing it without objection (until now). One could argue they've been "getting away with it" for too long, but we can't change history. 2) Is the MLM emitting a new message? I would agree with Michael and contend that it is if there have been any content changes at all, in the same way that someone making a compilation of a series of independent works (a "mix tape") owns the copyright on the mix, though not on the original material. Now, MLMs do that with digests already -- who else could one legitimately put in the From of a digest? -- but typically not for resent messages. To the point of Message-IDs, I would say that should follow the same rule as the From change: If the content changes, it's a new message, and it gets a new Message-ID. Might it be sufficient to declare an "Original-Message-ID" or "Author-Message-ID" or "List-Original-Message-ID" field that contains the author-generated Message-ID, allowing for the duplicate suppression that's done now? If MUAs do unpredictable things with multimailbox From headers, it > may be because they don't see them often enough. I'm sure they'll fix > their errors if list mail begins to arrive with heretofore unusual but > RFC5322-compliant headers. > I would far rather have MUA developers work with us directly, but the IETF has a persistent allergy to us tampering in user space. As I understand it, our desire in general tends to be to create well-defined interfaces (not APIs, mind you) at which MUAs can "meet" us on their own, and let them take it from there. Thus, the best we can do is be very clear about what information is presented by a multi-From message and perhaps why, and hope they'll adapt. The sad legacy is that different mail operators have historically done different things, which has led to MUAs doing different things, which has in turn led to a global sy
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thu, Apr 16, 2015 at 11:34 AM, John R Levine wrote: > At least, we need to look at what non-technical costs they push onto other > parties. > > Some changes have insignificant non-techincal costs and are not > controversial, e.g., adding a List-ID header for the benefit of recipients > who know how to use it. Changes that seem similar may have quite different > costs, e.g., adding a List-ID and removing subject tags, forcing recipients > to change the way they sort and organize their incoming messages. > Rolf kind of said what I'm thinking here: I agree that we need to look at the costs. But are we willing, or not willing, to accept costs that are not zero? For example, asserting that all parties should have to take on zero non-technical cost here seems like it might leave us dead in the water before we even start. I don't have a good non-zero suggestion though, because it's hard (or maybe even impossible) to be specific. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Thu, Apr 16, 2015 at 9:31 AM, John Levine wrote: > The most tedious and unhelpful discussions here have implicitly (or > perhaps explicitly) assumed that receiver nontechnical costs don't > matter, then repeatedly pointed out the true but useless fact that > there are single party mediator changes with trivial technical costs. > Useless because it presumes the non-technical costs of those changes are high? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Wed, Apr 15, 2015 at 1:39 PM, Scott Kitterman wrote: > For the umpteenth time, the issue isn't managing a DNS zone. That's the > easy > part. The hard part is knowing what to put in it. Many companies, not > even > the really big ones, have thousands of domains. Go publish SPF, DKIM key, > and > DMARC records for 4,000 domains and then tell me it's all easy to then > figure > out what the right list of authorized forwarders should be for each one. > +1. Also, if one were to interpret the Pareto Principle correctly, it actually favors the idea that the only things we should consider are the ones the large operators are willing to adopt, which means it's abundantly clear that registration protocols -- all of them -- are non-starters at this point. P.S. I'm done on the topic of is keeping a list of forwarders a useful > solution for the group to work on. No matter how you wrap it up, it's not. > +1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Tue, Apr 14, 2015 at 3:41 PM, Terry Zink wrote: > 1. For Hotmail, every mailing list that our users are signed up for would > result in a new DNS entry. How do we manage the lifecycle around that? > Should we automate its addition? Should we automate its removal? Do we > delay email before the DNS entries are published? Should we thereby bypass > the change review process? If so, how do we audit what's going in and > what's coming out of the Hotmail zone? > > 2. For Office 365, we can't publish DNS entries for most of our customers. > We could tell them what to publish but I guarantee you almost none of them > would for every single mail list their users signed up for, if they had to > do it every day. Most of them probably wouldn't even do it once. > > That's the part that doesn't scale. +1. The mechanism of generating DNS records is not the issue; we even have an RFC that shows how that could be done in theory. It's the processes themselves that simply won't scale or would fail to thrive. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Tue, Apr 14, 2015 at 1:24 PM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > Remembering to what great lengths the ietf-dkim group went to make sure > that every bit of a message was covered by the signature (and with the l= > discussions in mind) I would really be surprised if adding the @fs= for all > outbound mail would be an acceptable solution for the problem. > I agree in general, but I'm not sure that's a valid comparison. A bare "l=0" is a lot less restricted than one that also includes "@fs=" and, perhaps, something like a short expiration. It could well be that's a tolerable risk when compared with the cost of doing nothing here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Tue, Apr 14, 2015 at 12:03 PM, Terry Zink wrote: > Getting someone to add anything to DNS doesn't work well [3] unless it is > automated because the majority of people that I work with in the customer > space don't feel comfortable managing DNS; it is rare that I encounter > someone who does and these are people who are in charge of email > infrastructure. This is the exact opposite of most people on this > discussion list, many of which manage their own zones. For many large > organizations, there is a slow change-review process. For medium and small > businesses, they just want it to work and therefore don't change much in > their DNS unless they are experts, of which there aren't that many in real > life. > Just to pile on: There are probably security people many large organizations who would be unthrilled with the notion of automating an authorization process, which is really what this is. It might feel to them a lot like an injection attack, and I would argue they're correct. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Tue, Apr 14, 2015 at 8:25 AM, Scott Kitterman wrote: > I haven't reviewed his in detail, so I've no opinion. I was talking about > this proposal. Not getting fancy with MIME parts would be nice, so if this > one can work, I already like it better than Murray's, but if we have to > pile > this onto the stack of nice ideas, then that's probably what I'll look at > next. > The elegance of John's idea is that it's content-agnostic, and is apparently backward compatible because v=1 verifiers will not consider the weak signature to be valid (unless they're already quite broken). There's no need to learn to parse MIME structure in order to produce a signature. I think the concerning part is deciding when to add the weak signature. The simplest thing is to always add it along with an "@fs=" signature, but then you're basically allowing the forwarding domain to sign any content it wants and you'll be approving it too, implicitly. If you want to be selective about when you add it, you have to apply some kind of heuristic to make that decision. We obviously can't specify that, but it becomes a burden to signers. It's also prone to replays. It might be enough to use a short expiration time, but that relies on everyone processing "x=" properly (or at all), and you need to make a good guess as to what expiration time to use. Of all the proposals before us, this would be the easiest for me to adopt and try, followed by dkim-delegate. dkim-list-canon and dkim-transform would be the hardest, not only because they will require more code, but I'm nervous about how sensitive they are to misinterpretations or abuses of MIME. For example, I've no idea what would happen to messages with MIME preambles. Still, there's something attractive about being able to tell what the original message was and what the added/modified content was, and determining who was responsible for what. Depends on who needs to change to mitigate things. If (as an example only) > we > decide that From rewriting is the best (least bad) solution, then that's a > mediator change. We don't need Yahoo and AOL except to the extent they > operate as mediators also, but AFAIK, that's different groups at Yahoo and > AOL. > I don't think we need to be worried about their participation. Unless they plan to embarrass me later for saying so, they are indeed paying attention, and will participate in trying something that seems viable. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Tue, Apr 14, 2015 at 7:56 AM, Stephen J. Turnbull wrote: > > If I misunderstood the proposal and it requires someone to be > > keeping a list of mailing lists used (either globally or by > > individual users), then I think this is not a good idea at all. I > > don't think any tracking/whitelisting design is going to succeed at > > scale. > > I can't speak for Murray, but I can't see that his proposal does. > Sorry, I've lost context. I assume you're talking about dkim-list-canon. You could apply it only when you know the mail is going to a list, maybe if you're worried about overall header size or crypto cost, but it's designed to be used generally. Since it's a signature that covers the whole message, it's not replayable (any more than basic DKIM is). Really, isn't the question whether Yahoo! and AOL are willing to do > *anything* to mitigate? We need some participation from them or it's > useless, and if at least one does participate, it's a win. What are > they willing to think about implementing? > At least one of them is subscribed, but I've no idea if they're actively monitoring. At the same time, I think the feedback we're getting from MS and Google is equally valuable, and they're active. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Fwd: WG Action: Formed Domain Boundaries (dbound)
Colleagues, The DBOUND working group has officially formed. We will be working on the question of what to do about our concerns with the Public Suffix List, which is an important component of DMARC, so it's relevant here. The chairs will be announcing to that list soon what our plan of attack is. Feel free to subscribe if interested. -MSK, one of the DBOUND chairs -- Forwarded message -- From: The IESG Date: Fri, Apr 10, 2015 at 9:26 AM Subject: WG Action: Formed Domain Boundaries (dbound) To: IETF-Announce Cc: dbound WG A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Domain Boundaries (dbound) Current Status: Proposed WG Chairs: Pete Resnick Murray Kucherawy Assigned Area Director: Barry Leiba Mailing list Address: dbo...@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dbound Archive: http://www.ietf.org/mail-archive/web/dbound Charter: Various Internet protocols and applications require some mechanism for determining whether two domain names are related. The meaning of "related" in this context is not a unitary concept. The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the types of relations relevant. For example, it is often necessary or useful to determine whether example.com and foo.example.com, or even example.net, are subject to the same administrative control. To humans, the answer to this may be obvious. However, the Domain Name System (DNS), which is the service that handles domain name queries, does not provide the ability to mark these sorts of relationships. This makes it impossible to discern relationships algorithmically. The right answer is not always "compare the rightmost two labels". Applications and organizations impose policies and procedures that create additional structure in their use of domain names. This creates many possible relationships that are not evident in the names themselves or in the operational, public representation of the names. Prior solutions for identifying relationships between domain names have sought to use the DNS namespace and protocol to extract that information when it isn't actually there. See the "Additional Background Information" section of the working group wiki for more details: https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation For the purpose of this work, "domain names" are identifiers used by organizations and services, independent of underlying protocols or mechanisms, and an "organizational domain" is defined as a name that is at the top of an administrative hierarchy, defining transition from one "outside" administrative authority to another that is "inside" the organization. The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"), and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can. Solutions will not involve the proposal of any changes to the DNS protocol. They might involve the creation of new resource record types. This working group will not seek to amend the consuming protocols themselves (standards for any web, email, or other such protocols) under this charter. If such work is desirable, it will be assigned to another appropriate working group or defined as a work item in an updated charter. Rechartering will only be considered after completion of the base work. The working group has a pre-IETF draft to consider as a possible starting point: draft-sullivan-dbound-problem-statement Milestones: TBD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Publishing and Registration Concerns
On Tue, Apr 14, 2015 at 10:12 AM, Terry Zink wrote: > But there's no way Google Apps and Microsoft's Office 365 (for example) > can publish DNS entries for all of its small, medium, and large businesses > that use its service and subscribe to mailing lists, because many times > those companies don't control the DNS for their customers. They'd (we'd) > have to get customers to update their DNS entries for every mailing list > they use if we don't have access to their DNS. Getting customers to update > their DNS is almost as pleasant as getting my teeth cleaned. > ...and remove entries when one of them stops using a mailing list. And for all we know this might happen with such scale that it begins to affect DNS caching of other useful data. > That's what we mean when we say it doesn't scale. Right. And since the largest problem is with the largest operators (because they have the biggest impact), a solution they aren't likely to adopt is probably a waste of precious working group resources. It's not "marketing" to decide to abandon a protocol that nobody will actually use. Rather, it's a highly pragmatic engineering (and working group) decision. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Apr 13, 2015 2:22 PM, "Rolf E. Sonneveld" > But, if this 'registration' does not apply to the 'mandatory tag draft', that means that every sender will always add the weak signature + 'fs=' and a replay attack is reduced to breaking the weak signature? You can't reuse the weak signature without a proper signature from the fs domain on the same message. I imagine short expiration times mitigate that risk. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Mon, Apr 13, 2015 at 12:58 AM, Stephen J. Turnbull <
turnb...@sk.tsukuba.ac.jp> wrote:
> Douglas Otis writes:
>
> > If the DMARC domain fails to step up, then a reasonable fallback
> > could require the display of the Sender header offering the needed
> > alignment.
>
> I don't understand this. We already see that most professional
> spammers exhibit From alignment on much of their traffic. Sender
> alignment is just as easy to implement, even if we could expect MUAs
> to conform to the "required display of Sender field". Users do not
> understand the Sender field as far as I can tell.
>
To the extent comprehensible, TPA is meant to allow author A to tell
receiver B that mail that has C in (for example) the List-ID field should
be treated as though it came from A. However, I concur that it means an
impostor can simply do what the TPA record says and thereby succeed; few of
the properties TPA identifies are authenticated in any way. It might be
helpful to get alignment working through paths that invalidate SPF or DKIM,
but compared to the fact that it basically advertises how to get a "pass"
in an invisible way, it's more scary to me than not. Now, if that isn't
the case, then I suggest the document falls short of explaining how this is
not an attack vector.
Also, Doug insists that this is not registration, but I don't know how he
can claim this since it requires a DNS entry for every {A, C} pair that
exists which must then be queried by every B that might receive mail from
C. Unless I'm not understanding use of the term, that's exactly how I
believe we've been using "registration" lately, and the argument on the
table is that any registration scheme is basically a non-starter for
operators for which the cardinality of AxC is or could be large.
As I've pointed out before, ATPS, DSAP, and all other earlier proposals
that required a registration step have also been non-starters. I'm not
picking on TPA here; I'm saying this entire family of solutions is probably
not the best use of our time, and I suggest there's empirical evidence to
support that claim.
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Thu, Apr 9, 2015 at 10:47 PM, Stephen J. Turnbull wrote: > TPA is still on the table for other 3rd party services (invoicing etc), > because conditional signatures do nothing for them. > I suggest that TPA or ATPS are way too complicated for third party services like invoicing, because in that case the relationship between the parties is solid enough that one could just give the other a signing key and be done with it. We can do that today. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Thu, Apr 9, 2015 at 11:25 AM, John Levine wrote: > Yeah, now that I look at your drafts again, I see that we are both > making the same assertion that this message is a mutated version of > one that someone else sent. I still like mine better because trying > to enumerate all of the possible kinds of changes doesn't work very > well, e.g., subject tags and per-recipient S/MIME encryption. (Sympa > can do the latter.) What we're claiming is slightly different. Your approach is to trust that the "fs" domain isn't malicious; mine is to claim responsibility for only the original content and allow the second domain to claim its modifications. I guess it depends on which side we want to mess with more. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: > It seems to me that this addresses the same issues that the list > mutation stuff does with a lot less complication, and without having > to enumerate all of the ways that a list might change the message. It > only assumes that the list won't change To, From, Date, or Message-ID, > which matches my list experience. The list can make arbitrary changes > to the message body, but if it does, you know who to blame. > That last sentence is basically what I said about both of my drafts, and that logic was shot down. Once you've decided you don't like the arbitrary changes, you know who to blame, but you still have to decide what you like and what you don't. > As a lazy list operator, I also like the fact that it doesn't require > lists to do anything different from what they should be doing now, > sign their outgoing mail. Senders put additional weak signatures on > mail sent to addresses that might be mailing lists, verifiers have to > upgrade to understand new signatures. Note that smelling like a > mailing list is not the same as whitelisting mailing lists. > "might be mailing lists" sounds like a place for heuristics. How would you identify an address that might be a list, or content that's likely destined for a list? The "-l" suffix isn't that common these days. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft
On Wed, Apr 8, 2015 at 7:06 PM, John Levine wrote: > I updated my conditional signature draft, which is now (thanks to a > suggestion from Ned Freed) the mandatory tag draft. > > https://tools.ietf.org/html/draft-levine-dkim-conditional-01 > > [...] > Well, I'm game to try. Adjustments to the parsing engine should be fairly simple, and a couple of extra steps to notice and resolve the forward reference will be needed. And maybe some extra return codes. I'd use "!" instead of "@", I think, as an indication of their importance when observed visually, but that's rather a minor point. The first thing that hits me: Do we have to be specific about what's meant by "weak"? How does the verifier decide if it's "weak enough" or perhaps "too weak"? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ideas for list handling
On Wed, Apr 8, 2015 at 4:18 PM, John R Levine wrote: > Yeah, I can add a giant new MIME part of arbitrary spamminess and it'll > DKIM verify. Can someone explain in detail how a verifier is supposed to > use this new hack. Consider these two messages: > > a) has a one line trailer part saying > "for more information about foo list see http://foolist.org"; > > b) has a 50 line trailer explaining that my credit card has been cancelled > and I need to click on this malware link immediately. > > Both have a valid list-whatever signature. Aren't you going to run them through your spam filter regardless, so the nasty stuff will get caught anyway? Assuming the schemes in those drafts worked, both cases have a valid list-whatever signature AND a valid author signature, AND you know the (a) or (b) added bit is solely the responsibility of the list (and, conversely, you also know where the original content starts and ends). Nobody's saying it's safe in any case, but you do know who did what, and that's more than we know today. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ideas for list handling
On Wed, Apr 8, 2015 at 11:06 AM, John R Levine wrote: > Well, that's the problem. The current spec has a well defined rule that a > verifier uses on the headers and body and the key from the DNS. Either the > signature's valid or it isn't. The recipient can certainly decide to do > whatever it wants with that bit, but it's one well defined bit. > > Unless I'm misreading these drafts, the signature now says "I took the > message, and then I deleted this part, and then I added that part" or the > like. While it's likely possible for the recipient to say, yes, that's > what you did, the recipient still has to make up its own rules about what > transformations it likes, probably including body filtering of new parts. > Are these not well-defined rules, in the same vein that canonicalizations are? That's certainly the intent here. The existing "relaxed" canonicalizations spell out a bunch of things you do to the content before you compute the hashes. That's all these do as well. It's more involved, to be sure, but in the end you're just trying to figure out if the "d=" domain took responsibility for the content. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ideas for list handling
On Wed, Apr 8, 2015 at 9:19 AM, John Levine wrote: > >Comments on either or both are welcome. > > They both have the same problem: the list says: > > Here's what I did. Whadda ya think? > > Every recipient system has to come up with its own heuristics to > decide what combinations of changes are or are not acceptable, which > means that the exact same message will be accepted by one 100% > conformant implementation and rejected by another. This does not > seem to me to be a major improvement over the current situation. > But I think that's true of every protocol we have now. For example, independent of DMARC, a valid DKIM-signed message might be rejected by "A" and not by "B" because of its content based on local policy and filtering. Local heuristics about acceptable content will always be there regardless of what we do. The goal here is not acceptance, but deterministic results from the authentication layer. Or, more generally, we need to be able to recover a validated identifer that aligns in a way that doesn't degrade the integrity of that validation. Being able to have the author signature cover the original content and the list signature cover any changes seems like a win to me. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ideas for list handling
On Mon, Apr 6, 2015 at 8:25 AM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote: > In both documents, there's a conspicuously missing item that would make > list subscribers -- and owners -- a lot happier: A mechanism for changing > the RFC5322.Subject header. Since most lists nowadays add something like > "[list-name] " immediately after "Subject: " in the originating Author's > message, they still won't pass DKIM validation even after complying > with the proposed body modification rules. Would it not be fairly > easy to add an easily reversible "change-subject" transformation to > draft-kucherawy-dkim-transform document, along with a corresponding "cs" > DKIM-Signature tag? Assuming that the mediated RFC5322.From header is > unchanged, this would make it fairly simple for the originating Author's > message to be reconstructed from the message delivered to list members. > But perhaps it might be better to put header transformations in a > separate draft. > It's conspicuously missing mainly because of the thread from last week that talks about why we avoided dealing with Subject: tagging during the original development of DKIM. However, if consensus is that this general approach is viable, then yes, it would be possible to have a second set of additional reversible mutations such as this. The difference in this case is that the list is taking responsibility for the mutations by signing the mutated form. The advantage of this method over the CDKIM or "v=2" method is that it's purely incremental to DKIM, so we don't have to touch RFC6376. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Ideas for list handling
Colleagues, I've posted a new version of draft-kucherawy-dkim-list-canon, which had expired. It was one of several we were considering a while back as a way of dealing with some indirect mail flows. https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ Also, I've posted a new one that proposes a way to include in the signature some information about message transformations that happened at a Mediator, allowing the Verifier to undo said changes and re-try the author signature. Something else to consider: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/ Comments on either or both are welcome. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM libraries, was Third Party Sender DMARC Adaptations
On Fri, Apr 3, 2015 at 7:42 PM, John Levine wrote: > In answer to someone else's question, libdkim is inded the Alt-N > library which as far as I can tell hasn't been touched since 2008. > It still seems to work OK, and it checks the v= in the signature > to be "1" or some old 0.x test versions. > Unfortunately the dkim-milter package (the predecessor to OpenDKIM) also called its library "libdkim". -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 6:25 PM, John R Levine wrote: > So receipt of a message signed in the new form will likely produce an >> incorrect signature validation, ... >> > > I wondered about that, too, so before I proposed a version bump, I took a > look at the code that people use: > > * Murray's opendkim C library: checks that the version is 0.5 or 1, fails > otherwise. That's the code in the milters that sendmail and postfix use, > and I believe it's the library that everyone else with custom C code > (including me) uses or adapts. It replaces the older libdkim. > It won't accept 0.5 unless configured to do so, and that's off by default. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 12:42 PM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > if DMARC is really the succes that dmarc.org claims it is [1] and with so > many of the big ESPs around here [2] I fail to see why it would be so > difficult to involve the MUA developers of these same ESPs? > Several of them are here. If they have better experience understanding what actually gets through to users in terms of message safety that doesn't reduce to, as John Levine put it, "Where do I click to make this warning go away?", they have yet to say so. :-) -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 11:42 AM, Murray S. Kucherawy wrote: > If the input is "the message" and the output is "a set of zero or more > SDIDs representing domains whose signatures validated", then I don't think > it matters if we go the "v=2" route or the "new header field name" route, > because the multiplexing happens on the inside of the processing machine > thus described. > As I read RFC6376 sections 3.8 and 3.9, this is a valid perspective. (I may be biased.) -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker wrote: > > The main difference I see is that if we call v2 something else, we now > > have a tedious administrative exercise of finding every place something > > refers to DKIM and change it to "DKIM or DKIM-plus." This does not > > strike me as a good use of anyone's time. > > That task you characterize as tedious is, in fact, the discipline of > making sure the documentation is careful to distinguish between the two > different (ie, non-interoperable) protocols. > > Efforts to do that with a single specification wind up confusing things > and confusing readers and implementers. I'm using API terminology here but I think the comment generalizes to the protocol: If the input is "the message" and the output is "a set of zero or more SDIDs representing domains whose signatures validated", then I don't think it matters if we go the "v=2" route or the "new header field name" route, because the multiplexing happens on the inside of the processing machine thus described. However, and perhaps unfortunately, RFC5672 changed it so that the output of DKIM is a single SDID. That means either (a) RFC5672 got it wrong, because this doesn't allow for the whole message to be the input and multiple domain names (for passing signatures) to be the output, or (b) the above definition is wrong, because it means a single DKIM signature _plus_ the whole message is the input, and the algorithm picks apart the message as needed to complete the verification and thus produce the single SDID (or an error). OpenDKIM certainly implements the first definition I've used above at its API level, though I could argue that it satisfies either of the two definitions and just happens to do the latter one in a parallel way. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Thu, Apr 2, 2015 at 6:59 AM, Anne Bennett wrote: > > As I recall this was considered during the development of DKIM > originally, > > exactly for this reason. We rejected it because we couldn't come up > with a > > safe description of what a tag should look like. If arbitrary text is > > allowed in there, then one could "tag" a spam URL at the front of a > > legitimate message's Subject field and the signature would still pass. > > Right, but if that tag were explicitly deemed to be excluded > from the signature, it could be handled differently. Hmm, but > if this resulted in (for example) the tag not being displayed, > then we would have gained nothing in the case of mailing lists. > Handled by whom? If we're talking about telling MUAs "Don't render the unsigned part of the content the same way as the signed content", then a bunch of additional complexities begin to appear: - MUAs now need to know how to do DKIM themselves, so that they know what parts were signed and what parts were not; alternatively, we need a way to signal between the DKIM verifier and the MUA what parts are safe to render, beyond what Authentication-Results already provides - We're wandering into conversations about how MUAs should interact with users, which this community typically avoids like a terrible allergy - Even if the above aren't problems, we're relying on MUAs to adapt to this change in a relatively short period of time Here be dragons. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Wed, Apr 1, 2015 at 7:24 PM, Dave Crocker wrote: > In the first case, the version field is literally useless. It is wholly > redundant or worse insufficient, given that the receiver of the protocol > data unit sees the new stuff in other ways than the version field. > > In the latter case, it's really an entirely new protocol, which should > be identified by the next-lower protocol, rather than by using the > version field as an in-bred demultiplexing field. > > And yes, IPv4 and IPv6 are distinguished by different demultiplexing > values in the Ethernet frame: > > http://en.wikipedia.org/wiki/EtherType > This argues for creating a new thing that looks almost identical to DKIM, using a new header field name, that has this one extra property. That forces demultiplexing one pseudo-layer down. I think John produced a draft about that as well. I can't get my head around the "entirely new" part of that assertion though. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Wed, Apr 1, 2015 at 6:00 PM, Michael Jack Assels < mjass...@encs.concordia.ca> wrote: > >The case of a syntactically valid multi-valued RFC5322.From field >presents a particular challenge. The process in this case is to >apply the DMARC check using each of those domains found in the >RFC5322.From field as the Author Domain and apply the most strict >policy selected among the checks that fail. > > (The word "fail" leaves me confused. Shouldn't that be "pass"?) > DMARC's "p=" describes the action to take when the evaluation mechanism fails. There is no policy to apply (other than, I suppose, an implicit "accept" action) when DMARC passes. > > At any rate, it seems to me that if DMARC would be satisfied by a Mediator > making substantial modifications to my message, changing the RFC5322.From > to > >From: "Michael Jack Assels" > > and signing appropriately, it ought to be similarly happy with > >From: "Michael Jack Assels" , > "dmarc" >Sender: "dmarc" > > signed by IETF's sending MTA. Assuming that the usual change is made to > the Subject line and the usual trailer is appended to the message body, > only the "ietf.org" identity ought to align with "the" RFC5322.From > domain, > and I can't see a reason why DMARC wouldn't be happy. Yes, someone could > have spoofed my address, but IETF's receiver will have had an opportunity > to check that, so it's either IETF's fault for accepting the original > message > or my MTA's fault for not being DMARC compliant. > > In this case, the mailing list would be doing what's asked of it by DMARC, > but keeping (most of) it's time honoured values intact. This could work, except that if this yields favorable treatment by the receiver, then that's all an attacker needs to do to get to your inbox (i.e., double up the From: using an arbitrary domain name, and make sure the message satisfies the DMARC test for the latter). The exception to that is some expression, which the receiver can confirm, that domain2 and domain1 have some kind of relationship that's interesting to this process. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Third Party Sender DMARC Adaptations
On Wed, Apr 1, 2015 at 11:11 AM, John Levine wrote: > Has anyone looked at my double signing draft? The idea is the the > original sender (which we'll call, oh, Yahoo) puts on a very weak > signature probably only on From, Date, and Message-ID, with l=0 and a > new tag that says the signature is only valid if the message is also > signed by a specific other domain, call it ietf.org. It probably also > puts on an ordinary strong signature, too, and sends the message to a > list forwarder such as dmarc@ietf.org. The list does what it does, > and signs the message normally with d=ietf.org. That breaks the > strong yahoo signature, but the weak one is now valid in combination > with the normal ietf.org signature, so there's a valid d=yahoo > signature and DMARC is happy. > > The forwarder could of course do naughty things, but only the specific > forwarder to whom the message was sent, which greatly limits the scope > of damage. It's even more limited in the common case that the original > sender has a reasonably good idea who are likely to be the well > behaved forwarders and only puts the weak signatures on mail sent to > them. > Didn't we stalemate on the question of whether this has to be a whole new header field, or a "v=" increase? I seem to recall someone (Dave?) thinking both were horrible. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
