From nobody Thu Jun 22 09:09:18 2023 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBDBC1519B0 for ; Thu, 22 Jun 2023 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDbvkTZ5H5ia for ; Thu, 22 Jun 2023 09:09:16 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B978BC1519A0 for ; Thu, 22 Jun 2023 09:09:16 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2b57b4e95a8so10032601fa.1 for ; Thu, 22 Jun 2023 09:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687450155; x=1690042155; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qI9TNwrsLvXMDu0z+4UIG3q+BKBShPvhpQY/DPgMDAU=; b=YVK2ddX5fFlm66NRyWUVGjpzvNkhLaXLvLiMeUq6ldxqpTvKmYkg2FWj4LIF1/Zspi RAW9gtM2QPzm/bZbTdu/mBMeEdgHgKwubuR/l2NZ4uT/j6290sawzMRdrETFqrT5pIu1 q+JFLYIF1rJ67WygG2RcZKZMUwklm4h+cERsk4I9pYg5/PWntJzrpbo8xvTL0xknrPXM xh7GdodxpHROgAr94HjLb71ZK0maIYq1Lhoi8S3UJwmJ/kdw237MfZjZq7zpV/lofcR+ NzdfInwGZLgt3JBCdBFvnHX2/vGx7ouJXx2eohXkdi/jDTWwgPtlOfUMknZwXRD1RxMP +zlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687450155; x=1690042155; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qI9TNwrsLvXMDu0z+4UIG3q+BKBShPvhpQY/DPgMDAU=; b=IHdlYbgVYOcEUnDjYsi3gAYO/owoYQ4RoMtw0NIWdDjJdZmgyRPkDm12Hc6IBAEwaO Sj5Ftpw9OiGn1RRBTwY1hwb5qo/88EJ+h+fcgYkJPcEoyU0wjaquQSOJMspvqdMhdxbc fppZTIni0kPTTevAvgw65m0V/xq0NtmhRldpEDXtYPyQGud1V1GIcB9+9AeUsoP3M3eq vL7nvmdTtX8TkjubF1yU8BkgqDuioLxqAfrwaD7/vfxzEg9VN17GvsuyKOn18J6KNbgW EHtwWZpnN+HgIyCoXatMjIu03WtEZ/RBoibrqunWVLMn3bNSzeg/W+pj6qgPwzlY53Kw O2KA== X-Gm-Message-State: AC+VfDy/swQ5bWX3votCXXZjUTQLkyJWhYPmBjrUNREc7uUq3NihaIhW 85EtshXRS/UShJSV787uBHegSnx/SDGqFLZeMSuqFMqp X-Google-Smtp-Source: ACHHUZ6XX/rn+Pu+tpOMOX0w52RxpEELHB76e2iLCoZ5aREe4Iz2RjxKAd3ShDHmqbokCIVK7PkA1WeP9aWCxzDcGMA= X-Received: by 2002:a05:651c:2002:b0:2b5:8ff0:59ad with SMTP id s2-20020a05651c200200b002b58ff059admr1419791ljo.4.1687450154536; Thu, 22 Jun 2023 09:09:14 -0700 (PDT) MIME-Version: 1.0 References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <2817813.dRqVH37e0G@localhost> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <3087d0fa-91b4-62b4-fc64-a705c7f0b672@taugh.com> <2de0ca2a-2c18-91ae-f306-38e70aaebf8e@inboxsys.com> <2080c6e5-2b57-be82-995b-a0986c3a45c5@inboxsys.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 22 Jun 2023 09:09:02 -0700 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000009940705feba1b0e" Archived-At: Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2023 16:09:17 -0000 --00000000000009940705feba1b0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2023 at 6:32=E2=80=AFAM Todd Herr wrote: > Marty also has the right to engage a third party to send the mail (again, > as conveyed by their employer), mail that Marty and others at Marty's > company will create. The third party here is most commonly referred to, i= n > my experience, as an Email Service Provider (ESP), but this is just one u= se > case. The ESP knows how to DKIM sign messages, and can even do so using t= he > domain of Marty's employer, so long as Marty is able to get the public ke= y > published in DNS. > We thought about this during the early DKIM days. It was called out more than once that at sufficiently large organizations, the email people and the DNS people are not certain to be part of the same organization. That's certainly true where I work. And at a subset of the largest of those organizations, the email people and the DNS people don't trust each other either, so they sometimes make it harder for one to tamper in the space of the other. We tried to keep this in mind while designing how DKIM could function. I concur that this isn't really a problem for either working group to solve as part of a standard, but there might be room for some suggestions if either one ends up producing a best practices document. The open source DKIM package I developed included a simple tool that would generate a properly formed TXT record and associated comments suitable for inclusion into a zone file, but there was feedback that it was still error prone. It also included a script that, once you had published a DKIM record, would confirm that your signing key and the public key now in the DNS matched, so signatures should work. I had two thoughts over the years about other things to try: (1) Instead of generating a DNS TXT record for someone to cut and paste, output a complete "_domainkey" zone file to simply move into position, i.e., by copying files rather than strings. This is less prone to corruption because copy-paste isn't part of the process. (2) Make use of protocols like DNS UPDATE (RFC2136) that could allow DKIM key generation tools to insert new records directly into the primary authoritative server. This is even less prone to error or corruption because the human is almost totally removed from the process. -MSK --00000000000009940705feba1b0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 22, 2023 at 6:32=E2=80=AFAM T= odd Herr <todd.herr=3D4= 0valimail.com@dmarc.ietf.org> wrote:
Marty a= lso has the right to engage a third party to send the mail (again, as conve= yed by their employer), mail that Marty and others at Marty's company w= ill create. The third party here is most commonly referred to, in my experi= ence, as an Email Service Provider (ESP), but this is just one use case. Th= e ESP knows how to DKIM sign messages, and can even do so using the domain = of Marty's employer, so long as Marty is able to get the public key pub= lished in DNS.

We thought about this = during the early DKIM days.=C2=A0 It was called out more than once that at = sufficiently large organizations, the email people and the DNS people are n= ot certain to be part of the same organization.=C2=A0 That's certainly = true where I work.=C2=A0 And at a subset of the largest of those organizati= ons, the email people and the DNS people don't trust each other either,= so they sometimes make it harder for one to tamper in the space of the oth= er.=C2=A0 We tried to keep this in mind while designing how DKIM could func= tion.

I concur that this isn't really a pr= oblem for either working group to solve as part of a standard, but there mi= ght be room for some suggestions if either one ends up producing a best pra= ctices document.

The open source DKIM package I de= veloped included a simple tool that would generate a properly formed TXT re= cord and associated comments suitable for inclusion into a zone file, but t= here was feedback that it was still error prone.=C2=A0 It also included a s= cript that, once you had published a DKIM record, would confirm that your s= igning key and the public key now in the DNS matched, so signatures should = work.

I had two thoughts over the years about othe= r things to try:

(1) Instead = of generating a DNS TXT record for someone to cut and paste, output a compl= ete "_domainkey" zone file to simply move into position, i.e., by= copying files rather than strings.=C2=A0 This is less prone to corruption = because copy-paste isn't part of the process.

(2) Make use of protocols l= ike DNS UPDATE (RFC2136) that could allow DKIM key generation tools to inse= rt new records directly into the primary authoritative server.=C2=A0 This i= s even less prone to error or corruption because the human is almost totall= y removed from the process.

<= div class=3D"gmail_quote">-MSK
--00000000000009940705feba1b0e--