Re: [DNSOP] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Christian Elmerot]

Hi everyone!

I support the publication of this document.

Regards,
Christian

On 2024-01-21 00:23, Tim Wicinski wrote:


All

Peter has integrated feedback from the first working group last call, and
we'd like to do a followup last call.  The diff with the current version 
is here:


https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-dnssec-bootstrapping-05=draft-ietf-dnsop-dnssec-bootstrapping-07=--html
 


This starts a Working Group Last Call for 
draft-ietf-dnsop-dnssec-bootstrapping


Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ 



The Current Intended Status of this document is: Proposed Standards

Please review the draft and offer relevant comments.

For WGLC, we need positive support and constructive comments; lack of 
objection is not enough.

So if you think this draft should be published as an RFC, please say so.

If you feel the document is *not* ready for publication, please speak 
out with your reasons.



This starts a two week Working Group Last Call process, and ends on: 
February 3, 2024


thanks
tim


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


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

Re: [DNSOP] Updated: Compact Denial of Existence

[Christian Elmerot]

On 2023-03-29 15:45, Paul Vixie wrote:



Joe Abley wrote on 2023-03-29 01:56:

Hi Paul,

On Tue, Mar 28, 2023 at 14:51, Paul Vixie

... for perspective, no root name
server has deployed this alternative form of Denial of Existence, ...


Root servers don't do online signing; they serve a pre-signed zone. 
They don't have a motivation to reduce the cost of signature 
generation at response time because that cost is already zero.


oops. duh.

however, olafur's original CF blog post about CDoE also talked about 
packet size (desiring explicitly to fit in 512b). justification was 
about fragmentation avoidance, not CPU time needed to construct 
responses that were smaller than 512b being less than for responses 
that were larger than 512b. i think it's worth asking if this still 
matters, or else, is the current perceived benefit of CDoE simply that 
a NODATA response is easier to construct and contains no wildcard 
disproof?


The original blog does bring up the CPU argument: 
https://blog.cloudflare.com/black-lies/

from the Conclusion:

"We’re proud of our negative answers. They help us keep packet size 
small, and CPU consumption low enough for us to provide DNSSEC for free 
for any domain"


and yes packet size still matters

/ Christian

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

Re: [DNSOP] Updated: Compact Denial of Existence

[Christian Elmerot]

On 2023-03-28 06:41, Shumon Huque wrote:
On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni 
 wrote:


[ Multi-response to four upthread messages. ]

---

On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:

> Thanks for your comments. We've posted an updated draft (-01):
>
>
https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01

[ Copied from today's dns-operations post on the same general topic. ]

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling is compact DoE?

The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would likely require resolvers to
respond differently to queries with the DO bit set (pass them the
NODATA
"truth" along with the NXNAME signal) vs. queries that don't request
validated answers (pass them the inferred NXDOMAIN).

The savings vs. actual by-the-book NSEC responses appear to be a 2x
reduction in the number of signatures to compute (the SOA RRSIG is
presumably easily cached) and a 1.5x reduction in the number of
signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC).

Do the CPU and packet size reductions justify the additional protocol
complexity?


I'll also regurgitate my message here from the dns-operations@ list 
thread:


That's a reasonable question, and perhaps best directed to the 
originators of the scheme at Cloudflare. I don't know if there have 
been any measurement studies or analyses of the cost benefits vs 
by-the-book DNSSEC. There are currently 3 large commercial DNS 
providers that have had it deployed for a while now, so I suspect that 
it is here to stay.


Compact DoE should be seen through the lens of online signing and that 
changes the perspective quite a bit for large providers. That the answer 
is compact is a clear benefit but reducing the amount of work the 
authoritative server has to perform is more important. The server does 
not need to know the contents of the full zone, just that either the 
name or the type in question does not exists. No need to lookup closest 
enclosers etc. Depending on how you've designed the internals of your 
server this reduction in the work you have to perform is likely 
substantial. The proposal for Compact DoE is also of benefit to 
validating resolvers for normal workloads as less signatures have to be 
validated. On the flip side there is the question of a random prefix 
attacks and RFC 8198,  but then again "white-lies" and NSEC3 opt-out was 
kind of the needle to that balloon so this (Compact DoE) is not making 
that situation any worse.


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

Re: [DNSOP] Updated: Compact Denial of Existence

[Christian Elmerot]

On 2023-03-06 03:35, Shumon Huque wrote:

On Sun, Mar 5, 2023 at 12:20 PM Peter Thomassen  wrote:

Hi,

I like this draft. Some thoughts:

1.) Maybe it's worth pointing out that zones using compact denial
SHOULD (MUST?) use NSEC, not NSEC3.


Yes, we could do that. I agree with Geoff's later point that this 
mechanism could in theory use NSEC3 also. But NSEC is simpler, so 
unless someone has a compelling argument to do NSEC3, I'm fine with 
stating that restriction. All known implementations to date use NSEC.



I'm not opposed to adding the restriction though I'm more in favor of 
adding a mention that using NSEC3 increases complexity and processing 
requirements while providing no additional benefit




2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0
(the NULL type). So far it only has meaning for "type covered"
fields in signature records such as SIG(0) (RFC 2931). There
appears to be no collision with usage in the NSEC type bitmap, and
IMHO it appears to be a very natural meta type fit. ("This is
NULL, There Really Is Nothing Underneath.")

If I didn't get the math wrong, it would also save 11 bytes in the
type bitmap (compared to using the lowest available meta type
code, 128), slightly reducing the chance of packet size issues
e.g. when double-signing etc.


I'm a bit allergic to re-using an RR type already designated for 
another purpose. It will require more process work (potentially 
blocking) to revise other documents too. Also, I've been told by a few 
folks who deal with RR type allocation, that if we standardize this 
mechanism, it will have to be a meta-type.


It's certainly true that using a type in the meta-type range will 
increase the size of the type bitmap some. Your calculation sounds 
right. By comparison, the ENT private type used by NS1 presently 
consumes only 3 more octets (window number 255, 1 byte bitmap). This 
all still seems to be in the noise to me, and perhaps not worth 
worrying about. To your comment about double signing, I suspect the 
bigger concern will be about the computational cost to perform 
multiple cryptographic operations rather than a few extra bytes in the 
signature input. (I've proposed algorithm negotiation mechanisms in 
the past to deal with that, but so far the community hasn't been 
receptive).


[One could ponder defining that NXDOMAIN is indicated with a type
bitmap that has *only* the sentinel in it, or even an empty
bitmap. There would be no information loss, as a validator already
knows about the NSEC (+ RRSIG) record's existence simply by
looking at them; the type map adds nothing at all. The idea is
only semi-serious (because of its risk to cause confusion). I'm
bringing it up only to observe that such an empty bitmap would
require no sentinel type at all!]


I briefly had the same thought, but dismissed it. You will get bogged 
down in long, arduous debates about protocol and cryptographic proof 
correctness. By design, the NSEC record needs to prove its own 
existence. By contrast, the NSEC3 record can't, so can have an empty 
type bitmap (see "The NSEC3 Paradox").


3.) Section 2:

        An alternative way to distinguish NXDOMAIN from ENT is to
define the
        synthetic Resource Record type for ENTs instead, as
specified in
        [ENT-SENTINEL], and this has already been deployed in the
field. This
        typically imposes less work on the server since NXDOMAIN
responses
        are a lot more common than ENTs.

It's likely I'm missing something, but I'm not following. Here's
my line of thinking:

Constructing the NODATA response for a name without data records
requires checking whether the name is an ENT. Depending on the
outcome, a bit is set/unset. How can inverting the condition
affect the amount of work on the server?


I probably didn't explain myself clearly here. It isn't inverting the 
condition. But comparing the work needed to set the distinguisher RR 
type in ENT responses versus setting it in NXDOMAIN responses. Since 
the latter are far more common.


4.) Section 4:

        A signed zone at an authoritative server implementing
Compact Answers
        will never return a response with a response code of NXDOMAIN.

Is this meant literally, or only for queries with "do" flag? 



For responses to queries without "do" flag, there is no DoE
processing. To preserve the DoE information, the return code fur
such responses should IMO continue to be NXDOMAIN.


This isn't defined clearly in the original draft or in this one, and 
we should state explicitly what we want it to be. I believe Cloudflare 
already does what you suggest. But NS1 always returns NODATA, 
regardless of the DO flag.


Yes, for queries without the DO-flag we (Cloudflare) return NXDOMAIN 
RCODE when appropriate.



Note that many modern DNS resolver 

Re: [DNSOP] Updated: Compact Denial of Existence

[Christian Elmerot]

On 2023-03-06 05:00, Paul Vixie wrote:



Peter Thomassen wrote on 2023-03-05 14:56:
(Compact NSEC answers prevent zone enumeration just as well, if not 
better.)


that makes it even cooler, and it was already cool. (so long as the 
nxdomain signal is not suppressed as in the cloudflare prototype.)


We intend to follow the specification. The NXDOMAIN type signal is going 
to be deployed before the end of the month


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

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Christian Elmerot]

Coming a bit late to the discussion

On 2021-11-09 22:53, Paul Wouters wrote:

On Tue, 9 Nov 2021, Peter Thomassen wrote:


Let's consider the bootstrapping namespace under _boot.ns1.desec.io.
There would usually be NS/DS records at this name.

However, it should be possible to introduce zone cuts underneath that
name, so operators can control the size and churn of the zones involved
in bootstrapping.  This idea madeit into the draft based on feedback
by John Levine, who pointed out that scalability should be a very
strong priority.

So, there may be additional NS/DS rrsets at com._boot.ns1.desec.io, or
dedyn.io._boot.ns1.desec.io.


But then you are most certainly better of without hashing, because then
you can make a zone for each ._boot.ns1.desec.io. Or when you see
that foo.tld is a generic domain too that is becoming too large, create
a zone for foo.tld._boot.ns1.desec.io.

Whereas with hashes, you just have an unpredictable flat 
._boot.ns1.desec.io zone.



Without hashing involved it would be possible to delegate the 
bootstrapping zone(s) to a live service. Hashing requires 
precomputation, which would detract and delay implementation. It would 
be simple to map example.com on top of example.com._boot.ns1.server.name



In a way, this is just the same as me publishing www.example.com IN 
CDS [...]. No one will ever

ask for the record since there is no NS for www.example.com. So there is
no way for "current deployed software" to do anything wrong. In your
document, you could simply say "no bootraps are allowed under a _boot"
delegation.


I agree. This would be a clarification of CDS/CDNSKEY records since this 
work is already adding additional use of the records beyond 
child->parent signalling.




We disagree. I think the boostrap should only extend the validation path
from a parent zone to the child zone. It should not try to skip a
zonecut in the hierarchy. Yes this causes a delay to deploy, but you
need some delay for security anyway and people won't be deploying 7
delegations deep dnssec bootstraps, or if they do, a 7*1 day delay is
fine.


I agree.


I don't think it helps scaling either because large zones are pretty
trivial these days and all these records are fairly short lived
(days). I doubt we will see 60M of these on 1 nameserver. Can you (or
John) explain what you think is the scale that would no longer work on
a DNSSEC system? And how would that scaling compare to the CPU/disk
required to generate new DNSKEYs for all those new DNSSEC domains,
signing the domains and creating CDNSKEY/CDS records for them?


I'd like to think that any such a large number would be easiest served 
by a "live" non-hashed implementation. Adding delegations is far messier



I think it only helps prevent hitting the theoretical but non-real
FQDN limit of 255, but as I said before, anything that prepends an
_underscore prefix will always have a limit under 255. Not using hashes
would reduce the max length to 128 minues the _boot prefix length versus
255 - 64 (length of base64(sha256)) - _boot prefix length.  So more or
less reduce support of FQDNs from ~200 to ~128. This already requires a
minimum of 3 subdelegations, but since most TLDs dont exceed ~10 to
~20, would require 4+ delegations. At which point you should really be in
part of the DNS tree where you control all parties to provision zones
without needing the bootstrap, that is mainly aimed at Registrar - DNS
Operator limitations. Eg you would be using catalog zones with your
nameservers that would be able to do CDS -> DS because of existing XFR
or NSUPDATE based trust relationships, or would even run on the same
nameserver to completely automated DS updates when hosting both child
and parent.

Anyway, just to reflect, I _do_ like and this idea, but strongly 
prefer no
hashing and not using it to go two delegations deep over unsigned 
parents.


Hashing complicates matters more than the issue it solves. A quick (but 
not exhaustive) check suggests that none of the zones we (Cloudflare) 
would be using this for would be affected. It also complicates 
implementations and debugging for all zones while solving the 
bootstrapping issue for a minute number of zones with long names.


/Christian

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