Re: [dmarc-ietf] New version of draft-ietf-dmarc-arc-usage posted
In article , Jeremy Harris wrote: >> New version: https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-06 > >How about another subsection 5.x saying when Originating ADMDs should >take any ARC action? For starting a new ARC chain I assume the answer >is normally "don't" - but perhaps there is an exception when a message >is already DKIM-signed, or when SPF for it would be invalidated by >forwarding (despite it being in-theory a local ADMD source)? Seems to me that's pretty simple: you should add an ARC seal when you do something that might break DMARC validation, which means modifying the contents of the message (breaks DKIM) or remailing a message (breaks SPF.) It is my impression that if your message already has a local A-R header, it's a good candidate for adding an ARC seal. If not, it probably isn't even though you could in principle add your own A-R which only has arc=none. R's, John -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Request to accept a new I-D into the WG work items
In article you write: >I'd like to recommend that we (DMARC-WG) accept >https://tools.ietf.org/html/draft-kitterman-dmarc-psd-00 into our work >queue. It aligns with our charter already. OK with me. I'd like a clearer explanation of what problem it solves, but that should be fixable. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AD review of draft-ietf-dmarc-rfc7601bis-03.txt
In article <3eea2f77-8aea-4f49-80f3-d96b639c3...@isode.com> you write: > Note that in an EAI-formatted message, this identifier may be > expressed in UTF-8. > >So I decided to check whether this statement is actually true. Oops. >OLD: > >"value" is as defined in Section 5.1 of [MIME]. > >NEW: > >"value" is as defined in Section 5.1 of [MIME], with "quoted-string" >updated as specified in RFC 6532. That seems the smallest adequate fix. In general EAI allows UTF-8 in fields that humans look at, but not ones just for computers like message-IDs. The alternative would be to leave the old text and add a note that says in the common case that the identifier is a domain name, IDNs are represented as A-labels. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AD review of draft-ietf-dmarc-arc-protocol-18
In article you write: >-=-=-=-=-=- >At least 7601bis will be an RFC at the same time as this one is, if not >sooner. I don't know what the plans are for the other one. Also see Scott's LC comment on 7601bis. There's a bunch of stuff in 7601 not in the new draft, so 7601bis is really an update, not a replacement for 7601. R's, JOhn ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC Crypto Algorithm Selection
In article , Seth Blank wrote: >ARC inherits all the DKIM mechanisms by reference. So whateverâs valid for >DKIM (the list you provided) is whatâs valid for ARC. >> DKIM, as updated by the DCRUP work, has two valid crypto algorithms: >> >> rsa-sha256 >> ed25119-sha256 I would defer working on this until we clarify how algorithm switching will work. One place that ARC differs from DKIM is that many DKIM signatures are OK but you can only have one ARC seal per forward. In draft-ietf-dmarc-arc-multi-02 we say how I think it can work, but it's not quite backward compatible. R's, John -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
In article you write: >My contention to Seth is that in a multi-hop scenario, the *only* report >with meaningful data will be the one from the handler who made the "fail" >determination and any subsequent reports are untrustworthy. Assuming that "subsequent" means earlier in the chain, I agree. >Do the other folks on this thread agree that our main point of contention >has to do with the ability to generate the DMARC report (or the data >scoping thereof)? Yes. I understand what to do with "here's a valid chain" and "it was broken when I got it", but not "here's a broken chain you may or may not be able to reconstruct." R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
In article <799c2b18-97fe-6e22-f2cf-49245ae9c...@gmail.com> you write: >So the extra mechanism is intended an efficiency hack. No, it also documents the fact that the chain was broken when it arrived at the cv=fail signer. Without it, a subsequent hop can't tell. It probably won't make much difference to spam filters, but it could be useful if you're trying to find and fix forwarders that make gratuitous changes. I think there's a modest benefit to signing with cv=fail, and since you can't count on having a chain (even an invalid one) signing as if it were cv=none seems reasonable. R's, John PS: Once there is a cv=fail seal, there doesn't seem to be any point to adding any more seals in later hops. It's dead, Jim. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02
In article you write: >-=-=-=-=-=- > > To the rest of the WG: Is there consensus to make this change or the >others being proposed? Not that I've seen. I thought we agreed to make changes to support ARC, to handle EAI, and to fix any actual errors. Other than that, leave it alone. R's, John > >I feel like we're making a lot more edits here than the WG intended to >make. It's fine if the WG wants to turn this into a larger editorial pass, >but I thought the updates here were tightly scoped before, namely just >enough to allow ARC to do what it needs. > >I'm inclined to resist, absent consensus, any changes that are other than >(a) something ARC needs, or (b) something clearly incorrect. > >On Wed, Aug 1, 2018 at 5:16 AM, Alessandro Vesely wrote: > >> >> In that case, if the producer intent is not to harm or mislead, the >> trust >> >> in this field's content would be proportional to the estimated >> quality of >> >> the producer's software. Consumer's wisdom is key. >> > >> > How is a receiver to know anything about the estimated quality of the >> > producer's software? ... ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-16 and EAI messages
In article you write: >> It doesn't say that in 4.1.2, even though it's sort of implicit since >> i= means something else. I'd say so explicitly in a fifth bullet >> after where it says "three (3) differences." > >One of those differences says: > >* the presence of the “instance tag”. Additional information on the >“instance tag” can be found in Section 4.2.1. The instance tag replaces the >DKIM “AUID” tag; > >This language could probably be cleaned up to say "the 'i' (AUID) tag is >not imported from DKIM. Instead, it is replaced by the "instance tag" as >defined in Section 4.2.1" > >Then section 4.1.3 should use the identical language as well. Please do. Experience tells us that the more clearly you lay something out, the less likely we are to screw it up. I don't remember what AUID is without looking it up but i= is obvious. R's, John PS: There's still four bullets after the three (3) differences. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-16 and EAI messages
In article you write: >-=-=-=-=-=- > >I've added the following text as Section 4.1.4 (note fixed typos and >removal of the i= section, which is removed from ARC explicitly): It doesn't say that in 4.1.2, even though it's sort of implicit since i= means something else. I'd say so explicitly in a fifth bullet after where it says "three (3) differences." R's, John >4.1.4: Internationalized mail considerations > >In internationalized messages [RFC 6532] many header fields can contain >UTF-8 as well as ASCII text. The changes for Email Address >Internationalization (EAI) are all inherited from DKIM as updated by >[draft-levine-eaiauth] and Authentication-Results as updated in >[rfc7601bis], but are called out here for emphasis. > >In the AMS and AS header fields, the d= and s= tags can contain U-labels, >and in all tags, non-ASCII >characters need not be quoted in dkim-quoted-printable. > >The AAR header allows UTF-8 in the same places that A-R does, as described >in [7601bis]. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-16 and EAI messages
In article you write: >The appropriate place for this guidance is likely a second paragraph in 4.1 >(https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-4.1), >as this guidance will apply to the three following header fields. > >Would you mind suggesting a paragraph to add in this context? 4.1.4 Internationalized mail In internationalized messages (RFC 6532) many header fields can contain UTF-8 as well as ASCII text. The changes for EAI are all inherited from DKIM as updated by [draft-levine-eaiauth] and Authentication-Restukts as updated in [rfc7601bis], but are called out here for emphasis. in an AS header, the d= s= tags can be contain U-labels. In an AMS header, the d= s= tags can contain U-labels, i= can have UTF-8 in the local-part and U-labels in the domain, and in all tags, non-ASCII characters need not be quoted in dkim-quoted-printable. The AAR header allows UTF-8 in the same places that A-R does, as described in [7601bis]. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-16 and EAI messages
In article you write: >-=-=-=-=-=- > >I agree ARC should be EAI-ized. > >To be clear, are you saying that once 7601bis and draft-levine-appsarea-eaiauth >are approved by the IESG and properly update 7601 and 6376, then no direct >changes are needed to the ARC spec? > >So the only wording consideration under WGLC is the ABNF import with >respect to DKIM and draft-levine-appsarea-eaiauth? Yes, although it's probably worth reminding people where things are different in EAI messages. R's, John >On Tue, Jul 31, 2018 at 12:47 PM, John R Levine wrote: > >> I was updating my EAI-izing draft for DKIM and DMARC and realized that it >> would be nice not to have to update ARC, too. >> >> The gist of it is the same as what I said for DKIM: anywhere there's a >> domain name there can be an IDN written with U-labels (Unicode), and >> anywhere there's user text, the text can be UTF-8. >> >> The easiest thing for me would be for us to give >> draft-levine-appsarea-eaiauth a nudge so where it says ARC imports ABNF >> from RFC6376, it instead says it imports from RFC6376 as updated by >> draft-levine-appsarea-eaiauth. >> >> The concrete changes are that in the AS header, the d= s= tags can be >> IDNs, and in the AMS header, the d= s= tags can be IDNs, i= can have >> unicode local-part and IDN domain, and throughout dkim-safe-char is updated >> so that non-ASCII characters don't have to be quoted. I assume 7601bis >> will be done so AAR can inherit from there. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily
In article you write: >5.1.2 says when a chain fails, to put cv=fail in the AS and only Seal the >ARC Set being added. > >Per the original message and suggested text, I believe 5.1.2 should only >provide the above guidance when it is not otherwise possible to sign the >entire ARC Chain (i.e. when the Chain is structurally invalid and a >deterministic set of headers cannot be enumerated). I still have a question: if you have the right set of older headers, you could sign them even if they're corrupted and the signatures are invalid. But if the old sets have extra or missing headers, you can only sign your own set. I think it's fine to sign and hope for the best, but how is a validator supposed to tell the difference? Perhaps we need something like cv=restart. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC on draft-ietf-dmarc-rfc7601bis-02
In article <4878884.yiV4iTtLKX@kitterma-e6430> you write: >> In authentication service identifiers in EAI-formatted messages, a U-label >> and its equivalent A-label are considered to be the same. > >As an implementer (who's tried really hard to avoid spending cycles on EAI - >sorry), does this translate into "be prepared for UTF-8 in any A-R element >that may contain an email address or a domain"? That's partly it. IDN domain labels can be in two different forms, a UTF-8 U-label or an xn--punycode A-label. It would be a good idea to treat them as equivalent. There are translation libraries, and it's easy to recognize U-labels by checking for the 0x80 bit so this is not a lot of code. Having been writing MTA patches to handle EAI better last week, I say this from experience. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken
In article you write: >-=-=-=-=-=- > >On Fri, Jul 27, 2018 at 10:41 AM, Scott Kitterman >wrote: > >> And if you don't want to make a new one, 5.7.26 (Multiple authentication >> checks failed) seems at least not wrong. To get to this point DKIM, >> DMARC, >> and ARC have failed. > >Is this better moved into Experimental Considerations? > >We could put simple text around if an error code is appropriate or not, and >if so if a new one is needed. Just add the error code. It's really not a big deal. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-16 signature domains
In article you write: >-=-=-=-=-=- > >On Fri, Jul 27, 2018 at 11:15 AM, John R Levine wrote: >> >> I'd say that all signatures in a seal SHOULD have the same domain, to make >> them easier to evaluate. >> > >So the Usage Guide will (does?) say that. Earlier consensus was to keep >that out of the normative document because a) it doesn't affect >interoperability, b) it would be yet another requirement in an already >complex standard, and c) there are reasons this flexibility could be >valuable. OK, that makes sense. It is an experiment, after all. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] ARC-16 signature domains
The ARC draft clearly says that every ARC header can be signed by whatever domain you want. I understand what that means technically, but I don't understand the semantics of an ARC set where the AMS and AS are signed by different domains. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] abnf bug in arc-protocol, was Comments on certain drafts
In article <5b55a0f8.1c69fb81.123a9.5...@mx.google.com> you write: >-=-=-=-=-=- > >draft-ietf-dmarc-arc-protocol > >The production “arc-info” includes a semicolon after “instance”, which in turn >has a semicolon at the >end. However, a great number of Arc-Authentication-Results header fields I’ve >seen in practice include only >one semicolon between the instance and the “authres-payload”; for example: >“i=1; mx.example.com; …”. > >draft-ietf-dmarc-rfc7601bis You're right, that's a bug in the ABNF. The definition of instance in section 3.6 shouldn't have a semicolon because both places it's used, arc-info and arc-as-info, put a semicolon after it. I suppose we could take the semicolon out of arc-info and arc-as-info instead. >I also want to report on another form of the Authentication-Results field that >I've seen in practice. It has the form: > > authserv from=domain; method=result (comment); from=domain; method=result > (comment) > >where "authserv" (from what I've seen) is a domain name that always ends in >"yahoo.com". Yeah, Yahoo implemented it wrong. I'll remind them when I see them at M3AAWG. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC protocol-15 posted
In article you write: >> 9.2 describes the problem, but it's expressed in terms of a DoS attack on >> (primarily) validators. The DNS folk will be more concerned with the >> overall load on the infrastructure caused by ARC, not specifically on >> attack scenarios. So in consulting the DNS directorate, it would be good to >> mention the operational impact of 9.2. >> >> I also wonder if it would be helpful to mitigate the operational impact by >> saying that AS SHOULD use the same selector as the associated AMS. > >I would be opposed to adding the suggestion of this sort of restriction on >the basis of hypothetical load impacts. I agree with Kurt here. I would be astonished if the extra load of ARC lookups were even noticable other than in contrived scenarios. In typical mail systems, every incoming message provokes a blizzard of DNS lookups in DNSBLs for IP addresses and envelope domains, SPF, DKIM keys, checking whether envelope and header address domains exist, and DNSBL lookups up of every domain name in message bodies. ARC is a very slim straw on the back of this particular camel. I do weird DKIM signatures where every signature has a different selector, often with several signatures per message, and the DNS load is still trivial. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC protocol-15 posted
In article you write: >Given that we've settled on Experimental status, I propose this gets tabled >until that's published. The experiment will establish what benefit ARC can >provide, which I think is the most important output of this work. The >change being suggested here appears to be one of efficiency, not something >that will assist with evaluating that benefit. Having written and deployed a bunch of ARC code, I do not believe that any sort of twiddle to try to combine one of the ARC headers with a DKIM signature would be productive, and I have no interest in going down that road. As I said in a previous message, the bloat wars are over and bloat won. Nobody cares any more about avoiding a few hundred bytes of message header. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC protocol-15 posted
In article you write: >-=-=-=-=-=- > >On 7/11/18 5:15 PM, Brandon Long wrote: >So essentially we're creating a bunch of header bloat (creating >duplicate header fields with different names where that could be >avoided) because there are some MTAs that did not follow the >specifications before. Not really. Removing A-R headers and DKIM signatures that you know you've broken is perfectly legit. >While that was ~14 years ago and storage is >cheaper now, we're talking about a lot more space than just a public key. The header bloat war was over years ago, and bloat won. See the headers below from a Hotmail message I just sent to myself. And remember that most messages have two copies of the contents, one as text and one as overformatted HTML. R's, John Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254069.outbound.protection.outlook.com [40.92.254.69]) by mail1.iecc.com ([64.57.183.56]) with ESMTPS (TLS1.2/X.509/SHA384) via TCP port 4832/25 id 593422434; 12 Jul 2018 01:33:45 - DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yheKLMok/AWsFgQSOudb3SeVpVLTechgX2xwJg55q1I=; b=fSMMmynOZ/yvG4APRjHNPV6dEp5BL4cqFrWDuhwGP1TrOFjBAKfK90feS2C0m8fYLSCpxLT5kVicGIRKU4/m8mnkhAddsiYJyH1YndV++hcuWdYczcC+J4BTOjyGoI6nHG0huyk4JNCdDbUDkOrBJVtnzBuUV7bul1/HiRpByRmwjJEblpDmwL39unVb5BsraL4LI4tFpVg7SoSN8JknQkQhEehEy4y/KKrjf0BWfTevXijH/SUIuhfTtvivBNYk3nttmGb/UzZnppsg0K60B1Spzkt5a+MDVfb0WcxOW96pbW+JZBDUQL2DJzYEeMO2XwU0KzvI2VeTo+FFbsaJfg== Received: from PU1APC01FT054.eop-APC01.prod.protection.outlook.com (10.152.252.53) by PU1APC01HT025.eop-APC01.prod.protection.outlook.com (10.152.253.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.952.17; Thu, 12 Jul 2018 01:33:40 + Received: from MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM (10.152.252.58) by PU1APC01FT054.mail.protection.outlook.com (10.152.253.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.952.17 via Frontend Transport; Thu, 12 Jul 2018 01:33:40 + Received: from MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM ([fe80::80d8:30b7:8b9:76b8]) by MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM ([fe80::80d8:30b7:8b9:76b8%6]) with mapi id 15.20.0952.017; Thu, 12 Jul 2018 01:33:40 + From: John Levine To: "jo...@taugh.com" Subject: foonly Thread-Topic: foonly Thread-Index: AQHUGYBbeUQDz4tOwk+dGC+Hc9JmZA== Date: Thu, 12 Jul 2018 01:33:40 + Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A7C19D09C7AEA4F3F77D7470D7304AD8D473C0A6D230F3D30521AB146ABFE106;UpperCasedChecksum:396480D49DF29DCCCFBA5A280F6FA9AC7D936435C538895B009E6EE3C82D4242;SizeAsReceived:6935;Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [EXz7oC/i7RDIxsz0et96krw+RIvK/ZpBSSdECXooGiWEUcOlu9MA/OlkbCP8PsXYKWXUaXqoDgk=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;PU1APC01HT025;7:MrJzcL3Ttgoo5VtNuOX58QnjyQ9+Dos0iMozs6RfU6mvKY6vaW/B9Ta309AzLchfmM/OI+ejlE8BZ63HPBTs1d7sj4m7AXNELVE0UWzMtt5pOfCHXuTDuaQXyu+0caU6ZayNj66ow1OOqvmegxS5mykVWw9cO0GXW90Wpk6olG3kSxqjOJ5MUPeznySFTRBi7zx8SVTbvJCwvmEWFvbawwc29O1FjyBBePky3s56CRq2eQqu9Iw314XajfL253HU x-incomingheadercount: 44 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045);SRVR:PU1APC01HT025; x-ms-traffictypediagnostic: PU1APC01HT025: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(82015058);SRVR:PU1APC01HT025;BCL:0;PCL:0;RULEID:;SRVR:PU1APC01HT025; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM;SFS:(7070007)(199004)(189003)(8676002)(2351001)(104016004)(102836004)(173073)(7696005)(81156014)(8936002)(105586002)(68736007)(4508042)(588024002)(74316002)(97736004)(14454004)(290011)(25786009)(33656002)(427066)(606006)(6916009)(525012)(7116003)(348074)(566031)(106356001)(2501003)(7066003)(105004)(558084003)(426003)(6306002)(54896002)(53376002)(99286004)(55016002)(476003)(2046051)(256004)(236005)(82202002)(1748072)(53366004)(87572001)(46003)(6436002)(86362001)(19627405001)(486006)(564073)(221733001)(6346003)(135393001)(217283001)(220243001)(42262002)(10090945008);DIR:OUT;SFP:1901;SCL:1;SRVR:PU1APC01HT025;H:MA1PR01MB0504.INDPRD01.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:; received-spf: None (protection.outlook.com: outlook.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=xn--ls...@outlook.com; x-microsoft-antispam-message-info: 1hB2K4YT2O0kPIKFQFuK5MkKMpbq//Nz/nLHv3mR53oy
Re: [dmarc-ietf] Any outstanding issues on 7601bis?
In article <2940516.WEBi8fTYBz@kitterma-e6430> you write: >Is the list of EAI affected components of the field complete? As an example, >sometimes email addresses are used for SMTP Auth user IDs (or sometimes just >the local part). I don't know a lot about EAI, but it seems to me that most >any field might have to contain UTF-8 now? Any field that is a domain name or an e-mail address can be UTF-8 in an EAI message. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC protocol-15 posted
In article you write: >> Anything that comes close to 'do whatever you want with this >> information' demonstrates NON-standardization. Not at all. The point of a standard is to say here is what you do if you want to interoperate. Trying to figure out how to recover when someone else doesn't follow the spec is a fool's errand, since there are more ways to misimplement a spec than any of us can imagine. I suppose we could put in a sentence or two reminding people that unlike DKIM, the list of tags in the spec are the only ones allowed in an ARC header, so don't try to invent new ones. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Too bad that the EFAIL victims never heard of DKIM/DMARC
In article <66d513ca-f33d-748b-e394-bceb6e1da...@spamtrap.tnetconsulting.net> you write: >-=-=-=-=-=- > >On 05/15/2018 08:15 AM, Kurt Andersen wrote: >> Manipulating MIME structures in email messages to expose the encrypted >> content: https://efail.de/ > >DKIM will not help protect against #Efail. > >Efail works by copying ciphertext into a new message and arranging for >the client to decrypt it. Said new message is devoid of any association >with DKIM. I suppose, for the 10 seconds from the time the message is created until the attacker's MTA signs it on the way out. The bad guy can put a return address he controls on the malicious message and make the whole thing DMARC compliant. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] inheritance and public suffix list
In article <91efb193-9a81-4626-92ca-bf116826f...@uniregistry.link> you write: >Contractual changes. Not really. This is the relevant text from >https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html But the paragraph at the end of that section, Exhibit A, says: If Registry Operator wishes to place any DNS resource record type or class into its TLD DNS service (other than those listed in Sections 1.1 or 1.2 above), it must describe in detail its proposal and submit a Registry Services Evaluation Process (RSEP) request. This will be evaluated per RSEP to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS. Registry Operator recognizes and acknowledges that a service based on the use of less-common DNS resource records and/or classes in the TLD zone, even if approved, might not work as intended for all users due to lack of software support. Registries make RSEP requests all the time. They're tedious and fairly expensive, but the process is straightforward. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] inheritance and public suffix list
In article you write: >> I think _dmarc as a TXT record is fairly well known. Is there anything >> that would specifically prohibit this? > >gTLDs are not permitted to place TXT records in their zones. That's mostly right. There is detailed language in the registry contracts about what's allowed in the TLD zones, dating back to the sitefinder fiasco when Verisign put a *.com wildcard in the .com zone. See Exhibit A in the Base Registry Agreement: https://www.icann.org/resources/pages/registries/registries-agreements-en TLDs are allowed to put in txt records for zone status. See, for example, the TXT records at __zone_status.sharp or at total. I doubt that anyone would object to a _dmarc. TXT record, but it's debatable whether it would qualify as zone status. Otherwise the registry would have to make an RSEP request to ICANN for permission to do so, which is expensive and slow. https://www.icann.org/resources/pages/rsep-2014-02-19-en R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-01.txt
In article you write: >This includes a registration for "header.a" and John's changes to support >EAI. However, Barry has some concerns with how "local-part" is not left in >a good state by these changes. Those of you in the WG with clue about EAI, >please help me sort this out, since I do not fall into that category. That would probably be me, but I don't know what the local-part problem is. My intention was to import the local-part changes from the EAI RFC. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-00.txt
In article you write: >Et voila. If you go to the "History" tab and request a diff from the >individual -00 to the working group -00, you can see all of the changes >made relative to RFC7601. Basically it loosens up the language about what >categories of things can be recorded, makes the ABNF changes requested, and >guts some stuff copied from RFC7601 that doesn't need to be there for this >version because it describes registry changes that were already made by >that RFC. > >Let me know if I missed anything. Seems fine, although I've long found 7601 one of the most mysterious RFCs ever published. The IANA registry says that there is a dkim header.i property defined in RFC7601, but the only place it appears in 7601 is in examples in Appendix B. Section 2.4 says that a "policy" property is how you report a local policy that overrides the regular result, but I see policy=reject in reports about DMARC where it's just copying the p= from the _dmarc record. Is that right? If not, where if anywhere should it be reported? Can we add DKIM header.a here, please? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-WG F2F @ IETF101
The WG chairs do it online, start here: https://datatracker.ietf.org/accounts/login/?next=/secr/sreq/ R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt
In article <01qo3ttohmle000...@mauve.mrochek.com> you write: >This would need to be coordinated with the EAI people/list, but as long >as it isn't controversial I don't see a reason not to put it in. It's not supposed to be controversial, the minimum changes to make stuff work with EAI UTF-8 messages. R's, John >> If I may budge in here, any chance we could put in a few tweaks for >> EAI mail? > >> I think the main changes would be that if the A-R or AAR header is in >> an EAI message, domain names and local parts can be UTF-8 rather than >> ASCII. I specifically do not want to change any of the keywords or >> codes, since they're for software, not for people. > >> I realize that we should update RFC 6376 at the same time for DKIM >> signatures, but I'll take what I can get. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt
If I may budge in here, any chance we could put in a few tweaks for EAI mail? I think the main changes would be that if the A-R or AAR header is in an EAI message, domain names and local parts can be UTF-8 rather than ASCII. I specifically do not want to change any of the keywords or codes, since they're for software, not for people. I realize that we should update RFC 6376 at the same time for DKIM signatures, but I'll take what I can get. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Clarifying the value of arc.closest-fail
In article <1514939995.3318165.1222346488.5b169...@webmail.messagingengine.com> you write: >Please read my examples again if the problem wasn't clear, because you >don't get security by imagining the best cases where everyone behaves >themselves, you get security by imagining that everybody is trying to >get away with the worst abuses they can without being detected. Seems to me this makes some assumptions about the way ARC consumers will use ARC chains to decide whether to ignore a DMARC failure. Personally, I think the most likely scenario is that they'll look at all of the signers to see if they all are reasonably trustworthy, and if so, look at the i=1 seal to see if the message would have passed before being munged, and if so allow it. This requires having a giant reputation database for every ARC signer, but that's not much of a stretch beyond the reputation database you need to decide whether to look at the ARC chain at all. Trying to guess who changed something and whether they were malicious seems unlikely to work. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5.2.1, header.ds considered confusing
In article you write: >header.s is NOT defined: https://www.iana.org/assignments/email-auth/email- >auth.xhtml Quite right, need to put it in the IANA considerations of something. FWIW, I added header.s to my SMTP daemon this afternoon. It took about 10 minuutes. I'm a pretty good programmer, but I'm not *that* good. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft-10 Section 10 - Algorithm Rotation - can we address separately?
In article you write: >https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-10) >feels clunky and itself says it needs more work. To put it mildly. >Assuming we're proceeding as an Experiment, I propose we address rotation >in a separate draft. I understand the motivation, but I think that if we do that, it makes it a lot less likely that people will actually implement the rotation stuff. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted
In article you write: >"Experimental" is perfectly fine. As I understand it, EAI did that first >and went to the standards track after it had some field use. That is true, but it's also true that the standards track version of EAI is fairly different from the experimental version, mostly by leaving out a feature that didn't work in the field (downgrading.) ARC is complex enough that I think it's likely that once we have experience with ARC 1.0, we'll find that the stanards track ARC 2.0 is somewhat different. Perhaps we should think about how to prepare for that, e.g., the dread version number field. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted
In article <13429029.WxFjRkil8E@kitterma-e6430> you write: >> Stall ARC for a few more months until we can get ed25519 into the >> libraries, then adjust the document to make it MUST verify both. > >I doubt you'll see it in OpenARC until after OpenSSL has a release that >supports ed25519. That may be a large value of few. Does anyone know? Rich Salz says it's supposed to be in the next release. The ed25519 code has been in the github source for several months. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted
In article <1513857489.3531319.1212273208.18fe8...@webmail.messagingengine.com> you write: >I certainly concur with Brandon here - changing ARC algorithm looks like >a very messy proposition, I expect you'd pretty much have to do a window >where both the old and new algorithm were supported - with a dealine >where the old algorithm gets treated like a broken link. ... Complex technical approach: Invent a new ps= tag for peer selector. If using two signing algorithms, add two AS and AMS headers with the same d= but different s=, one for each algorithm, each with a ps= pointing to the other header, and each signature covering both headers, and you have to check when signing and validating that the ps= in this header matches the s= in the other. The chain is valid if either AS is valid. Simple administrative approach: Stall ARC for a few more months until we can get ed25519 into the libraries, then adjust the document to make it MUST verify both. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Duplicate DMARC records and tags?
In article <20171219183616.ga6...@marwnad.com> you write: >Section 6.6.3, Policy Discovery. > >"If the remaining set contains multiple records or no records, >policy discovery terminates and DMARC processing is not applied >to this message." Oh, look at that. Thanks. >> For that matter, what if anything does this mean? >> >> _dmarc.example.com IN TXT "v=DMARC1; p=none; p=reject" > >> In 7489 it says "DMARC records follow the extensible "tag-value" >> syntax for DNS-based key records defined in DKIM [DKIM]." I hope that >> means they follow the DKIM rule that duplicate tags make the whole >> record invalid, but that could be clearer. > >The definition of tag-value syntax in [DKIM] section 3.2 says "Tags >with duplicate names MUST NOT occur within a single tag-list; if a tag >name does occur more than once, the entire tag-list is invalid." This >language could be repeated in the DMARC specification, but I don't see >any real reason to do so. > >There's also a formal ABNF definition in 7489 section 6.4 which shows >that duplicate tags aren't allowed. I see that, but unfortunately the DMARC ABNF doesn't match the prose. Section 6.3 says that unknown tags are ignored, but the ABNF syntax doesn't allow them. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Duplicate DMARC records and tags?
>> Dunno if this ever came up before. What, if anything, does this mean? >> >> _dmarc.example.com IN TXT "v=DMARC1; p=none" >> _dmarc.example.com IN TXT "v=DMARC1; p=reject" > >https://tools.ietf.org/html/rfc7489#section-6.1 say >.. MUST concatenate these strings ... Nope, that's talking about strings in a single TXT record. These are separate TXT records. >> For that matter, what if anything does this mean? >> >> _dmarc.example.com IN TXT "v=DMARC1; p=none; p=reject" >I would expect this to be valid but the result depend on the implemented parser >thus is not predictable. Could be p=none OR p=reject I would prefer it's not valid. If you can't figure out how to tell me what your policy (or whatever is) I don't see why I should waste time guessing. It would also make the parsing rules compatible with DKIM. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains
> We can’t just >use a wildcard CNAME record because there doesn’t seem to be any way to >generate the necessary second level subdomain that we >need (the _dmarc.baddomain.gov.uk). As you surmise, that won't work. For one thing _dmarc.*.gov.uk isn't a wildcard, and for another, *.gov.uk only matches names that don't already exist and don't have an existing parent. So if, for example, mod.gov.uk exists, *.mod.gov.uk won't match. This is not considered to be a bug. > DNAME would be the most obvious way to do this, but it’d need a wildcard > DNAME and they’re >‘frowned upon’ ☺. Indeed they are, because they don't work either. You cannot have any DNS records or any NS delegations below a DNAME. In practice DNAMEs are not very useful. > Before we start thinking about doing something kludgy (probably looking for > failed lookups for TXT records >in logs and adding the subdomain to the zone, which sucks), does anyone have >any ideas that we could try? I can’t believe this is >the first time this has been encountered! Honestly, you need to figure out how to get the attention of of the people to whom you have delegated subdomains and have them fix their DNS. I realize this is not easy. I have often surmised that rather than delegating subdomain zones, you're much better off one big zone with a provisioning system that lets people mess with the records in their subtree. Then it's still your provisioning system so if they get things wrong, or you want to help them set up records like SPF or DMARC that they haven't gotten around do doing themselves, you can just do it. R's, John -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Duplicate DMARC records and tags?
Dunno if this ever came up before. What, if anything, does this mean? _dmarc.example.com IN TXT "v=DMARC1; p=none" _dmarc.example.com IN TXT "v=DMARC1; p=reject" Looking through RFC 7489 I don't see anywhere that it says that more than one record is forbidden. For that matter, what if anything does this mean? _dmarc.example.com IN TXT "v=DMARC1; p=none; p=reject" In 7489 it says "DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM]." I hope that means they follow the DKIM rule that duplicate tags make the whole record invalid, but that could be clearer. R's, John PS: This came up when I was reading a guy's code where he carefully looks at multiple records and somehow decides which one to believe. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Preventing abuse of public-suffix-level domains
In article <16060f3af18.2772.9bc7627f4bf0daf95da66808f3dcb...@crankycanuck.ca> you write: >But if course, it isn't necessarily the domain admin who puts things in the >PSL, which has always been one of the problems with the PSL. It was why we >set up the dbound WG. Pity we couldn't get that to consensus. I take your point, but in this case the entries come from the registry, which somehow has simultaneously insisted that all names be registered below SLDs, and provided A and MX for some SLDs. https://www.zadna.org.za/content/page/domain-information/ R's, John >> In article >> you >> write: >>>I've heard from one of my contacts that country-level TLDs like gov.za are >>>being used for attacks and that there is not a particularly effective way >>>to protect against that or to protect against non-existent subdomains being >>>abused. (It's even worse if those public suffix level domains are being >>>used to send mail, but if they aren't, how do you protect it?) >> >> I was about to say that surely nobody would be foolish enough to put a >> name in the PSL that has live MX records and used for mail. Silly me. >> >> The obvious response is that if they can publish A and MX and SPF >> records for gov.za, which they do, they can publish DMARC, too. It >> also suggests that putting gov.za in the PSL was not a very good idea. >> >> R's, >> John >> >> >> >> >> freight.aero: 10 mx1.champ.aero. >> freight.aero: 10 mx3.champ.aero. >> freight.aero: 10 mx2.champ.aero. >> freight.aero: 10 mx4.champ.aero. ... >> ac.za: 10 protea.tenet.ac.za. >> agric.za: 10 gwsmtp1.agric.za. >> alt.za: 0 ln1.cequrux.com. >> co.za: 10 mx2.coza.net.za. >> gov.za: 100 mta.gov.za. >> grondar.za: 0 gromit.grondar.org. >> law.za: 20 luke.voffice.co.za. >> law.za: 30 mail.attorneys.law.za. >> law.za: 10 mailfirewall.voffice.co.za. >> mil.za: 10 fm-mail-in.voxtelecom.co.za. >> ngo.za: 10 mxc01.mxrc.co.za. >> ngo.za: 10 mxc02.mxrc.co.za. >> nis.za: 0 nis.za. >> nom.za: 20 secdns1.posix.co.za. >> nom.za: 10 mail.nom.za. >> org.za: 10 mx2.coza.net.za. >> school.za: 10 ochre.school.za. >> school.za: 20 mopani.school.za. >> tm.za: 20 alt1.aspmx.l.google.com. >> tm.za: 20 alt2.aspmx.l.google.com. >> tm.za: 30 aspmx2.googlemail.com. >> tm.za: 30 aspmx3.googlemail.com. >> tm.za: 30 aspmx4.googlemail.com. >> tm.za: 30 aspmx5.googlemail.com. >> tm.za: 10 aspmx.l.google.com. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] SHA1 and short keys, threat or menace
I am working on yet another ARC library and am wondering what to do about SHA1 signatures and 512 bit keys. The DCRUP working group has sent a DKIM update to the RFC editor which finally kills SHA1 hashes and RSA keys shorter than 1024 bits. It's in the queue and will be published when they get around to it, probably next month. On the assumption that ARC signatures track DKIM, what should I do? At the moment I have a "strict" option in the verifier which when set rejects SHA1 hashes and short keys. I suppose it should be on by default, but a couple of the tests in the YANG test suite have SHA1 signatures. There's also a test that 512 bit signatures are rejected, so depending on the setting currently I can either fail the SHA1 signatures or I can fail the short key signature. Suggestions? Signed, Uncertain PS: Coming soon to DKIM, ed25519 signatures, but since the underlying library code isn't in OpenSSL yet, I'm not yet worrying about it. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Lenient SPF
In article <5fca5469-8673-9555-8e47-e2251632f...@tnetconsulting.net> you write: >-=-=-=-=-=- > >On 10/13/2017 10:54 AM, John Levine wrote: >> SRS is one of those magic bullets that might have worked if everyone >> in the world implemented it at the same time, and the design were >> written by someone who understood the security issues. > >Would you please elaborate on (or point me to existing documentation) on >the security issues that you're referring to? See the paragraph about forged domains and whitelists in the original message. >> So if you have to be prepared to ignore overenthusiastic SPF >> -all anyway, who needs SRS? > >Maybe it's just me, but I've never felt the desire to ignore >overenthusiastic SPF. It's just you. I talk to people who run large mail systems, and without exception they tell me that they do not reject on spf -all other perhaps a plain -all which means someone sends no mail at all.. The false positive rate would just be too high. >I feel that if a sending domain sets "-all" they (hypothetically) know >what they are doing ... Wow, you're the optimist. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Lenient SPF
In article <6a14ffbc-d704-b168-c5f4-6b971d48d...@tnetconsulting.net> you write: >On 10/08/2017 08:29 PM, John Levine wrote: >> * There is a kludge called SRS that embeds the original bounce address >> in the forwarder's bounce address, but it doesn't help. > >Where can I find out more about how / why SRS does not help. SRS is one of those magic bullets that might have worked if everyone in the world implemented it at the same time, and the design were written by someone who understood the security issues. In the real world, any change to e-mail is implemented gradually, so you have to be prepared for the old way and new way to work in parallel for a long time. So if you have to be prepared to ignore overenthusiastic SPF -all anyway, who needs SRS? There's no technical way to tell an incoming message with a real rewritten SRS address from one with a fake SRS address intended to make spam look less spammy, other than by checking against a whitelist of known virtuous forwarders. But if you have that whitelist, you don't need SRS, you just skip the SPF check on mail from those forwarders. (Gmail approximately does that.) The other problem that SRS is supposed to fix, forwarding back bounce messages, barely exists any more. Due to the floods of spam with forged return addresses, bounce messages are now mostly reflected spam going back to someone who didn't send the message in the first place. MTAs (other than those written in Redmond WA) try hard to reject undeliverable mail during the initial SMTP session rather than accept and bounce. The comment about some rule against changing bounce addresses is wrong. Every mailing list rewrites the bounce address on mail it forwards. That makes sense for lists, since they need to handle subscriber bounces, not the person who originally sent the message. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Lenient SPF
In article <59da9de9.4000...@openfortress.nl> you write: >Forwarding is an action on the receiving end, and can only be solved >reliably by the recipient. Notably, a mailbox user could specify >addresses that are forwarded to their mailbox. Mailing list >subscriptions may be seen as a special form of forwarding. Sorry but this is another WKBI. Off the top of my head some of the reasons it doesn't work are: * There is no way to tell who forwarded a message, in particular you cannot expect the recipient to be in a To: or Cc: header. You could invent a Forwarded-By: header, but of course bad guys add fake headers, so you'd have to track who's supposed to be forwarding what and you'd end up with a very complex and fragile forwarder whitelist. * There is a kludge called SRS that embeds the original bounce address in the forwarder's bounce address, but it doesn't help. * Mailing lists invariably replace the incoming bounce address with their own bounce address so they can handle the bounces, which among other things means there you can't tell that a mailing list message is a mutated forwarded message from whoever originally sent it. Skipping ahead, you might at best end up with a very complex and fragile mailing list whitelist. * Asking users to manage their own security settings doesn't work. See prior discussion of MUA highlighting and browser warnings. R's, John PS: Most courtesy forwards don't break DKIM signatures. That's not an accident. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)
In article <59c8d406.7000...@openfortress.nl> you write: >I am looking forward to your responses. Please keep me in Cc: if possible? I hate to be totally negative, but this draft revives a lot of things that we considered and rejected when we did DKIM. Marking content in an MUA is a WKBI*. There is no reason to believe that users would understand content marking or would make reasonable decisions based on it. As a general rule, anything that puts security policy in the hands of end users doesn't work. Think of all the browser bad SSL cert warnings you've clicked through. Also, there are more ways to change content that anyone can describe. Some of the harder to describe are recoding between 7 and 8 bit and base64, reducing the size and resolution of images (common on phones) and reordering MIME parts. Finally, it is pretty clear from the ARC work that big mail systems are more interested in telling recipient systems the identities of the parties that handled a message than how it changed or whether any of those parties thought the changes were a good idea. For another rejected approach see my DKIM conditional signatures, which let senders authorize intermediaries to modify and resign messages. https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ R's, John * - Well Known Bad Idea ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] About "non-rewindable crypto"
In article you write: >Do we think there's any utility to adding more message info to the AS, such >as message-id? Probably not. Mailing lists sometimes change the message ID, so it's not a very useful indication of evil. Having watched this thread, I don't see what the issue is. If a bad guy rewinds and resends a message, it'll arrive from the bad guy, not from wherever it was supposed to come from. I think we agree that ARC is only useful on messages that come from normally trustworthy sources, which the bad guy would not be. So what problem are we solving here? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC-Seal is meaningless security theatre
In article <1502083287.2191248.1065195288.7cdc7...@webmail.messagingengine.com> you write: >I thought long and hard about using a less inflammatory title, but I >figure maybe going in hard is the right way here, because I'd rather >fix this before it becomes a standard! (and thanks Dave for your >thoughtful questions during the Prague DMARC session which prompted >some of my thinking) For the most part you're right, but there seem to be a few corner cases that make it worthwhile. Since it only makes sense to look at the ARC chain on mail that comes from senders that are generally reliable, I've asked why you don't just whitelist those senders and be done with it. The answer, at least at very large mail systems, is that a mailing list sends nice clean mail, but then it starts forwarding lots of spam. I've seen this on some of the ICANN lists where someone got his address book stolen that had both the lists and individuals' addresses, so we're now getting mail through the lists with faked addresses of a frequent participant. ARC passes along info from previous hops so the recipient can retroactively do filtering that the mailing list didn't. I personally don't expect to do that, but if Gmail says they will, I presume they will. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question for Thursday's meeting consideration: extending DMARC DNS record to cover ARC
In article you write: >ARC is an underlying authentication mechanism that calls for a new >assessment mechanism, since the role of the authenticated entity is >different than the entities currently being assessed by filtering >engines -- intermediary rather than originator. Well, yes, but for ARC you need a bottom turtle that tells you whether to mix the advice from the ARC chain into your message assessment. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC RFC status to target
In article , Murray S. Kucherawy wrote: >I think at the time DKIM went to Proposed Standard, one could've made the >same argument about it as well, especially on your last two points. Sorta kinda. At that point there wasn't any question that people would use it to tie messages to domain names, since domainkeys already did that. We still have no consensus on what you do with the domains once you have them. With ARC, I expect it'll be pretty clear whether stuff forwarded through mailing lists and the like is getting through. >I also think there's enough in flux about the current base document for ARC >that I would argue pretty hard for Experimental if we were pressed to >publish sooner. It doesn't feel "done" to me. Agreed. I expect that after a six months or a year we'll have a lot better idea whether ARC is fixing the mailing list issues and what tweaks might help. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Next version of the draft was delayed due to TSA
In article <6a1c679b-d5e0-2e4d-fe5f-b3a4c9db4...@gmail.com> you write: >Today it's about being able to edit documents on the smallest device. Naah, it's routing around damage, except that now it's flight routing rather than packet routing. I live in the US but I usually fly out of Toronto which is seeming more and more like a good idea. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Valimail and DMARC
In article <1496485938.3555.19.ca...@wemonitoremail.com> you write: >MailMan has supported DMARC domains for ages through a simple address re- >writing mechanism. It works quite well. The version running this list >(2.1.22) definitely supports it, it just needs to be enabled. The IETF has a long-running discussion about how to deal with DMARC and is looking at some options. Putting the list's address on the From: line is not one of the options. It would be utterly unproductive to reargue this topic here, so please don't. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?
In article <8f87f9de-c87e-406e-ba49-6aea5dc17...@kitterman.com>, >Nothing other than potentially ARC requires multiple AR header fields for >different authentication types to be combined. These different >verification operations (e.g. SPF, DKIM, and DMARC) are generally performed be >different processes that add their own AR field. Since DMARC needs the results of SPF and DKIM, how does that work? Does DMARC look at the A-R that the other two created or is there a side channel? It occurs to me that a DMARC process has everything needed to make a header that combines all three. >It probably makes sense to stick the sender with the complexity of dealing >with multiple AR fields and combining then, but let's not pretend there's an >overall simplification here. In ARC, definitely. My setup already does a combined header, since I wrote one plugin that calls all three libraries. On my setup (mailfront) it was a lot easier than doing it separately. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?
In article you write: >Looking at random messages on this list, I've seen anywhere from two to >five AR headers per message. Locally, with opendkim and opendmarc running, >there are three locally generated AR headers that get passed to openarc. It >looks like seeing multiple AR headers is going to be a common occurrence >for ARC implementations to handle. When I take a look, I only see one, from ietfa.amsl.com. If I were having the list mailed to me, I'd expect to see two, that one plus the one my system adds. It is rather peculiar to have multiple headers with the same service identifier, since section 5 of RFC 7601 says that you normally delete exsting A-R headers with the same authserv-id before you add a new one. On my system, the SMTP daemon calls the spf2, opendkim, and opendmarc libraries, and then puts all the results in a single A-R header. For example, when I look at mail from a list I forward to a gmail account, I see one A-R header from mx.google.com, one from my system, and maybe one from the original system. I think that's more typical. >Is this a problem the group thinks needs discussion? Only if there are a lot of MTAs that don't report their results in one header. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
In article <363edd8b-2654-4d81-ad41-d355599d3...@att.com> you write: >-=-=-=-=-=- >Right now we require support for two types of keys: a weak one (sha1) and a >strong one (sha256). True, but it's important to note that we don't require anyone to sign with weak keys. A key record in the DNS can contain "h=sha256" to say no SHA1 signatures accepted. I've set my key records like that for years. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
>Maybe we can build timelines into the updates. By Jan 1, 2019, receivers >SHOULD (MUST?) no longer support the >following key sizes or algorithms. That way, if anyone complains that a >particular DKIM-signature is not >considered valid, we can always say it’s RFC non-compliant. The IETF historically hasn't done that. Would would make a difference is if some of the big gorillas (you know who you are) said you'll stop accepting weak signatures as of some date, then actually do it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
>If you believe sha256/rsa1024 are forever, there is no actual need for >draft-srose-dkim-ecc-00.txt. The problem is, this need may arrive at >some time, and this time is hardly predictable. There is also possible >there may be the need to roll back ECC and mark it as insecure at some >point of time. So one would expect from the standard: ... One can expect whatever one wants, but as should be self-evident to anyone who's read RFC 6376, it's not going to happen. As Murray noted, signers put whatever signatures they want on the messages, and verifiers accept whatever signatures they find acceptable. If verifiers stop accepting signatures with a weak algorithm it'll be because they stop accepting them, not because of a "this is a weak signature" flag. One of the things DCRUP may do is to recommend that they stop accepting signatures with SHA-1 hashes or 512 bit RSA keys. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
In article <30f3baa9-f13b-91b4-c931-a2fb68582...@diennea.com> you write: >If we want to put a meaningful value in this new field, I think it would >be more useful to make it the time since when the key was obsoleted, >this would allow for mail dated before that moment (which was correctly >signed only with then-not-obsolete keys) to pass verification. This >should be optional, so one could choose if he rather have some valid >mail fail verification, or risk some invalid back-dated mail pass >verification. Good lord, no. That's why DKIM has key rotation. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
>1. produce 2 different DKIM-Signatures with 2 different selectors: >slector1 with SHA-1 + RSA and selector2 one with SHA-512 + ECDSA Of course. >2. add an additional field to either selector1 DKIM DNS record (need to >consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's >allowed but probably is not enough to protect against downgrade) to >indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate >this selector should be ignored if verifier supports sha-512 and eccp256. No. If the verifier is smart enough to understand new algorithms, it is smart enough to figure out which signature to prefer. Also keep in mind that the legacy crypto is sha256/rsa1024 which is plenty strong for the forseeable future. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
In article you write: >This may be of interest to this group, as there isn't an active DKIM WG >anymore. At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM with a new crypto algorithm and/or a more compact key representation (put the key in the signature and put a hash of it in the DNS.) Reaction was positive, people told me to write a proposed charter, which starts here: https://www.ietf.org/mail-archive/web/dispatch/current/msg06701.html Also see: https://datatracker.ietf.org/doc/draft-levine-dcrup-dkim-crypto/ R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value
>My reading of this too-long message thread is that there is essentially >no support for making ARC's header-related issues any different from >DKIM's, so I encourage the chair to shut this thread down. What he said. Can we please limit subsequent discussion of testing about how to test ARC as defined and implemented, not some not-ARC that is not defined and certainly will not be implemented? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value
In article you write: >The issue is that its possible for two separate arc implementations, given >the exact same message inputs, keys, timestamps, etc to be generating two >different, but equally valid ARC seal hashes. DKIM does the same thing. The order of fields in a DKIM-Signature header is arbitrary, and the b= hash includes that header, so there are lots of different equivalent DKIM signatures for the same message and same selector and key. Verifiers use the DKIM-Signature header in the message so they get the same answer as the signer, which I would think would work the same way in ARC-Seal. Can you explain why you think this is a problem? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] "Missed it by *that* much". . .
In article you write: >I'm not sure how you could go about registering key lengths. What do you >have in mind? Come to DISPATCH and learn all about it. The general point is that DKIM's key advice is kind of stale -- 512 bit keys are too short, 1024 keys are OK now, but within the likely lifetime of this spec we'll need longer keys. The obvious suggestion is 2048 except they don't fit in a single TXT record string, and way too much DNS web crudware(tm) doesn't handle multiple strings. Oh, and elliptic curve. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Changing algorithms
As threatened, albeit kind of late, here's plan for how to rotate to a new algorithm. We note that every Arc-Seal and Arc-Message-Signature header has an a= tag that identifies the hash and signing algorithms used. (In sec 5.1.1.1 it just says hash, which is wrong.) Every DKIM key record has k= tag that says what signing algorithm the key is for. That should mean that we could publish several key records for several algorithms at the same domain and selector, except that RFC 6376 sec 3.6.2.2 says you can't. I think that's a bug in 6376, but we can fix that later. We relax the language saying that there can only be one Arc-Seal and one Arc-Message-Signature header for each i= value to say that there can be a group but they can only differ in the a=algorithm, s=selector, b=signature, and for A-M-S the bh=hash if the algorithms have different hashes. The group is valid if the recipient can verify at least one of them. The Arc-Seal signature covers all of the A-S and A-M-S headers, even ones it can't verify, and the header says cv=pass if it could verify at least one of the headers in each group. (Even if you can't verify a new algorithm, maybe the next system can.) To avoid infinite regress, we leave the instructions in 5.1.1.3 alone, so when adding new A-S headers, they're added as a group and the signatures are computed as through the b= in all of the headers in the newly added group were empty. I don't think this will add a lot of code, and it provides a straightforward upgrade path. When a system is upgraded to support a new algorithm, it starts adding headers for both the old and new algorithm. This potentially adds an extra A-S and A-M-S header at each level, but it's just linear, not exponential. When checking signatures, verifiers should try the new algorithm first in each group with multiple headers (it's a lot faster), and if so it need not check any others. Receivers can see from the ARC headers on their incoming mail how much of the mail has new signatures in addition to the old ones and who's adding them. Eventually there'll be enough new signatures that we can nudge the people still using only old ones and eventually only use the new ones. One minor weakness is that the A-S signature signs the headers in a group in whatever order they're in, and if a later system reorders them, the signature will break. We could address that by allowing sequence numbers like i=n.m where the m only affects the order in which they're signed, but I doubt it's worth it. It's hard to imagine a mail system that would only reorder the headers and not also break the signatures in other ways. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section [5.2.1] of the ARC draft
In article you write: >The last time I broached the topic of adding EC to DKIM, I was told there's >no way that could proceed because EC was heavily encumbered by IPR claims. >Is that no longer the case? RFC 7479 adds Ed25519 to SSH and has no IPR disclosures. Dan Bernstein is the primary author of Ed25519 and he's said it has no patent problems: https://cr.yp.to/ecdh/patents.html R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft
>It's been awhile since I've seen this, so it may not be a problem anymore. >There is no obviously correct >thing that someone won't screw up. > >It's probably better to specify how to put multiple strings together. RFC >7208 has words that can probably be >reused without modification. Might as well use section 3.6.2.2. from RFC 6376, since the ARC keys are so similar to DKIM keys. I don't ever recall hearing about this problem with DKIM. I've been publishing multi-string keys for years and never had reports of breakage. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section [5.2.1] of the ARC draft
>We should recommend secure defaults and let users of DNS crudware harangue >their vendors or find new ones that >can support publishing secure keys. We’re also foreshadowing long key lengths >next year. Having been dealing with the crudware argument for a very long time* I can tell you that the chances of getting all the crudware fixed anytime soon are negligible, and nobody's going to change registrars because they can't publish 2K keys. That's why I suggested we add EdDSA. It's, ah, crudware resistant. R's, John * - see draft-levine-dnsextlang-09 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] key sizes, was Section [5.2.1] of the ARC draft
>As I recall there are issues using keys bigger than 1024 bits because >construction and/or correct interpretation of TXT records that contain keys >of that size or bigger has been problematic due to DNS provisioning >software that does the former wrong and DKIM verifiers that do the latter >wrong. I entirely believe that the provisioning crudware gets it wrong, but I haven't heard of verifiers that don't handle multiple TXT strings. Are you thinking of any specific ones? I also agree that none of the other alleged issues are issues, although I still think that migrating to EdDSA would be a good idea. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section [5.2.1] of the ARC draft
In article you write: >I'd like to come up with something better than updating DKIM every time >there's new advice on key sizes, etc. Doing one update that points to the >best current advice, and then letting that other thing get updated >whenever, would be better. Otherwise at some point we'll need to update >DKIM and ARC, and then DKIM, ARC, and the next thing, etc. etc. > >But is there such a reference? I'm pretty sure there isn't. Having checked with Paul Hoffman last night, I have a slightly different version of the suggestion I made. The first is that ARC says that keys SHOULD be 2K and MUST be at least 1K. We understand the only likely deviation from the SHOULD to be due to DNS crudware that can't provision larger keys. Given the short lifetime of ARC signatures, this is cryptographically defensible. The second is to add a more modern signing algorithm. Paul suggests EdDSA with the ED25519 profile. It was designed by well-known civilian cryptographers with no help from the NSA, and there is a high quality reference implementation that everyone likes. A 256 bit EdDSA key is about as strong as a 3000 bit RSA key and the crypto operations are faster, so that's the last signing algorithm we're likely to need. For coding purposes, the minimum key size is just a parameter, and I would be astonished if changing the key size added as much as two lines of code to the implementations. Changing algorithms turns out not to be much harder -- the DKIM or ARC application calls signing and verification routines from a crypto library, and a different algorithm just means calling a different routine. A practical issue is that the most popular crypto library, OpenSSL, hasn't added EdDSA yet. They're currently on 1.0.2, and say it's supposed to be in 1.1.1 which will be released when it's released. So I'd suggest adding EdDSA to the spec, but not expect people to implement it yet. Then we can back-port the change into DKIM with what I hope would be a two-page update. This suggests a tweak to the ARC spec that we should make anyway. The way you do an algorithm migration, like the one we did from rsa-sha1 to rsa-sha256 is to put two signatures on the message for a while, one with the old algorithm and one with the new one. So a validator ignores signatures with algorithms it doesn't understand, and if there are two valid signatures with the same i=N using different algorithms, just pick one. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section [5.2.1] of the ARC draft
In article you write: >Trying to figure out some signing order for pathological cases seems >unnecessary. > >What's the point of passing my failure status on? I agree. We don't have legacy code to work around, so we should concentrate on getting things to work correctly. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM update, was Section [5.2.1] of the ARC draft
>How would you suggest we drive a revision to RFC 6376 to address this issue? As you saw, anything in the IETF that smells of crypto tends to go into the weeds with the crypto fad du jour. If you want to do this, I'd suggest an update with a very small focus: 1) Add a new signature algorithm, probably ECDSA, since it has good support in OpenSSL. 2) Deprecate 512 and 1024 bit DSA keys, and recommend 2K bit DSA or 320 bit ECDSA keys. The reason for ECDSA is that the keys are much smaller. A 160 bit ECDSA key is about as strong as a 1024 bit DSA key, so the equivalent of a 4K DSA key is only 640 bits and will fit easily into a single TXT record string. Make it clear that the scope of this update is only the crypto, so we can more easily chase away people who want DKIM to do something it doesn't. R's, John PS: Although it would be entirely appropriate to ask them "where were you when we were writing the last two specs?" people tend not to respond well. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section [5.2.1] of the ARC draft
In article you write: >> No responsible operator has used the RFC minimum DKIM key sizes for a long >> time. They were trivial to bypass half a decade ago. No one has ever >> complained about 1024 bits default minimum being too big. ... >I agree with your points, but don't you think it would be better to "fix" >the DKIM spec than to have ARC "do its own thing" which does not address >the weakness still enshrined in the DKIM spec? Only if we want to stall ARC for a couple of years while we have unproductive arguments about what it means to update the DKIM spec and whether key lengths are the only thing we want to twiddle. While ARC signatures are a lot like DKIM signatures, they're not DKIM signatures. A spec that says "ARC signatures are created the same way as DKIM signatures except that keys MUST be at least 1024 bits" is no harder to implement than one that says they're just the same, and is likely to match what people do in practice anyway. I looked at the current version of dkimpy (0.5.6) and found that by default it requires a minimum key length of 1024 which you can override with a larger or smaller size if you want. If Scott says nobody's ever complained about it, I believe him. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section [5.2.1] of the ARC draft
>1) Do we have a normative reference within the RFC framework for key >lengths for different crypto systems, and can we simply invoke that >reference rather than including a hard figure in this spec? There's RFC 3766, but it's over a decade old and has rules for how to figure out how long a key you need, not the actual sizes. This NIST publication seems relevant: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf The tables on pages 52 and 53 suggest that we use 2K keys and sha256 hashes. >2) Does such a reference still consider 1k keys as acceptable at this >time? Is there a schedule for periodic review? No. See the document. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC draft issues/clarifications
In article you write: >I'm currently working on a test suite for ARC, and have run into a few >areas in the draft that could use some clarification, mostly with regards >to section 5.2.1, which seems like it needs a non-trivial update. I've run >into the following issues: > >- Can messages with violations in their ARC sets(duplicate/malformed i= >values, etc), still be considered valid, assuming they pass the chain >validation algorithm under the given ordering? >- Similarly, can messages with completely duplicate ARC sets still be >considered valid? My advice is to fail them all, since that's the way to get the message back to MTA authors to fix buggy ARC code. Perhaps at some time in the future we will see consistent breakage due to legacy non-ARC code that we can recognize as broken but legit, and we can agree to do workarounds for them. But at this point, all the ARC code is new, all of it should work, and if it doesn't, the people who can fix it are still around to make the fixes. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag
>It's a request, but my intend was it MUST be supported when the "ruf" >tag is honored. Only if there is no "ruf", or a report generator ignores >the "ruf", than the "fi" may be ignored. (I know some report generators >don't implement "ruf", for reasons of privacy). Remember that MUST only means "do this if you want to interoperate reliably." This is the Internet, where anyone can do anything, including ignoring rate limits. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag
>I'm not sure there's another way. If the domain receiving the reports were >to be burdened with imposing the limit, it has only a few choices: > >* size up to withstand whatever load the greater Internet will throw at it >(expensive); >* build queueing infrastructure to accept anything the greater Internet >throws at it so it can be processed as quickly as possible (also requires >infrastructure); >* return 4xx error codes when you're at capacity (which means pushing it >back on senders or intermediaries anyway). > >Am I missing something? If you're worried about capacity problems from DMARC reports, use a separate subdomain and a separate MTA so if it gets overwhelmed, the rest of your mail isn't affected. If you really want to isolate it, spin it up in a VPS of the $10/mo variety. On today's Internet, 275K messages/day is not a lot, and should not need a lot of infrastructure to handle or discard. If the reports all come from the same place, it is not rocket science to block the source. As you note, if the junk comes from all over the place, you'll need to deal with it all anyway, so a limit in ruf wouldn't help. Also, if you use a separate MTA, you can skip all the content based spam filtering since it's easier to look and see if a message contains the failure ARF report or the summary XML attachment and throw it away otherwise than to see if it looks spammy. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag
>However, under certain circumstances this property can potentially lead >to an undesirably high volume of reports. Especially when a Domain >Owner's name is spoofed and abused in a large-scale phishing or other >impersonation attack. I gather that this was inspired by some sort of phish or spoof that caused people to send you a lot of failure reports. Can you give us an idea of the report volume and rate that raised the concern? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)
In article <713098835.18678872.1478547678821.javamail.zim...@peachymango.org> you write: >The EAI WG found it was fine to remove the obligation to have an email address >part in the >mandatory RFC5322.From header, leaving only the display part to assert the >original author. Only in the very narrow situation where you have an EAI mail system and a non-EAI mail client, and the POP or IMAP server wants to give a version of an incoming message to the client. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)
>So, please point to the formal specification that permits a From: field >to have no email address. RFC 6854 section 2.1 allows the From: addresses to be an address-list. In RFC 5322 sec 3.4, an adresss-list can be an address, an address can be a group, and the group-list of addresses in a group is optional. The example near the bottom of page 2 of RFC 6854, after the second paragraph of section 1, should make it obvious that this expansion is not unexpected. >Absent that, there's the small question about how the EAI group would >have the authority to make such a major change to such a basic email >feature... We did this for the narrow and specific case of delivery time downgrades described in RFC 6858, when a mail system is EAI compatible all the way to the POP or IMAP server, but the MUA fetching the mail isn't. The POP or IMAP server is allowed to smash the headers into ASCII that the ASCII-only client can display and one of the options for a UTF-8 mailbox in a From: or other header is to replace it with an empty group. You can ask Barry how much he expects this to affect ASCII mail, since he wrote 6854. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Mailing Lists and DMARC
>Belittling people who are arguing that a long-standing problem needs >to be fixed is not appropriate. We all agree that the problem needs to be fixed, but many of us believe we have a duty to try to understand a problem before demanding "solutions" which would cause at least as many problems as they solve. >>FWIW, I use Google For Work (or whatever it's called this week) and it >>doesn't automatically add DMARC headers-- You could solve your DMARC problems overnight by switching to a mail provider that doesn't throw away mailing list mail that you want. Fastmail would be a good place to look, competent and cheap. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Mailing Lists and DMARC
>I've seen comments that people who were on Yahoo can fortunately go to Gmail. >What happens when Gmail publishes a >p=reject like they said they were going to (even if the timeline is delayed), >per >https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/? They have said multiple times that they won't do so until ARC is up and working. If they're lying, well, we're all schrod. >Perhaps people can go to Outlook.com? What happens if they go to DMARC >p=reject? Everyone can go an sign up for yet >another domain? > >That just kicks the can down the road, but eventually that can will take no >more kicks. Indeed. We look forward to hotmail/outlook implementing ARC so your users can resume using mailing lists the way they have for 30 years or more. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Mailing Lists and DMARC
In article you write: >FWIW, I use Google For Work (or whatever it's called this week) and it >doesn't automatically add DMARC headers-- Is it too much to ask that anyone who wants to tell us how to deal with DMARC should at least read RFC 7489 so he knows how DMARC works? R's, John Helpful tip: There's no such thing as a DMARC header. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Progress of ARC documents
>Most of the recent work has been in regard to coordinating and testing the >four (4) known implementations of the ARC spec (Google, AOL, dkimpy, >OpenARC). They are each in various stages of completion/readiness for >production. Any chance we could get a peek at dkimpy or OpenARC? We understand that they're beta software. R's, John ___ 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)
>My worry is that if DMARC started as a private mechanism for high value >targets and large msps to collaborate to lower the risk of phishing for >their shared users, and I don't want ARC to be perceived as breaking that. > >I don't want MSPs to have to come up with private lists of high value >targets again, or there being yet another policy enforcement standard for >"no, I really mean it this time". I see your point, but I don't have much hope. DMARC worked great as a way to say "I'm a phish target", less great when repurposed to outsource the pain of some providers' security failures. No matter what we say, there will always be people who believe that the strictest possible option is most secure, then blame everyone else when the predictable screwups happen. So I don't think you can trust people's self-assertion of "I really mean it." Also, keep in mind that DMARC is supposed to be an anti-phishing technology. If some nitwit puts a mailing list's address on his Paypal account or the contact address for ordering some slinky underwear, and ARC allows the notices to go out through the list, so what? It's certainly stupid, it might be embarassing, but nobody's been phished. R's, John ___ 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)
>Should DMARC add a policy setting for whether the domain owner feels that >ARC should be used to bypass regular DMARC evaluation? Please, no. One approach to what we can oversimplify as the mailing list problem is to do it from the sending end, with the sender using something like conditional double signatures to say mutated messages are OK. The other is to provide data that the recipient can use to decide these mutations are OK. ARC is definitely in the latter camp, and it would be painful to have both ends arguing about how OK stuff is. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption
In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >In light of all of the discussion about how the LHS of email addresses are >normalized and encoded/hashed in order to be used to >publish certificates and keys via DANE records like SMIMEA and OPENPGPKEY we >have put together an approach that lets a zone owner >signal the policy that is used for their domain by adding a few keywords to >the DMARC record. > >The draft is at: >https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/ Since this is a a draft about mail operations, I would strongly suggest that you post it to the ietf-smtp list, where people with experience in nontrival mail systems hang out. In particular, you might ask about "canonicalization policy of LHS portions of email addresses", and to move things along, you might want to review RFC 5321 and find a better term than LHS. I also share Kurt's concern that it seems like a bad idea to mix advice intended for MUAs with the existing DMARC advice which is purely for MTAs. R's, John ___ 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
>I can put together an appendix with some examples. I was thinking that >having a better explanation would provide more value so I guess I got your >suggestion backwards :-) I'd prefer that you post the current version of the draft so we can see what the context is. Draft revisions are cheap, posting three in a week if there are changes is not unreasonable. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-02
>I had not noticed -- and still don't quite understand -- what it is >about the new stuff that will cause a legacy engine to fail the >signature validation. It's in section 3.5 of RFC 6376, the part about the DKIM-Signature header, where it says: v= Version (plain-text; REQUIRED). This tag defines the version of this specification that applies to the signature record. It MUST have the value "1" for implementations compliant with this version of DKIM. ABNF: sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT INFORMATIVE NOTE: DKIM-Signature version numbers may increase arithmetically as new versions of this specification are released. People have looked at the code in most existing DKIM verifiers to see whether the code matches the spec, and the current code does indeed reject signatures that don't start with v=1. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] versioning in draft-levine-dkim-conditional-02
>1. I wasn't recommending making the new feature optional. Merely >noting the considerable benefit that accrues if you can live with it >being optional. You might want to reread my draft, because this discussion has no relationship I can see to anything it says. The DKIM spec says a signature is valid if a list of things are true, e.g, the hash of the message's body matches the bh= value. But since the spec says that unknown tags are ignored, there's no way that you can add a new tag that adds a new condition to the existing ones. All you can add are tags that are comments. You could hypothetically add a tag that would make an otherwise invalid signature good, e.g., here's another place to look for the key, but that seems to me like a bad idea and nobody I know has done it. What I want to do is add new optional conditions, this signature is only good if all of the normal things are true, and these other things are true, too. Someone (not me) had the bright idea to use an indicator, currently an exclamation point, to say that a tag adds a new condition, so the verifier fails if it can't check all the tags with that indicator, and we can add more condition tags later without another version bump. But now the syntax has changed, so if a signature uses the new kind of tag, it has to be a v=2 signature. If a signature doesn't, it's still v=1, so everything that used to work still works. If an old verifier sees a v=2 tag it'll fail, so this fails closed. This is about this simplest version of upward compatibility I can imagine. You could do a hack to put this in an otherwise invalid v=1 signature, e.g., put the body hash in a bh2= field and omit the bh= so only a verifier that knows about bh2 will succeed, but why bother? It's ugly and would work in exactly the same places that v=2 does. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-02
>> Quite correct. I would expect conditional signatures to be applied by >> large mail systems, using their private list of domains that look like >> mailing lists to decide who gets them. > >How much of a barrier to entry to new or small mailing list providers >(or new domains being used there) does this cause? Beats me. Depends on how the large providers manage their provider lists. In an optimistic scenario, they see the welcome message from the list and use that to add the list's domain to the resigner list. On the other hand, compared to the current situation, ... R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-levine-dkim-conditional-02
>> The local signer here must know this message goes to dmarc@ietf.org >> an add a signature including "!fs=ietg.org" > >An average email author cannot be relied on to cause this setting to be >made. Quite correct. I would expect conditional signatures to be applied by large mail systems, using their private list of domains that look like mailing lists to decide who gets them. >From the past couple of years of discussion, it is clear that all of the large mail systems already have such a list of domains, so the implementation should be straightforward. Small domains may not, in which case there's a variety of ways they could approximate it, e.g., sniff incoming mail for stuff that looks like list mail to create a list, cooperate on a shared database of mailing list domains, or most likely admit that they are too small to be phish targets so publishing a DMARC policy is counterproductive. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows"
> A sender that expects a message to be forwarded might put both a > conventional DKIM signature and a signature with a !fs tag that > refers to the domain name of the expected forwarder. > > require conventional, full DKIM signatures. Why? It seems to me that any >DMARC authentication method could suffice. That is, the author domain (!fs >signer) could be SPF authenticated by the MLM; and the MLM could be SPF >authenticated by list recipients. No? You're mixing levels here. dkim-conditional describes a new way to create a valid DKIM signature. I wouldn't want to try to describe how a DKIM validator is supposed to stop and take a detour through an SPF validator to decide what to do next. R's, John PS: the draft looks fine to me ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-levine-dkim-conditional-02
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
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-05.txt
>ReSenders haven't introduced any interoperability issues. DMARC has. How >about: Indeed. I agree with the advice to refrain from blaming the victim. > o MTAs sending email on behalf of multiple domains may require > Domain Owners to provide DKIM keys to use DKIM to avoid SPF > alignment issues. Managing DKIM keys with a third party has > security risks which should be carefully managed. > >This can generally be done through CNAMES or subdomain delegation. I've yet >to see anyone handle this situation by actually exchanging private keys across >an administrative boundary. A manager at a well known ESP told me that one of the free mail suspects gave them a DKIM signing key. (I forget whether it was A or Y.) R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Confused about DMARC Reports (ruf/rua)
>But I am still receiving reports from hotmail despite DKIM and SPF >tests passing ? So I don't understand what hotmail's system's are >moaning about ?!? Aggregate reports aren't failure reports, they're aggregate reports. They tell you about all incoming mail that purports to be from you and what the recipient thought about it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] weak dkim canonicalization
>We've been looking at weak dkim from the angle of reducing what's covered >by the signature... but unfortunately, that takes out the major parts of >the message that we care about. > >I'm wondering if there is a different alternative. When we were doing DKIM, we went around and around and around trying to figure out what sort of modifications we could allow and still consider messages to be "the same", with negligible success. All we came up with was relaxed canon and l=NN. The point of relaxed was to allow for the sort of message tidying up that sendmail used to do before people understood the distinction between mail submission and mail relay. It is my impression that these days it's rare to have a message that passes relaxed that wouldn't also pass strict. The point of l= was to allow mailing lists to add footers, not so much because we thought that would solve a lot of problems but because it was the only thing we could think of that might solve one problem and it was cheap to specify and implement. Again, I don't get the impression that it's used very much, and messages with l=N would usually pass anyway. Google has some great algorithms people, so maybe they can come up with some essence of message fingerprint that works, but I'd be surprised. Anything that a mailing list might do to add innocuous text to a message, a spammer can do the same but adding spam text. I don't see any way around that. We can probably come up with a hack for subject lines just because subject lines are so short, but I'd be pretty surprised if anything more general were workable. (Proposed subject hack: add a new code to DKIM-Signature that says to use the copied subject from z= when verifying the signature, but only if the contents of that subject is a substring of the current subject. De-MIME-ing is a quality of implementation issue.) For my double signing hack, I'm coming at it from the other direction, what problem are we trying to solve. When AOL and Yahoo made their unfortunate DMARC decisions, they had a very concrete problem to solve. They'd allowed crooks to steal address books, so Yahoo (or AOL) users were getting spam with Yahoo addresses of people they knew, sent from random botnets, not from Yahoo. I believe that double signing still solves 99.9% of that problem while allowing mailing lists to do most of what they ordinarily do. While it is true that a malicious re-signing mediator could still delete the contents of a weakly signed message and replace it with spam, this greatly decreases the attack surface. The malicious party has to have a recent real message in hand from the real author, and the real author's mail system has fine grained control over who they allow to re-sign. Start with a heuristic about what domains are likely to be mailing lists (something I know gmail has from the comments in the aggregate reports), put weak signatures on mail sent to them. If a particular mediator's spamminess spikes, you can stop putting weak signatures on mail to the bad actor without having to break mail to everyone else. For incoming mail, the double signature allows you to tell the difference between direct mail and mediated mail, with the double signature not meaning that the mail is "real", but rather that it came via someone with at least a weak relationship with the author so it's likely non-horrible enough to be worth running through the normal spam filters. This does require heuristics and tuning, but so does any spam filter, and what this does seems similar to what any spam filter does anyway. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt
>It is not wrong, I think you have no practical experience with EAI. You might want to review these, as well as RFC 6783. http://www.circleid.com/posts/email_in_the_worlds_languages_part_i/ http://www.circleid.com/posts/email_in_the_worlds_languages_part_ii/ http://www.circleid.com/posts/email_in_the_worlds_languages_part_iii/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC ATPS Interop Note
>> (3) I would really like to see some provision for reporting to mailbox >> users when their mail is being discarded due to publication of >> p=reject by their mailbox providers, especially in cases where a >> Mediator is willing to put its reputation on the line by signing >> the forwarded message. ... >The email is bounced, not discarded. The mailbox user knows about it. >Unfortunately, bounces are so ugly that few people can successfully read them. Good point. I would like to see some provision for reporting to mailbox users when their mail is effectively discarded due to p=quarantine. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt
>Please submit "stuff" that needs to be fixed The worst problem is still section 3.1.2.3 which needs to be deleted, since most of what it says is wrong, and what little isn't wrong is irrelevant. RFC 6854 is not about EAI, since an ASCII MUA can create mail with an empty group From: as easily as an EAI MUA. The assertion that RFC 6854 allows empty groups "during the transition period to SMTPUTF8" is false. Empty group syntax has nothing to do with DMARC since there is no domain on the From: line to check. From a DMARC point of view, there is no difference between a From: with an empty group and one with an address in a domain that publishes no DMARC record. This sentence is completely false. EAI MTAs never downgrade mail in transit: If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non- aware MTA, the EAI/SMTPUTF8-aware system may transform the RFC5322.From header field of the message to include group syntax to allow the non-aware MTA to receive the email. Section 4.1.2.3 is equally wrong for the same reasons and also needs to go. Section 4.1.3.1 doesn't mention rewriting the From: address to a valid forwarding address in a domain for which the list can sign. It's not just me doing it, LISTSERV can do that, it's widely implemented. Take out .invalid, nobody does that because (as I discovered and you mention) many spam filters dislike From: addresses with domains that don't resolve. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
