Subject: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

From: Shivan Kaul Sahib <[email-masked]>
Date: Thu, 10 Jun 2021 16:26:44 -0700

Hi all, Shumon and I have been working on an early draft that surveys
current DNS domain verification techniques. Depending on how it goes, we
hope to eventually explore if we can come up with some best practices.

We plan to ask for time to present it at the IETF 111 DNSOP meeting. In
the meantime, please let us know if this is of interest!

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Jun 10, 2021 at 9:27 AM
Subject: New Version Notification for
draft-sahib-domain-verification-techniques-02.txt
To: Shivan Sahib <[email-masked]>, Shumon Huque <[email-masked]

A new version of I-D, draft-sahib-domain-verification-techniques-02.txt
has been successfully submitted by Shivan Sahib and posted to the
IETF repository.

Name:           draft-sahib-domain-verification-techniques
Revision:       02
Title:          Survey of Domain Verification Techniques using DNS
Document date:  2021-06-10
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.txt
Status:
https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
Html:
https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-sahib-domain-verification-techniques
Diff:
https://www.ietf.org/rfcdiff?url2=draft-sahib-domain-verification-techniques-02

Abstract:
   Many services on the Internet need to verify ownership or control of
   domains in the Domain Name System (DNS) [RFC1034] [RFC1035].  This
   verification often relies on adding or editing DNS records within the
   domain.  This document surveys various techniques in wide use today,
   the pros and cons of each, and possible improvements.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ShivanKaul/draft-sahib-domain-verification-
   techniques.

The IETF Secretariat

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Jun 2021 22:21:27 -0400

Thanks for doing this work!

I’ve read this a while ago when you gave me a preview and this is important work that you should present at the next IETF and hopefully we can adopt and put though
reasonably fast - the market needs our guidance.

(For those who think there is no problem, dig txt cnn.com)

Paul

Sent using a virtual keyboard on a phone

> On Jun 10, 2021, at 19:27, Shivan Kaul Sahib <[email-masked]> wrote:
> 
> 
> Hi all, Shumon and I have been working on an early draft that surveys current DNS domain verification techniques. Depending on how it goes, we hope to eventually explore if we can come up with some best practices.
> 
> We plan to ask for time to present it at the IETF 111 DNSOP meeting. In the meantime, please let us know if this is of interest! 
> 
> Subject: New Version Notification for draft-sahib-domain-verification-techniques-02.txt
> To: Shivan Sahib <[email-masked]>, Shumon Huque <[email-masked]>
> 
> 
> 
> URL:            https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
> Html:           https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-sahib-domain-verification-techniques
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-sahib-domain-verification-techniques-02
> 
> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Jun 2021 10:19:02 -0400

Paul

We've been talking with Shivan and Shumon about the document, and I feel I
already asked them to be prepared to present at the next meeting on this.

I also suggested that they should also with the Application Area, for
feedback.

tim

On Thu, Jun 10, 2021 at 10:22 PM Paul Wouters <[email-masked]> wrote:

> I’ve read this a while ago when you gave me a preview and this is
> important work that you should present at the next IETF and hopefully we
> can adopt and put though

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Jun 2021 18:29:20 +0100

> hope to eventually explore if we can come up with some best practices.

This looks like a useful document!

One thing that's operationally awkward for me is how some providers do
one-time verifications, and others re-validate periodically. I suppose
there is another distinction between static re-validation done by (e.g.)
Google, and dynamic renewal as required by ACME.

Best practice for providers ought to be to document re-validation
requirements very prominently and clearly. (In my experience the common
ones are not too bad but occasionally we have to guess, so maybe a service
stops working for mysterious reasons 30 or 90 days later.)

It's kind of ugly the way static verification records clutter
up the place, but on the other hand it is a useful protection against
subdomain takeover attacks. So I hope that this document will have a good
survey of the security considerations.

Here's an overview of subdomain takeovers
https://www.csoonline.com/article/3601007/how-to-avoid-subdomain-takeover-in-azure-environments.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Southeast Fitzroy: Northerly or northeasterly 5 to 7, occasionally
gale 8 at first. Moderate or rough. Fair. Good.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 13 Jun 2021 18:25:59 +0200

On Thu, Jun 10, 2021 at 04:26:44PM -0700,
 Shivan Kaul Sahib <[email-masked]> wrote 
 a message of 164 lines which said:

> Hi all, Shumon and I have been working on an early draft that
> surveys current DNS domain verification techniques. Depending on how
> it goes, we hope to eventually explore if we can come up with some
> best practices.

Section 4.1: you do not mention a recommended name for the
subdomain. Should we suggest a name starting with an underscore, to
limit the risk of collisions and to emphasize it is not a host name?
(On the other hand, some users may have a limited DNS provisioning
interface, which enforces a LDH restriction.)

Section 5: should we also add that, specially if the zone is not
signed, multi-vantage-point checking is recommended (Let's Encrypt
already does it)?

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Tue, 15 Jun 2021 09:26:58 -0700

Hi Stephane!

> interface, which enforces a LDH restriction.)

This draft is intended to be a survey of existing techniques and broad
recommendations that can be derived from the survey (hence we only discuss
the value of targeted domain verification). Our thought was that we should
leave concrete best practices for a later draft.

> signed, multi-vantage-point checking is recommended (Let's Encrypt

Interesting, I raised an issue here:
https://github.com/ShivanKaul/draft-sahib-domain-verification-techniques/issues/18

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Tue, 15 Jun 2021 09:28:35 -0700

Thanks Tony!

> stops working for mysterious reasons 30 or 90 days later.)

Agreed! We currently have some text in section 4.3
<https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.html#name-time-bound-checking>
around time-bound checking but we should add this. I raised an issue
<https://github.com/ShivanKaul/draft-sahib-domain-verification-techniques/issues/19>
.

> https://www.csoonline.com/article/3601007/how-to-avoid-subdomain-takeover-in-azure-environments.html

My understanding of subdomain takeovers is that it happens because of
dangling records. Would you mind expanding on this?

---

From: Shumon Huque <[email-masked]>
Date: Tue, 15 Jun 2021 12:37:45 -0400

> leave concrete best practices for a later draft.

Shivan: a survey is the initial goal. But my thinking was: assuming there
is interest in the draft first (which there appears to be), we could work
on recommendations in a later iteration of this draft (and not a new one,
although I could be persuaded).

Yes, Stephane, we were envisioning recommending an underscore label. Of
course, that leads to how to avoid collisions in that space, and whether we
need to establish a registry of application service names.

> https://github.com/ShivanKaul/draft-sahib-domain-verification-techniques/issues/18

Yeah, that's a good idea.

Shumon

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 15 Jun 2021 12:46:18 -0400

> need to establish a registry of application service names.

You mean, a different registry than this one
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

tim

---

From: Shumon Huque <[email-masked]>
Date: Tue, 15 Jun 2021 12:50:25 -0400

> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

Tim - yes, I think this would be a bit different. The above is for IETF
defined protocols. This one (if we think it's a good idea) would have to
encompass arbitrary Internet application services, many that could be
proprietary services of companies.

Shumon.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 15 Jun 2021 13:10:31 -0400

> proprietary services of companies.
Ok, I can see that.

The survey you're doing will help with that.

tim

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2021 13:51:06 -0400

It appears that Shumon Huque  <[email-masked]> said:
>defined protocols. 

No, it's for anyone with a plausible application. It already includes
_validation-contactemail and _validation-contactphone from the CAB.

R's,
John

---

From: Shumon Huque <[email-masked]>
Date: Tue, 15 Jun 2021 14:58:55 -0400

> _validation-contactemail and _validation-contactphone from the CAB.

Ah, thanks for correcting me ..

In that case, we could use this one.

Shumon.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Jun 2021 15:02:32 -0400 (EDT)

On Tue, 15 Jun 2021, Shumon Huque wrote:

>             Yes, Stephane, we were envisioning recommending an underscore label. Of course, that leads to how to avoid collisions in that
>             space, and whether we need to establish a registry of application service names.
> 
> 
> Tim - yes, I think this would be a bit different. The above is for IETF defined protocols. This one (if we think it's a good idea) would have to encompass
> arbitrary Internet application services, many that could be proprietary services of companies.

<hat> I am one of the underscored-globally-scoped-dns-node-names Experts

The _underscore registry is "Expert Review" only, meaning it is not only
used for IETF defined protocols. It's only goal is to be a place where
people can register a unique name to avoid name collision between
different protocols/applications using it.

As such, it would be fine for this draft to commend registration there.
It could also start its own _underscore registry.

</hat>

Of course, if people ensure the names they use are somehow linked to
their product of business name, it becomes fairly unique to begin
with, and a registry might not be needed. Like people shouldn't be
using _registration or _website_auth or something generic like that.
My personal preference would be to focus stronger on generating proper
names (and embedded expire / recurring check within the name) that
would ensure no central registry of any kind would be needed.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Jun 2021 15:05:57 -0400 (EDT)

>>       _validation-contactemail and _validation-contactphone from the CAB.

I would rephrase this as "for anyone who foolishly made a really bad
generic name in the past and is now stuck with it and wants to avoid
anyone else picking the same foolish name".

> In that case, we could use this one.

Please try and recommend stronger naming guidelines so that a registry
is not _needed_

Paul

---

From: Shumon Huque <[email-masked]>
Date: Tue, 15 Jun 2021 15:07:46 -0400

> Please try and recommend stronger naming guidelines so that a registry

Ok, I'm fine with punting on the registry idea for now ..

Shumon.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Jun 2021 14:23:57 -0700

>    the pros and cons of each, and possible improvements.

Adding my thoughts: well written and highly useful document.  Should
definitely be an informational document.
-- 
Wes Hardaker
USC/ISI

---

From: Brian Dickson <[email-masked]>
Date: Fri, 25 Jun 2021 19:14:24 -0700

On Tue, Jun 15, 2021 at 12:03 PM Paul Wouters <[email-masked]> wrote:

> >             Yes, Stephane, we were envisioning recommending an
> underscore label. Of course, that leads to how to avoid collisions in that
> encompass

The only real issue I see is managing the underscore namespace as a flat
namespace.
Given that DNS itself was engineered in part to be hierarchical as a
solution to the scaling problems of hosts.txt,
maybe using an underscore scheme that is hierarchical would solve some/many
of these problems?
(Perhaps carved out with its own underscore suffix.)

The analogy that comes to mind is the MIB tree, with the public branch
(.1.3.6.1.2.1) and the enterprise (.1.3.6.1.4.1).
The enterprise portion of the tree has a very large number of nodes.
Using numeric values rather than names avoids name collisions.

These are just suggestions though.

 YMMV.
Brian