[DNSOP] Domain Verification Techniques using DNS
elliott.brown@num.uk Mon, 22 May 2023 21:49 UTC
Return-Path: <elliott.brown@num.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841E3C15107F for <dnsop@ietfa.amsl.com>; Mon, 22 May 2023 14:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=num.uk
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 HVHQl6KR4ArI for <dnsop@ietfa.amsl.com>; Mon, 22 May 2023 14:49:33 -0700 (PDT)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 C9346C14CE55 for <dnsop@ietf.org>; Mon, 22 May 2023 14:49:33 -0700 (PDT)
Date: Mon, 22 May 2023 21:49:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=num.uk; s=protonmail2; t=1684792171; x=1685051371; bh=Q8zgyx7dMmvTLiFvyUYKjPNULvYEge7rOerWrV8ctsk=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=IPJVbYJNmoRv4m8oC81MvQwUgM/hg3JRUDiR5pZ8H0CUygGwPpPoNILtBwX+IatH6 jDaG+i4K7zWuZoeSLNzi3gyY42NYDUlmOu6GkK3k1/bgj7fNgWXX27OCihq7mv/zf3 u3UMCAjm3SUkmD1dsPpirOAPDt3dn6xNwjfLCHC+uamxZEgE05WnkAGywVhH6Owp/P IKDhGOTrU+rnNmay6pMwSpEO+7M+Jb3Bm7T8TYidWRbxEboBn2tg3O7lWymb1e0Xch 8hKZ65rRrccaqTgNtSkBnJZHq5m3yWpNBWuE6UbVW+2lLdUAxeJZzWCdXjaKSeJR7i JCHY1WTt4WHYQ==
To: "dnsop@ietf.org" <dnsop@ietf.org>, "draft-ietf-dnsop-domain-verification-techniques.all@ietf.org" <draft-ietf-dnsop-domain-verification-techniques.all@ietf.org>
From: elliott.brown@num.uk
Message-ID: <lFAtHx4AM5tH7o5UTTgzfKqfZpLer5Gxu3je9lItz7SQ04nBWpv2dRiQv5Pwg9cuX9s_Hv-Yv7x7j8LYddrWl6Z3cPJLidyyETU2SDndbKc=@num.uk>
Feedback-ID: 51893081:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UNf2xUotkVt-dO_57AvnkqR55dA>
Subject: [DNSOP] Domain Verification Techniques using DNS
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2023 21:49:39 -0000
Dear DNSOP WG, My company has developed a domain verification technique using DNS, it fits the abstract of draft-ietf-dnsop-domain-verification-techniques. I am writing to ask the WG's opinion on whether our technique is within the scope of the current draft and if so, whether it should be considered for inclusion. Our technique is outlined here: https://www.domainverification.org You can see an example DNS TXT record by using the following dig command: dig 4i7ozur385y5nsqoo0mg0mxv6t9333s2rarxrtvlpag1gsk8pg._dv.dvexample.com TXT Although our method fits the draft's title and abstract, it is quite different to the method detailed in the best current practice of the draft. It is similar in the following ways: - Data is stored in a DNS TXT record - Data is stored at a subdomain of the target domain, rather than stored at the apex of the zone - The record includes an expiry date for the verification It differs in the following ways: - Each DNS TXT record does not provide verification for an individual service provider, each record enables verification for an authorised party (domain owner, SEO agency, etc) - Authorised parties are identified by email or telephone number (we call these verifiable identifiers) - A hash of the verifiable identifier is used as a DNS label in the DNS name of the TXT record, so that authorised parties are not easily discoverable - The TXT record includes permissions for the authorised party, the scope can be as narrow as a particular service provider – e.g. "search.google.com" – similar to the current BCP draft; permissions can also be much broader, e.g. by category (like "seo") or permissions that enable the authorised party to verify the domain with any service provider – For an authorised party to verify the domain with a service provider, they must provide their verifiable identifier (email or phone) to the service provider and then demonstrate ownership of that verifiable identifier, using standard techniques (e.g. clicking an email verifications link or receiving an SMS verification code). - The current draft ensures that the string used in the DNS TXT is not reproducible across service providers; our method has the opposite objective – to ensure that the string is reproducible across service providers. It is our ultimate goal for these records to be created by domain registrars upon domain registration (with registrant opt-in) to provide their customers with seamless onboarding when adding their domain to service providers. I am interested in the views of the WG on whether this technique could be included in the draft, and if not, whether the scope of the draft should be narrowed to be BCP for providing verification on a service-provider basis. In accordance with BCP79, I am disclosing the following patents which relate to our technology: Patents related to storing a hash of a verifiable identifier (email, phone, etc) in DNS for the purposes of verification: - UK granted patent: https://patents.google.com/patent/GB2585353B - US pending patent: https://patents.google.com/patent/US20220141172A1 Patents related to storing a hash of a verifiable identifier as a DNS label for the purposes of verification: - UK pending and unpublished patent: https://patents.google.com/patent/GB202216304D0 - US patent to be filed. As I understand it, this disclosure is a condition of contributing to the discussion. For the avoidance of doubt: I am not asserting any rights over the methods discussed in the current draft at all – only our new method being proposed for inclusion. We are still working on licensing but creating Domain Verification records will always be free for domain registrants or registrars, service providers will require a license to verify domains using the protocol. This is my first time contributing to the IETF, please forgive me for any accidental transgressions – I am here to contribute as productively as possible. Best regards, Elliott Brown CEO NUM Technology Ltd
- [DNSOP] Domain Verification Techniques using DNS elliott.brown
- Re: [DNSOP] Domain Verification Techniques using … Paul Wouters
- Re: [DNSOP] Domain Verification Techniques using … elliott.brown
- Re: [DNSOP] Domain Verification Techniques using … Shivan Kaul Sahib
- Re: [DNSOP] Domain Verification Techniques using … elliott.brown