Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL

Scott Kitterman <sklist@kitterman.com> Mon, 11 November 2019 20:08 UTC

Return-Path: <sklist@kitterman.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 C04D012081C for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 12:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=rafvkf28; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Z3juQZ7f
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 YLnhn01RlpvY for <dmarc@ietfa.amsl.com>; Mon, 11 Nov 2019 12:08:08 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D44B12022E for <dmarc@ietf.org>; Mon, 11 Nov 2019 12:08:02 -0800 (PST)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id D1D8EF804AA; Mon, 11 Nov 2019 15:07:58 -0500 (EST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1573502878; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=wpV//jWgDgmMyRc2gGz+lkQ67TfevmJG33rIyGbNaZ4=; b=rafvkf28Ih6IcifYDfyPRAJ6AwT0wmSBCm6h9erhtcvKgxxhMiudMnSu tQNg1GF82qP4JGkq8Xqvi8NDPcb9BA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1573502878; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=wpV//jWgDgmMyRc2gGz+lkQ67TfevmJG33rIyGbNaZ4=; b=Z3juQZ7f0vAloOSoV5yPlEIzIbCSGoF4l6uXZMnGmSC1tDIWC0t3VZ2U nQUpleT0fUJl1cdcawAPQWYAuwKpUx7n7984JMfOJDETsd+6jJJRYb47kZ PD8WbN/uiKdQHpqz1zLeENMQAb6ITXNdsgai60g8OLBaUAp4OoJE1tnglf 4m58Uq79tX0Apcr+Lh+ZxT5/qyzqi5Ho6e79YHSptS0ROpr1UmHGj5/IwZ OVDXdAM3NjpVtvXp7vhEwl0JnxuZNk/K2RLqdY/y8thp1Q+/Uz48d7PQr6 8GgUBszw0XOCDXOuRbePa5G7e7803tiJOCDkfiUBa+UpavAZAeP7DA==
Received: from [10.8.227.33] (mobile-166-170-34-138.mycingular.net [166.170.34.138]) by interserver.kitterman.com (Postfix) with ESMTPSA id 8A8D7F80041; Mon, 11 Nov 2019 15:07:58 -0500 (EST)
Date: Mon, 11 Nov 2019 20:07:50 +0000
In-Reply-To: <20191111155410.12A31E9E35A@ary.qy>
References: <20191111155410.12A31E9E35A@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <6A590DA7-4EE9-4C68-9932-89F6110AE158@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/dFBS2_BVkBLQrN_9OGmAArBSlM0>
Subject: Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL
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: Mon, 11 Nov 2019 20:08:10 -0000


On November 11, 2019 3:54:09 PM UTC, John Levine <johnl@taugh.com> wrote:
>In article
><CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=dxK5w@mail.gmail.com>
>you write:
>>Just to be clear: The policy for changes to that registry is "Expert
>>Review", but since the action that put it there was a document with
>IETF
>>consensus, I'm pretty hesitant about just approving this change based
>on a
>>formal request.  I'd rather at least see some consensus discussion
>about
>>it, or even better, a revision/update to RFC8601.
>
>Hey, wait, Expert Review is supposed to be considerably looser than RFC
>Required.
>
>Since there's no danger of running out of token names, I'd encourage
>you to accept new ptypes if they have a clear spec and a plausible use
>case.  In this instance, I think the description in the I-D is OK, but
>for the use case I would like some evidence that someone, somewhere is
>implementing it and doing something with the result.

I've had feature requests to include both s= Service Type (due to tlsrpt) and t= Flags (particularly t=y (testing)).  Since they are attributes of the DNS record and not the signature, I think the proposed dns ptype would be appropriate.

I plan to implement it in dkimpy and expose the values in dkimpy-milter.  I'd like some indication that it'll move forward first.

I think we can adequately define the ptype in the registry.  I don't think we need to have a spec.  For the rest of Ale's draft, I'm not convinced a registry entry is enough to document the proposed usage. (Speaking as alternate DE - msk is the primary though, so this is not an attempt to override him).

msk: What do you think about the idea of approving the new ptype now (so I can file requests for the above, well defined, DKIM result reporting enhancements)?

Scott K