Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

[Bob Harold]

Allowing the reverse zone method seems ok, but only if it is little extra
work, and does not hold up the rest.  As has been said, users can usually
get a third-party NS record, and the Registrars usually have a manual
method to add the first DS record.  This is a one-time event "per domain",
but once you have your first signed domain, then use an NS in that domain
to bootstrap the rest, so it really becomes a one-time event per
organization.

-- 
Bob Harold


On Wed, Jun 22, 2022 at 8:40 AM Paul Wouters  wrote:

> Unfortunately, the reverse zone is very often out of reach for those who
> use the IP range and trying to do classless reverse delegation (RFC 2317)
> for those who have less than a /24 is even harder to get.
>
> Paul
>
> Sent using a virtual keyboard on a phone
>
> On Jun 21, 2022, at 23:30, rubensk=40nic...@dmarc.ietf.org wrote:
>
> 
>
> On 22 Jun 2022, at 00:07, John Levine  wrote:
>
> It appears that   said:
>
> -=-=-=-=-=-
>
>
> Hi.
>
> During a meeting today of ROW (https://regiops.net), the I-D on CDS
> bootstrapping by using a DNSSEC-signed name at name server
> zone (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/)
> was discussed.
> In that discussion, it was mentioned that the current draft only supports
> out-of-bailiwick name servers; I replied that the
> same principle could be applied to in-bailiwick name server by usage of
> the reverse DNS zones for IPv4 and IPv6.
>
>
> Urrgh. In principle, you can put anything you want in a reverse zone.
> (Send mail to jo...@18.183.57.64.in-addr.arpa. and it'll work.)
>
>
> That's my recollection as well, but as the saying goes, code is law.
> Although in this case only registry/registrar and DNS operator are required
> to interoperate for the bootstrapping process.
>
> In practice, I doubt that enough reverse zones are signed or that the
> provisoning crudware that people use for reverse zones would work
> often enough to be worth trying to do this. I did some surveys of
> zones and found that in-bailiwick NS are quite uncommon, only a few
> percent of the ones in large gTLDs.
>
>
> I don't expect the IP space used for DNS servers to be managed thru an
> IPAM system of sorts. But if one is used, it's unlikely they provision a
> zone-cut as required in the draft.
>
> The prevalence among the overall DNS system is indeed low, but I wonder
> what % this represents within services that allow all of DNSSEC, CDS
> Bootstrapping and in-bailiwick DNS servers, like Business and Enterprise
> plans in Cloudflare:
> https://developers.cloudflare.com/dns/additional-options/custom-nameservers/
>  .
>
>
> Or if supporting this type of DNS servers can help the adoption of this
> draft for the 99.9% use case of out-of-bailiwick servers. If not, we could
> be adding a new piece to the DNS Camel...
>
>
>
> Rubens
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

[Paul Wouters]

Unfortunately, the reverse zone is very often out of reach for those who use the IP range and trying to do classless reverse delegation (RFC 2317) for those who have less than a /24 is even harder to get.Paul Sent using a virtual keyboard on a phoneOn Jun 21, 2022, at 23:30, rubensk=40nic...@dmarc.ietf.org wrote:On 22 Jun 2022, at 00:07, John Levine  wrote:It appears that   said:-=-=-=-=-=-Hi.During a meeting today of ROW (https://regiops.net), the I-D on CDS bootstrapping by using a DNSSEC-signed name at name serverzone (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/) was discussed.In that discussion, it was mentioned that the current draft only supports out-of-bailiwick name servers; I replied that thesame principle could be applied to in-bailiwick name server by usage of the reverse DNS zones for IPv4 and IPv6.Urrgh. In principle, you can put anything you want in a reverse zone.(Send mail to jo...@18.183.57.64.in-addr.arpa. and it'll work.)That's my recollection as well, but as the saying goes, code is law. Although in this case only registry/registrar and DNS operator are required to interoperate for the bootstrapping process. In practice, I doubt that enough reverse zones are signed or that theprovisoning crudware that people use for reverse zones would workoften enough to be worth trying to do this. I did some surveys of zones and found that in-bailiwick NS are quite uncommon, only a fewpercent of the ones in large gTLDs.I don't expect the IP space used for DNS servers to be managed thru an IPAM system of sorts. But if one is used, it's unlikely they provision a zone-cut as required in the draft. The prevalence among the overall DNS system is indeed low, but I wonder what % this represents within services that allow all of DNSSEC, CDS Bootstrapping and in-bailiwick DNS servers, like Business and Enterprise plans in Cloudflare: https://developers.cloudflare.com/dns/additional-options/custom-nameservers/ .Or if supporting this type of DNS servers can help the adoption of this draft for the 99.9% use case of out-of-bailiwick servers. If not, we could be adding a new piece to the DNS Camel... Rubens___DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop

signature.asc
Description: Binary data
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

[Peter Thomassen]

On 6/22/22 12:39, Peter Thomassen wrote:

So I agree that strictly "replacing" Section 3 may be too much, but we should strongly discourage 
its use. Perhaps its enough to state that the draft "obsoletes" (or "deprecates"?) RFC 
8078 Section 3?


I was thinking to write something like:

OLD:
  This document updates [@!RFC8078] and replaces its Section 3 with 
(#bootstrapping) of this document.

NEW:
  This document obsoletes Section 3 of [@!RFC8078] in favor of (#bootstrapping) 
of this document.


In doing so, I remember the Obsoletes: RFC header. Looking into it, it seems to 
apply to an RFC as a whole (not only to a Section, as is the case here).

I started considering what's the difference between obsoleting RFC 8078 Section 
3, and the RFC as a whole. The differences would be:

- Besides Section 3 (which we want to obsolete), RFC 8078 has normative 
language in Section 4 (Disabling DNSSEC with Null CDS record), and in Section 5 
(Security Considerations). I guess we don't want to obsolete Section 4. But if 
the whole RFC was obsoleted, the relevant aspects of Section 5 could be 
migrated to the new draft.

- RFC 8078 elevates RFC 7344 from Informational to Standards Track. Would that be 
"undone" by obsoleting RFC 8078? (I guess not?)

- Similarly, RFC 8078 registers the "Delete DS" algorithm. This continues to be 
needed. Would it collide with obsoleting the RFC?


I can imagine that having all bootstrapping-related stuff in one document (and 
obsoleting the former), that would make things easier to digest for readers. On 
the other hand, I don't know how the above situation would be best handled. 
Input from more experienced IETFers is appreciated.

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

[Peter Thomassen]

Libor,

On 6/19/22 16:41, libor.peltan wrote:

However, I'd like to discuss if it really should *replace* RFC8078, Section 3 
whatsoever.

Sure, it's definitely more secure than the rather quirky Accept after 
Delay/Checks/Challenge procedures, but it adds also more limitations, as 
described in section 3.4 anyway.

I would prefer if both options remained standardized in parallel, so that 
anyone can choose between more secure, or more universal way of DNSSEC 
bootstrapping.

Alternatively, we may say that the RFC8078 bootstrapping is deprecated, but 
still, it doesn't mean that we replace it.


I understand the concern, and I believe that at least those parents which already do 
implement unauthenticated RFC 8078 bootstrapping (e.g. "accept after delay") 
should not immediately run into a situation where the spec is violated. Some parents may 
also have other reasons for supporting a less secure method.

So I agree that strictly "replacing" Section 3 may be too much, but we should strongly discourage 
its use. Perhaps its enough to state that the draft "obsoletes" (or "deprecates"?) RFC 
8078 Section 3?

If we do so, the current draft still has Section 3, which says:

Child DNS Operators and Parental Agents who wish to use CDS/CDNSKEY records for 
DNSSEC bootstrapping SHOULD support the authentication protocol described in 
this section.


... so this already leave some wiggle room to do things differently.

Any preferences on the wording?

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

[Peter Thomassen]

Hi John,

On 6/19/22 19:30, John Levine wrote:

It appears that libor.peltan   said:

Alternatively, we may say that the RFC8078 bootstrapping is deprecated,
but still, it doesn't mean that we replace it.


That seems reasonable.  Does anyone actually do the current TOFU-ish bootstrap?


Yes: https://github.com/oskar456/cds-updates


Do no longer suggest NSEC-walking Signaling Domains. (It does not
work well due to the Signaling Type prefix. What's more, it's unclear
who would do this: Parents know there delegations and can do a
targeted scan; others are not interested.)


There's still a reference to NSEC walking in the penultimate paragraph in sec 
3.3.


Yes; the paragraph there names a precaution that needs to be considered when 
doing in NSEC walk. I think it should stay, even when NSEC walking is not 
suggested as a discovery method.


I think it's still worth a suggestion in the trigger section that
operators allow AXFR of the signal information. While probing is just
as fast if there are only a few domains delegated to a NS, there are
name servers that have hundreds of thousands or millions of delegated
names.


How about the following, inserted between the 2nd and the 3rd bullet in Section 
3.3:

   *  The Parental Agent encounters a Signaling Record during an NSEC
  walk or upon zone transfer of a Signaling Zone;

Thanks,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

[Brian Dickson]

On Tue, Jun 21, 2022 at 7:51 PM  wrote:

>
> Hi.
>
> During a meeting today of ROW (https://regiops.net), the I-D on CDS
> bootstrapping by using a DNSSEC-signed name at name server zone (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/)
> was discussed.
> In that discussion, it was mentioned that the current draft only supports
> out-of-bailiwick name servers; I replied that the same principle could be
> applied to in-bailiwick name server by usage of the reverse DNS zones for
> IPv4 and IPv6.
>
>
Even if that is true, why bother?

The whole point of the bootstrap mechanism is to onboard the *initial* DS
record for a particular domain securely.
Once the initial DS is present, there is no further need for bootstrap.
For a single domain, the only purpose of doing what you propose for a
"vanity" name server name, is to accomplish a one-shot action.

The use of some (any) third party DNS operator whose infrastructure zone(s)
is/are signed, for the purposes of doing the bootstrap, followed by
migrating the signed zone to another set of name servers securely (e.g. via
the multi-signer mechanisms, or via setting the zone up as a signed AXFR
from a hidden master), would achieve the same result without any new
proposals or implementations required. That would be two steps instead of
one, but only at the time of the initial DS. Once that DS is onboard at the
parent domain, the bootstrap operator is no longer involved.

Even if procuring the services from a DNS operator costs a small amount for
the time it takes to do the bootstrap and migration, knowing that it works
and is secure, and does not require any work on implementing something that
is never going to be reused, would seem to be a small price to pay.

You may even have friends operating their own signed zones, via which you
can bootstrap this way for free.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop