Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Alessandro Vesely <vesely@tana.it> Tue, 12 November 2019 08:16 UTC

Return-Path: <vesely@tana.it>
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 108BF120169 for <dmarc@ietfa.amsl.com>; Tue, 12 Nov 2019 00:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoXeXy7bmGlz for <dmarc@ietfa.amsl.com>; Tue, 12 Nov 2019 00:16:42 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C1F120046 for <dmarc@ietf.org>; Tue, 12 Nov 2019 00:16:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1573546598; bh=eHQQGjunCrh5uNx3GuNzl4GCsvIMQnVKV63ZlpnOAP8=; l=1520; h=To:References:From:Date:In-Reply-To; b=ADIkhJ0NpZi8lS2DvTAtd+tEWc7gBXaLCn7uFURmhpO7y58cygKTCcF8dA12nyEwj pRhd3erdwSvugZrBV+//l+T+EETV/RYazJwolXPqgJaxa1SNd9HiHE5xVsp62ChhQn MfNeUA9Idqx71z7yn0m6jB7bFTDOwCBG4Vp4X43sL/qs0TA/YGzeBv1tLownZ
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC073.000000005DCA6A66.0000526E; Tue, 12 Nov 2019 09:16:38 +0100
To: dmarc@ietf.org
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <CAL0qLwacbAT04tckpPcRcnOt=1QByOBeJ7uDf6rNK6NRwtxZYg@mail.gmail.com> <ffa2bf72-3024-237b-86ae-9cc04babeec6@gmail.com> <74a0ea49-7a46-4eb6-c297-cd703f63bd1b@gmail.com> <CAL0qLwbp2hNrgF_xxhKRRODQ6HP=U5_K-r3Wtm1wJZOZcKup3g@mail.gmail.com> <9DE9E7DC-FE60-4952-8595-B2D087A6B780@kitterman.com> <CADyWQ+GSP0K=Ci22ouE6AvdqCDGgUAg3jZHBOg3EwCmw=QG84A@mail.gmail.com> <CABuGu1obn55Y2=CuEYRYCEO3TYYNhYTsdkesQ67O61jRyfO=wA@mail.gmail.com> <59947cf1-1851-af56-536e-f78530e79dd2@tana.it> <LO2P123MB2285B674B32C689CE2C1455DC9770@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <f098ff76-ea8d-3b8e-8110-dcb41459acc0@tana.it>
Date: Tue, 12 Nov 2019 09:16:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <LO2P123MB2285B674B32C689CE2C1455DC9770@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/sQ80VwDRO2LPMODwFhaPr1XNt6k>
Subject: Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 12 Nov 2019 08:16:44 -0000

On Tue 12/Nov/2019 07:59:09 +0100 Ian Levy wrote:
>> while _dmarc.gov.uk returns a valid record. The latter is a Nominet,
>> already solved problem, AFAICS.>
> I can speak authoritatively about this. What we’ve got is an evil, hacky
> kludge that has some weird side effects (since we respond to *any* non
> existent sub domain, not just DMARC and SPF related ones). It’s just about
> passable as an interim, but we believe we need a better, targeted solution
> along the lines of Scott’s draft.

Thank you for chiming in.  Let me pinpoint that the hack you talk about is the
use of wildcards, which Scott's draft tries to fix with the np= tag.  That's a
protocol issue.

At a PSO level, someone decided that gov.uk can publish TXT records which may
affect all of the downward tree --solved.  The bank PSO cannot do that, and we
(the WG) look forward to ICANN allowing it --not yet solved.  The com PSO
cannot do it either, but I'd guess lots of people trust that ICANN will never
allow it.

I hope I've now clarified what I mean by "ICANN problem".  Scott's draft cannot
solve it, albeit it nearly touches on the point at the end of the intro.  It is
not a protocol problem.  It involves PSO-registrants agreements, and ICANN
managing that stuff.  There is not much we (the WG) can do, except hoping that
ICANN may consider protocol factors when making decisions.  As an Internet
user, I'd welcome diversity among TLDs, as numerousness without diversity
becomes just annoying.


Best
Ale
--