------- Original Message -------
On Tuesday, May 23rd, 2023 at 21:22, Paul Wouters
<paul.wouters=40aiven...@dmarc.ietf.org> wrote:
> On Mon, May 22, 2023 at 5:49 PM <elliott.br...@num.uk> wrote:
>
>> 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.
>
> Thanks for reaching out to DNSOP.
>
>> 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.
>
> Indeed. While the current draft's methods could be fully automated, your
> method specifically calls out for verification via
> a phone number or email address which more or less assumes a human operator.
The current draft's methods (Service Provider: instructing a domain owner to
create a DNS TXT record; Domain Owner: creating the DNS TXT record) are
automated on the service provider side, but in my experience it is very rarely
automated on the domain owner side.
On the domain owner side, there is a human operator following the instructions
and creating the DNS TXT record.
Our method does involve an extra step of verification (e.g. verifying an email
address), but in practice this extra step has often already been completed when
the domain owner set up a user account with the service provider.
> It therefor works indirectly and all the
> "verification" parts are out of scope handled inside the SMS / email / phone
> call messages that would be required.
>
> As such, I do not think it belings in the current draft, but should be
> submitted as a separate draft.
I am very open to submitting it as a separate draft and I am interested in the
thoughts of the WG around whether the abstract of the current draft (and
possibly title) should be narrowed to make it clear the domain verification
techniques included in the current draft are for one-time only / service
provider specific domain verification.
>> 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 wonder if that goal is achievable. In a way, the SOA record also contains a
> contact email for the domain and is basically no longer used by anyone.
The zonemaster is not the domain owner in the vast majority of cases. I think
there's a variety of reasons this email address is no longer used by anyone,
including: it is in plaintext so easily discoverable; there are better ways to
contact the administrator of a DNS zone.
> Hashing the contact info is only a very wea protection, as we have seen with
> people bruteforcing NSEC3 hash chains.
We hash the email/phone and store it in the DNS label itself so that it cannot
be easily harvested by spammers. We don't use hashing for any kind of
protection against a threat.
> And also, I think
> these type of records will also go stale and then not very useful.
These records will naturally be removed when a domain expires or changes
registrant, so I think the risk of stale records for a domain owner is quite
low. Records for third parties can have expiry dates, so I think this should
avoid stale records for third parties.
> And so another fallback mechanism will be required anyway. So perhaps using
> that fallback to start with would be better. (I guess you could add some
> application code to verify email addresses on signup requests, but I doubt
> this is all going to me that much easier than "take this DNS record and tell
> your IT to publish it for a few days" that the current draft uses.
I would argue that the service providers that verify the most domains already
verify email addresses on sign-up. And so, once the Domain Verification
Protocol record is in place – whether it's been setup by the domain registrant,
registrar or a previous service provider – domain verification becomes
"automatic" and significantly easier than "take this DNS record and tell your
IT to publish it for a few days".
I have provided an explanation of the process below:
1. Bob signs up with DomainRegistrar.com using emailbob@gmail.comand registers
the available domain[example.com](http://example.com/)
2. DomainRegistrar.com configures a Domain Verification record by
hashing...@gmail.com(simplified hash: 123ABC) and stores this record at
123ABC._[dv.example.com](http://dv.example.com/)
3. Bob signs up with Service Provider 1 using his emailbob@gmail.comand
verifies his email. He attempts to add the
domain[example.com](http://example.com/)to the service provider
4. Service Provider 1 runs a Domain Verification check for the
domain[example.com](http://example.com/)by hashing Bob’s email
(b...@gmail.com-> 123ABC) and using this in a dns query:
dig 123ABC._[dv.example.com](http://dv.example.com/)
5. If a valid record is returned then Domain Verification is successful.
6. Bob can claim[example.com](http://example.com/)on multiple service providers
using the same steps above, without adding any DNS TXT records.
In the example above, the Registrar creates the record but this record could
also be created by Bob himself under instruction from the first Service
Provider he uses. Subsequent Service Providers could re-use the same record.
>> 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
>
> I believe that RFC 7929 - DNS-Based Authentication of Named Entities, of
> which I am the author, constitutes prior art for this patent.
>
>> - 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
>
> I believe both the aforementioned RFC 7929, as well as RFC 7671: The
> DNS-Based Authentication of Named Entities,
> constitute prior art for this patent.
Thanks and noted.
>> - 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.
>
> Note that the IETF strongly leans towards only using patented technology if
> that technology is licensed using an irrevocable, perpetual, royalty free and
> non-discriminatory license. Your indication that service providers cannot use
> this technology without paying royalties would not be compatible with that
> goal.
I am new to this so my apologies if I've misinterpreted something, but In
RFC8179 I noted the following, particularly (b):
"Since IPR disclosures will be used by IETF working groups during their
evaluation of alternative technical solutions, it is helpful if an IPR
disclosure includes information about licensing of the IPR in case Implementing
Technologies require a license. Specifically, it is helpful to indicate
whether, upon approval by the IESG for publication as an RFC of the relevant
IETF specification(s), all persons will be able to obtain the right to
implement, use, distribute, and exercise other rights with respect to an
Implementing Technology a) under a royalty-free and otherwise reasonable and
non-discriminatory license, or b) under a license that contains reasonable and
non-discriminatory terms and conditions, including a reasonable royalty or
other payment, or c) without the need to obtain a license from the IPR holder
(e.g., a covenant not to sue with or without defensive suspension, as described
in Section 7)."
As per (b), our technology will be offered "under a license that contains
reasonable and non-discriminatory terms and conditions, including a reasonable
royalty or other payment".
I understand the IETF might lean towards non-proprietary technology or
proprietary technology that is freely-licensed.
I suppose my question, and the reason for contacting the IETF boils down to
whether or not the draft (with it's current title and abstract) is aiming to be
complete in it's consideration of "Domain Verification Techniques using DNS".
If so, I would argue our method should be considered for inclusion.
If instead it is intended to standardise the method widely used over the last
10-15 years then I wonder whether the draft and abstract should be narrowed to
make that clear.
>> 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.
>
> Welcome and thanks for coming to the IETF to make the internet work better :)
Thank for the time and consideration you've given to this.
> Paul
Best regards,
Elliott
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
