Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

Todd Herr <todd.herr@valimail.com> Thu, 14 March 2024 21:12 UTC

Return-Path: <todd.herr@valimail.com>
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 2E8DEC14F6BE for <dmarc@ietfa.amsl.com>; Thu, 14 Mar 2024 14:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 cki7VG0WeRPb for <dmarc@ietfa.amsl.com>; Thu, 14 Mar 2024 14:12:11 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 BD22CC14F6BD for <dmarc@ietf.org>; Thu, 14 Mar 2024 14:12:11 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-dc745927098so1213471276.3 for <dmarc@ietf.org>; Thu, 14 Mar 2024 14:12:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; t=1710450730; x=1711055530; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=uN9UX9CwlpM8klLBGB2FBomNO0WDQ9Eaif1ci4n5e1g=; b=H/jpDf9/8HMl4tO5vvu2PQfktgyIgRKG4+D1iY7Q2uA30P90XxBo+na6EcUx99e09t q0Ia8ahKP/noKAdApu0+JeFeccTOyWIZRL26ZTBDlsH5+vv5pmNNYBwb11Q4JAZs9NgW rMxWT1zqCcPvtM9bp9mzDA/nRT2F1glUicf5zZSciqrEG0Ya16qdbaNF1AVZN41lXDyU FIqvzQEpnO3eJzDjdSu2OpZGjCskXNBwhxlSyCCianB1FUYZqUiPSWdVqkOt9tDU4k+D wCasCyEDZ4iLUeqk3yOmJJ5z+DHa6+OnV2/fr7aX+n19si000VVj5hDqX+xqTTxJEvMv 8wxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710450730; x=1711055530; h=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=uN9UX9CwlpM8klLBGB2FBomNO0WDQ9Eaif1ci4n5e1g=; b=V56TE2UO0r1BAz7wNVY22msXqPaQGRe3uIDcdYpvMAGxtIhr4ZYgE2ZZLbRhPo7/8E czAO8sRW8hgbAsOcY4vDMHOtwhj2lcgSoUV/5qsqyDzeUi4v0MvnhtdGWnL1nIzvykYa mX8zssmYbSK7zHg5IgYWdALSNwCjfq5aOipOgCzn6+HrHShmRhunf9C6KMPbwjVn1e4x eTfpRtZas0fyDAK5mfDL28Yxy3fR1YZ77p8J3td7Vpw7RCXZweNdXsMGe/7d0oKfzjrm ilZ0tF6BJXgsXgl7rBINRs12PtCWOYKeK1PnsTve3Zz/skZSqvHH66Oj96LaPyelGM2v ozbg==
X-Gm-Message-State: AOJu0Yyyu+Nzl6/FB27Cbe9R1gcVEvEX5fgSYLMT5Xaig7XV7uE1yuBr 9539+bmQV3Tw3lxgwTZC8mPWlPdeFRxggLm8sWEkyMqfqaCPS23piM6euaLeXSE2oClzj+j4GP0 6g6hyU0JSVTW4eLXq+INtp0QIeXbRvRBU1FHxriFqnWnMKtFK
X-Google-Smtp-Source: AGHT+IFS2GZkecQTaNC0tp4V0ca6xSa1F3dVH/mR23Y09tVrEav2/PIaeP07tHDJfYtv+5dVlhcKsKUwQFO4zVCtz5Q=
X-Received: by 2002:a25:7c42:0:b0:dcc:6757:1720 with SMTP id x63-20020a257c42000000b00dcc67571720mr120318ybc.32.1710450730113; Thu, 14 Mar 2024 14:12:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAHej_8kip_p+n56=Y5WuVG2M_+HXHj51fyY3k6dx-itJRZkCpQ@mail.gmail.com> <B18FD596-D342-4569-8A23-3E01B137DDDA@kitterman.com> <CAHej_8=+fHDstBHCzS54cr5dmGo=XfyXy0wzaS6gY6WokpF_Lg@mail.gmail.com> <791cdf24-011d-4cd1-83cd-79d438f3020d@tekmarc.com> <CAHej_8my0_2y5NqsqawiH3x1S5Xn14eGXGYDNfHmPOWu585TKw@mail.gmail.com> <d87d4fd3-2a28-49a9-b427-b11e2f14b984@tekmarc.com>
In-Reply-To: <d87d4fd3-2a28-49a9-b427-b11e2f14b984@tekmarc.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Thu, 14 Mar 2024 17:11:54 -0400
Message-ID: <CAHej_8knzL1TTEGP4p31+9JKb8qwqGPc-OO3AieYocGtzp9pTg@mail.gmail.com>
To: dmarc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002cc1c70613a5585c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/R2MSbvpgzdKSjRt-BHWAAID5JGA>
Subject: Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2024 21:12:16 -0000

On Thu, Mar 14, 2024 at 5:05 PM Mark Alley <mark.alley=
40tekmarc.com@dmarc.ietf.org> wrote:

> On 3/14/2024 3:49 PM, Todd Herr wrote:
>
> On Thu, Mar 14, 2024 at 4:43 PM Mark Alley <mark.alley=
> 40tekmarc.com@dmarc.ietf.org> wrote:
>
>> On 3/14/2024 3:38 PM, Todd Herr wrote:
>>
>> On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman <sklist@kitterman.com>
>> wrote:
>>
>>>
>>> I think this is correct.  I think it's obviously enough correct that I'm
>>> surprised anyone was confused.
>>>
>>> Do we know what the theory was that led people to think otherwise?
>>>
>>> Seems to me we don't really need this, but maybe there's a reason.
>>>
>>>
>> The reasons given were:
>>
>>    1. https://www.rfc-editor.org/rfc/rfc5863#section-4.1
>>    2. https://datatracker.ietf.org/doc/html/rfc6376#section-7.5
>>    3. Neither RFC 7489 nor DMARCbis contain the phrase "CNAME", so if
>>    it's not explicitly mentioned...
>>
>> Granted, the first two citations are in regards to DKIM records, not
>> DMARC records, but those were the reasons given.
>>
>> Couldn't hurt to clarify explicitly, I'm for it. Domain owners have been
>> using CNAMEs with DMARC TXT RRs pretty much since its inception.
>>
> I agree that clarifying it can't hurt, obviously, but I was quite
> surprised to hear that CNAMEs were being published for DMARC records, as
> I'd never seen one. On the other hand, I've seen *lots* of DKIM public keys
> published as CNAMEs, which I'm sure just wrecks the person citing DKIM RFCs
> as a reason that DMARC records can't be CNAMEs.
>
>
> Domain owner use cases with DMARC CNAMEs boils down to really either of 2
> things:
>
>    - Single point of policy management for orgs with dozens, hundreds, or
>    thousands of domains to manage DMARC on, and also applicable to RUA/RUF
>    addresses.
>    - Delegation to a third-party for management, similar to DKIM CNAMEs
>    as you noted that are popularly in use by many ESPs for vendor-managed key
>    rotation.
>
>
Yup, I grok the use cases. I just hadn't thought of them prior to this
discussion.

-- 

Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.herr@valimail.com
Phone: 703-220-4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.