From nobody Thu Jun 1 08:06:28 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 64C1BC14CEE3 for ; Thu, 1 Jun 2023 08:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.096, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no 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 sq4lcF5bKPFk for ; Thu, 1 Jun 2023 08:06:23 -0700 (PDT) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 A322CC14F738 for ; Thu, 1 Jun 2023 08:06:23 -0700 (PDT) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5147f5efeb5so1525332a12.0 for ; Thu, 01 Jun 2023 08:06:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685631982; x=1688223982; h=content-transfer-encoding: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=zfTGFtZVMaY8smotAVLNV7grMpE/NzR2V1EFSrihyH4=; b=jGlNYeOTbZ1Afc+wd+C8JdkKJpprc5q6Q8zLFvIeYJYPdS/XE3WvRN0M55wfWW4k1i 9zI5e1CYqKeOIquijgCFQB206q9KoD6JghVGawK9dGy/xrnljpXcSwZBDzAQsiz0QE1P zX3fJTI4xrCVhf1W+oRLlHu5MQ9lKnwHmC2flZV5OTUWdB4txQOjo/b0feIGrPTscol9 ZtJKK9PI2ZiApQABrAzditVbKf3XR6Kz99gKiaCtkZJWYF9wEmbYRvWMsfeVtZoJhcF1 plAtJI8D428ZLNxC1vwZddWnL2Td1yKhrS7mZQRXgwHJ3b4QiOzSHihdt+VD8tvDPMFu hCZw== X-Gm-Message-State: AC+VfDwwDoCYMZHPAdWfeGs4PW8oCh0Hdef2TgZAqz8yr623X0fLZ9D3 FmCaUa6TuKmR3LnVeMfu5pMjMQbQsZl66a06GY8= X-Google-Smtp-Source: ACHHUZ7NBN3PRKQ/vx+Nf3Pqiv8vaWe+MCW1xQRMZH5n98VlKCNo63Ue43gd/Wbp0yDsw9lzz24ew8mUfzVnswVjROA= X-Received: by 2002:aa7:c586:0:b0:50b:fb85:8608 with SMTP id g6-20020aa7c586000000b0050bfb858608mr128270edq.25.1685631981744; Thu, 01 Jun 2023 08:06:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Thu, 1 Jun 2023 11:06:04 -0400 Message-ID: To: Douglas Foster Cc: IETF DMARC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] Sibling Authentication 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, 01 Jun 2023 15:06:27 -0000 We have discussed and settle the tree walk issue many times now. What new information is here that we haven't already discussed? Please be very specific. Barry, as chair On Thu, Jun 1, 2023 at 7:03=E2=80=AFAM Douglas Foster wrote: > > I cannot support the current draft because it creates new problems withou= t sufficiently solving the old ones. > > The PSL is subject to two types of errors: > - Landing too high, causing False Pass on non-affiliated domains > - Landing too low, causing False Fail or False NoPolicy on domains that a= re actually affiliated. > False Pass presents the greater threat. While it could occur on any type= of non-strict alignment, the primary concern is False Pass on sibling alig= nment. > > The bottom-up-first-stop tree walk attempts to solve the problem of False= Pass by using an algorithm that will often land too low, causing False Fai= l. Nonetheless, it fails to solve the whole problem because evaluators are= still at risk from private registries that publish a DMARC policy with str= ict alignment but without a PSD tag. The proposed tree walk has other probl= ems, because it changes an organization's relaxed alignment boundary every = time that a policy is added or removed. It also means that domain owners m= ust ensure that their policies and their configuration produce the correct = result whether the evaluator is using RFC 7489 or DMARCbis. > > The PSL security problem is caused by relaxed alignment itself. To be se= cure, relaxed alignment requires a certainty about organization boundaries = which we cannot yet provide. The appropriate response is to eliminate sibli= ng authentication. This change would provide immediate protection for eval= uators, with minimal changes to their running code. For implementations t= hat have an adequate DMARC exception process, sibling authentication can be= permitted for specific message sources using local policy. With this cha= nge in place, the differences between PSL lookup and Tree Walk becomes much= less important. > > My data indicates that sibling authentication is so lightly used that we = will see minimal disruption to legitimate traffic, much less disruption tha= n will occur from the proposed tree walk. I am hoping that Google can prov= ide more specific data about the use of sibling authentication under differ= ent DMARC disposition policies. > > As long as the parent-child and child-parent forms of relaxed alignment a= re permitted, we need an explicit tagging mechanism which gives the domain = owner full control over alignment boundaries and eliminates uncertainty abo= ut the domain owner's intent. Parent-child and child-parent authenticatio= n will be important for as long as SPF-alignment is necessary. For DKIM si= gnatures, I am not convinced that relaxed alignment should be necessary eve= n though it has some current use because it is allowed. > > A domain owner who wants to maximize deliverability should maximize evalu= ator trust in the message authentication. Maximizing trust means that the= message should be DKIM signed, and should be signed with strict alignment.= Our document should steer people in those directions. The DARA draft, w= hich has much to contribute about the forwarding problem, already moves us = in that direction by requiring exact-match signatures. > > Doug Foster > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc