Subject: [DNSOP] DNSSEC Strict Mode

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 10:08:11 -0500

Inspired by some recent discussions here (and at DNS-OARC), and hastened by
the draft cut-off, I present for your consideration "DNSSEC Strict Mode":
https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00

Abstract:
Currently, the DNSSEC security of a zone is limited by the strength of its
weakest signature algorithm.  DNSSEC Strict Mode makes zones as secure as
their strongest algorithm instead.

The draft has a long discussion about why and how, but the core normative
text is just three sentences:

The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags field.
If this flag is set, all records in the zone MUST be signed correctly under
this key's specified Algorithm.  A validator that receives a Strict Mode
DNSKEY with a supported Algorithm SHOULD reject as Bogus any RRSet that
lacks a valid RRSIG with this Algorithm.

--Ben Schwartz

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 23 Feb 2021 16:17:13 +0100

Hi Ben,

could you please briefly summarize how this relates to last paragraph of 
https://tools.ietf.org/html/rfc4035#section-2.2 ?

The way how I understand it, each DNSKEY already must be treated as the 
proposed "strict" mode, thus this proposal is completely useless.

Thanks,

Libor

Dne 23. 02. 21 v 16:08 Ben Schwartz napsal(a):
> Inspired by some recent discussions here (and at DNS-OARC), and 
> hastened by the draft cut-off, I present for your consideration 
> "DNSSEC Strict Mode": 
> <https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00> 
>
>
> Abstract:
> Currently, the DNSSEC security of a zone is limited by the strength of 
> its weakest signature algorithm.  DNSSEC Strict Mode makes zones as 
> secure as their strongest algorithm instead.
>
> The draft has a long discussion about why and how, but the core 
> normative text is just three sentences:
>
> The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags 
> field.  If this flag is set, all records in the zone MUST be 
> signed correctly under this key's specified Algorithm.  A validator 
> that receives a Strict Mode DNSKEY with a supported Algorithm 
> SHOULD reject as Bogus any RRSet that lacks a valid RRSIG with 
> this Algorithm.
>
> --Ben Schwartz
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 10:26:51 -0500

Libor,

That's what I thought too.  See RFC 6840 Section 5.11:

> The last paragraph of Section 2.2 of [RFC4035] includes rules
> describing which algorithms must be used to sign a zone.  Since these
> rules have been confusing, they are restated using different language
> here:
...
>> A signed zone MUST include a DNSKEY for each algorithm present in
>> the zone's DS RRset and expected trust anchors for the zone.  The
>> zone MUST also be signed with each algorithm (though not each key)
>> present in the DNSKEY RRset.
...
> This requirement applies to servers, not validators.  Validators
> SHOULD accept any single valid path.

RFC 6840 tells validators to be lax, so if we want to enforce this rule
then we need a signal (or we need to update RFC 6840).

On Tue, Feb 23, 2021 at 10:17 AM libor.peltan <[email-masked]> wrote:

> Inspired by some recent discussions here (and at DNS-OARC), and hastened
> by the draft cut-off, I present for your consideration "DNSSEC Strict
> Mode":
> DNSOP mailing [email-masked]://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 23 Feb 2021 16:36:06 +0100

Hi Ben,

Yes, RFC 6840 tells validators to be lax.

However, it also requires exactly the same as RFC 4035 from signers.

As I understand it, the requirement is rephrased, but entirely 
equivalent, and there is a MUST.

So, is your proposal only about a bit in DNSKEY record, signalling "this 
zone is RFC compliant"?

If so, I have no more questions, but you should maybe state this clearly ;)

Cheers,

Libor

Dne 23. 02. 21 v 16:26 Ben Schwartz napsal(a):
> RFC 6840 tells validators to be lax, so if we want to enforce this 
> rule then we need a signal (or we need to update RFC 6840).
>
> On Tue, Feb 23, 2021 at 10:17 AM libor.peltan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Ben,
>
>     could you please briefly summarize how this relates to last
>     paragraph of https://tools.ietf.org/html/rfc4035#section-2.2
>     <https://tools.ietf.org/html/rfc4035#section-2.2> ?
>
>     The way how I understand it, each DNSKEY already must be treated
>     as the proposed "strict" mode, thus this proposal is completely
>     useless.
>
>     Thanks,
>
>     Libor
>
>>     Currently, the DNSSEC security of a zone is limited by the
>>     strength of its weakest signature algorithm. DNSSEC Strict Mode
>>     makes zones as secure as their strongest algorithm instead.
>>
>>     signed correctly under this key's specified Algorithm.  A
>>     validator that receives a Strict Mode DNSKEY with a supported
>>     Algorithm SHOULD reject as Bogus any RRSet that lacks a valid
>>     RRSIG with this Algorithm.
>>
>>     --Ben Schwartz
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/dnsop  <https://www.ietf.org/mailman/listinfo/dnsop>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2021 10:40:00 -0500 (EST)

On Tue, 23 Feb 2021, Ben Schwartz wrote:

> Inspired by some recent discussions here (and at DNS-OARC), and hastened by the draft cut-off, I present for your consideration "DNSSEC Strict
> Mode": https://datatracker.ietf.org/doc/html/draft-schwartz-dnsop-dnssec-strict-mode-00
> Abstract:
> Currently, the DNSSEC security of a zone is limited by the strength of its weakest signature algorithm.  DNSSEC Strict Mode makes zones as secure as their strongest
> algorithm instead.

But why is that a problem? I assume that:

1) A regular zone has 1 algorithm
2) If there are two algorithms, the zone is moving from one to another
3) Accepting the outgoing algorithm during the migration is basically harmless

Am I making a wrong assumption here?

Also, we went out of our way to avoid specifying which algorithm is
"weaker" or "stronger" for good reasons, as people will disagree on
this, but the code path has to put something in. Better not to have
this assumption baked in at all. Case in point, harden-algo-downgrade: yes
in unbound deems ecdsap256sha256 to be a downgrade from rsasha256.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Feb 2021 15:40:13 +0000

What is the purpose of this flag? Why wouldn't a zone owner who has such a strong desire for using that one algorithm just sign with that algorithm?

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 10:53:34 -0500

On Tue, Feb 23, 2021 at 10:36 AM libor.peltan <[email-masked]> wrote:

> As I understand it, the requirement is rephrased, but entirely equivalent,
> and there is a MUST.
>
That's a fair characterization, but of course the point of the draft is to
change the behavior of validators.  Also, we need to be very clear about
which RFC requirements are being described here.

> If so, I have no more questions, but you should maybe state this clearly ;)
 OK, clarified in my copy:
https://github.com/bemasc/dnssec-strict-mode/commit/1d2a88aabdbf1c137baafa5465adbab263eee344

---

From: Petr Špaček <[email-masked]>
Date: Tue, 23 Feb 2021 16:58:47 +0100

Hi Ben,

I would appreciate more information about threat model you work with.

This
> Abstract
> 
>    Currently, the DNSSEC security of a zone is limited by the strength
>    of its weakest signature algorithm.  DNSSEC Strict Mode makes zones
>    as secure as their strongest algorithm instead.

is IMHO gravely imprecise: DNSSEC security is as strong as weakest link 
in (any permissible) chain of trust.

In other words, if my parent TLD has 1024 bit RSA and my "secure" zone 
has 1024 bit RSA + a fancy ECC alg with the new bit set, it still means 
nothing security-wise. Attacker can get better return on investment by 
attacking the parent zone.

I think it needs discussion if it is worth approaching this problem with 
single-zone granularity.

-- 
Petr Špaček

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 11:15:58 -0500

On Tue, Feb 23, 2021 at 10:41 AM Paul Wouters <[email-masked]> wrote:

> its weakest signature algorithm.  DNSSEC Strict Mode makes zones as secure
> as their strongest
> > algorithm instead.
>

I can't claim that your assumptions are wrong, but they're different from
mine.  I am assuming, in this draft, that there may be some valid reasons
to have a zone persistently signed by multiple algorithms.  The
introduction lists three such reasons, all variations on "because I have to
add an algorithm that I don't totally trust".  That could be because some
validators (perhaps including specific partners or customers) don't support
my favorite algorithm, or because there is no single algorithm that seems
totally trustworthy to me.

This gets more complicated with size and performance considerations.  For
example, a zone might wish to remain compatible with RSA-only validators
but feel that RSA-N keys are too big.  In that case, they could sign with
RSA-N/2 and (stronger, smaller) ECDSA keys.  Currently, this is not a good
option: a zone in that configuration would be weaker than if it were only
signed with RSA-N/2.

> this, but the code path has to put something in.

Note that nothing in this draft involves any software with opinions about
"weaker" and "stronger" algorithms.  The zone owner marks certain
algorithms (ideally all algorithms in use) as Strict, and the validator
checks that they all work.

> Better not to have

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 23 Feb 2021 11:20:37 -0500 (EST)

On Tue, 23 Feb 2021, Paul Hoffman wrote:

> What is the purpose of this flag? Why wouldn't a zone owner who has 
> such a strong desire for using that one algorithm just sign with 
> that algorithm?

section 2.2 of the draft makes the argument.  Ben seems to be 
imagining a world where some validators don't implement the "stronger" 
algorithm and he wants to provide at least some protection for them - 
potentially for a long time.  And, addressing Paul Wouters' comment, 
he's envisioning a world where the state of having multiple 
algorithms' signatures persists.

Recognizing that I'm likely biased by my history of working on the 
current "mandatory algorithm rules", I don't buy the need for this 
complexity.  In practice our "weak" algorithms aren't _that_ weak. 
And, if they are, we might as well stop signing with them entirely. 
This seems like unnecessary further loading of the camel.

Ben, if you decide to persist with this idea, I've filed some issues 
in your GH repo.

-- Sam

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 11:26:21 -0500

On Tue, Feb 23, 2021 at 11:00 AM Petr Špaček <[email-masked]> wrote:
...

> attacking the parent zone.

True.  I've added a note on this topic to the Security Considerations [1].

[1]
https://github.com/bemasc/dnssec-strict-mode/commit/08142c4b41690c23cfe0486e9f0ec5fb6c5da1ca

> single-zone granularity.

I don't see a better alternative, but I'm certainly open to ideas.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 11:49:40 -0500

On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler <[email-masked]> wrote:
...

> And, if they are, we might as well stop signing with them entirely.

I think that was true for a long time, but I'm not sure it's still true, or
will stay true.  I'm particularly motivated by the ongoing discussion about
adding Algorithms to the registry [1], and a recent overview of
Post-Quantum cryptography for DNSSEC [2].  Also, 829-bit RSA was factored
last year [3].  Validator update timelines are Very Slow, so we should be
thinking about adding features we might need before we need them.

Even if we are currently in a state where zone owners feel like they have
simple, safe choices, I don't think we should assume that this will remain
true indefinitely.

FWIW, my preference would be to simply remove the lax-validation rule from
RFC 6840, which would simplify the standard overall ... but there must
have been a good reason for it.  Strict Mode might be a stepping-stone in
that direction.

> in your GH repo.

Thanks!

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00
[2] https://indico.dns-oarc.net/event/37/contributions/811/
[3] https://en.wikipedia.org/wiki/RSA_numbers#RSA-250

---

From: Brian Dickson <[email-masked]>
Date: Tue, 23 Feb 2021 20:04:58 -0800

On Tue, Feb 23, 2021 at 8:50 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> I think that was true for a long time, but I'm not sure it's still true,
> or will stay true.
>

>   Validator update timelines are Very Slow, so we should be thinking about
> adding features we might need before we need them.
>
TL;DR: I don't think the solution offered (Strict Mode) is worth pursuing,
but it is helpful in raising awareness of the problem(s).

Ben & Sam:

I think that, while an interesting technical solution, more thought may
need to be given to the sources of problems.

I also think some of these are things that can be measured and tested.

That measurement and testing would be an excellent project for the fine
folks at APNIC (the folks I think of as "Geoff and George" but probably
include many others).

Here's what I think are problem areas, in a not comprehensive or
well-organized list:

   - Validating resolvers that are being updated, but where deployed
   instances are not tracking those updates
   - Validating resolvers that no one is managing any more (attrition
   victims)
   - Resolvers (validating or not) embedded in firmware that is not
   supported and cannot be updated
   - Forwarders of any flavor
   - Resolvers that are not maintained at all
   - No ability to identify what category a particular server is in, even
   from the client side
   - No ability to identify how many "hops" of forwarding exist, or what
   the forwarding topology looks like (depth, tree/DAG/DG, per-hop
   characteristics)
   - EDNS is only single-hop capable
   - No ability to determine or contact operator of server

The algorithms supported by the deployed base of validating resolvers (or
forwarders) impacts the ability of zone operators to deploy new algorithms.

The need to maintain old algorithms is a function of both the deployment of
support for new algorithms, and of validating resolvers that do not support
new algorithms.

One parameter that may be difficult to measure or even infer, is the
portion of validating resolvers which are either likely to never have new
algorithms added, or certain to never have new algorithms added, for some
of the reasons itemized above.

Having said all of the above, I think there are a number of approaches
which might be worth considering, either individually or in combination:

   - Improving the client capability, to discover and potentially bypass
   "problem" forwarders (e.g. skipping past the first forwarder and reaching
   out to either a subsequent forwarder or the eventual resolver reached)
   - Adding validation to the client, and adding logic to either work with,
   or work past, upstream forwarder(s)/resolver(s), e.g. via use of the CD bit
   - Creating zones designed to "break" validators deliberately, for
   specific algorithms, as a "forcing function" (e.g. popular domains that
   will get the attention of the end users behind the bad validators)
   - Developing opt-in operator identification/notification specifications,
   so operators of resolvers can eventually become aware that they need to fix
   security problems, upgrade, or be aware of upcoming flag days or likely
   transition to "everything is indeterminate/insecure" states
   - Developing mechanisms similar to the trust-anchor
   measurement/reporting to allow measurements of useful data (while still
   maintaining general anonymity?)

I think more data collection, testing, and analysis might be advisable
before picking a solution to the underlying problems.

Tackling this from the point of view that does not adequately characterize
the reasons for multiple algorithms seems like it won't address the bigger
issues, and as such will only make the situation (proliferation of
algorithms deployed in parallel) worse.

My perspective is that most zone operators will only want to deploy a
single algorithm, and improving the rate at which new algorithms are
feasible to be adopted should be an explicit goal.

Making it feasible to use new algorithms exclusively, necessarily means
breaking validation for unmanaged or unmaintained resolvers or forwarders.

If it is possible to break validation for those devices/systems, without
adversely affecting clients (due to improved client logic and/or
capabilities), that would seem to be a good thing to pursue.

Having measurements that allow zone operators to determine the impact of
changing algorithms seems extremely valuable.

I don't think these necessarily involve protocol changes per se (at the
signing/validation level at least), but having interoperable
implementations that support measurements is technically still a "DNSOP"
thing, dovetailing into OARC work or other studies by researchers.

Brian

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 24 Feb 2021 07:31:51 +0100

Moin!

On 23 Feb 2021, at 16:08, Ben Schwartz wrote:

> hastened by
Interesting read. Some comments:
- Shouldn’t multiple signatures/algorithms be the exception only used 
when
migrating to a new one? Having multiple algorithms as the norm seems 
wrong,
but I’m not a crypto person so would be interest if this is used 
somewhere.
- In DNSSEC or DNS in general you have to think about the whole domain 
tree.
If you do a more secure algorithm in a leaf/child zone you are still at 
mercy
of what your parent zones do, as an successful attack on the parent 
would
render your child zone irrelevant.
- DNSSEC validators are already absurdly complex, this is yet another 
straw
on the camels back IMHO.

So long
-Ralf
——-
Ralf Weber

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 24 Feb 2021 16:01:21 +0100

> On 23 Feb 2021, at 17:49, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> On Tue, Feb 23, 2021 at 11:21 AM Samuel Weiler <[email-masked] <mailto:[email-masked]>> wrote:
> ...
> I think that was true for a long time, but I'm not sure it's still true, or will stay true.  I'm particularly motivated by the ongoing discussion about adding Algorithms to the registry [1], and a recent overview of Post-Quantum cryptography for DNSSEC [2].  Also, 829-bit RSA was factored last year [3].  Validator update timelines are Very Slow, so we should be thinking about adding features we might need before we need them.
> 
> Even if we are currently in a state where zone owners feel like they have simple, safe choices, I don't think we should assume that this will remain true indefinitely.
> 
> FWIW, my preference would be to simply remove the lax-validation rule from RFC 6840, which would simplify the standard overall ... but there must have been a good reason for it.  Strict Mode might be a stepping-stone in that direction.

Not only am I in favor of the RFC6840 lax validation, it is in fact necessary for secure DNSSEC operation.
In fact I believe the RFC 4035 needs to be updated to explicitly allow algorithms without signatures.
At the current state of dnssec RFC definitions it is unclear how you could change DNS operators securely if these operators do not sign the zone with the same algorithm.

> [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00>
> [2] https://indico.dns-oarc.net/event/37/contributions/811/ <https://indico.dns-oarc.net/event/37/contributions/811/>
> [3] https://en.wikipedia.org/wiki/RSA_numbers#RSA-250 <https://en.wikipedia.org/wiki/RSA_numbers#RSA-250>_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Feb 2021 10:15:01 -0500

> but I’m not a crypto person so would be interest if this is used

In TLS, servers and clients almost always support several different
ciphersuites, and perform a secure negotiation to select one that they both
support.  Strict Mode is the static equivalent of secure ciphersuite
negotiation.

> - In DNSSEC or DNS in general you have to think about the whole domain

I've added a note on this the editor's draft.

More broadly, I think Strict Mode makes sense throughout the tree.  For
example, if we find ourselves in a position where quantum advances raise
concerns about RSA, and postquantum signatures are available but still new,
it might make sense to double-sign the root.

---

From: "libor.peltan" <[email-masked]>
Date: Wed, 24 Feb 2021 17:03:30 +0100

Hi Ulrich,

please see below..

Libor

Dne 24. 02. 21 v 16:01 Ulrich Wisser napsal(a):
>
>> On 23 Feb 2021, at 17:49, Ben Schwartz 
>> <bemasc=[email-masked] 
>> <mailto:bemasc=[email-masked]>> wrote:
>>
>>
>>
>> I think that was true for a long time, but I'm not sure it's still 
>> true, or will stay true.  I'm particularly motivated by the ongoing 
>> discussion about adding Algorithms to the registry [1], and a recent 
>> overview of Post-Quantum cryptography for DNSSEC [2].  Also, 829-bit 
>> RSA was factored last year [3].  Validator update timelines are Very 
>> Slow, so we should be thinking about adding features we might need 
>> before we need them.
>>
>> Even if we are currently in a state where zone owners feel like they 
>> have simple, safe choices, I don't think we should assume that this 
>> will remain true indefinitely.
>>
>> FWIW, my preference would be to simply remove the lax-validation rule 
>> from RFC 6840, which would simplify the standard overall ... but 
>> there must have been a good reason for it.  Strict Mode might be a 
>> stepping-stone in that direction.
>
I think lax validation is not necessary for secure DNSSEC operation. 
DNSSEC can be operated securely in the strict mode completely, including 
algorithm roll-overs.
> algorithms without signatures.

I believe the lax validation needs to be denied completely in order to 
not support RFC4035 (and 6840) non-compliant signers.

> At the current state of dnssec RFC definitions it is unclear how you 
> could change DNS operators securely if these operators do not sign the 
> zone with the same algorithm.
IMHO it's pretty clear: it's simply not possible at all.
>> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00>
>> <https://indico.dns-oarc.net/event/37/contributions/811/>
>> <https://en.wikipedia.org/wiki/RSA_numbers#RSA-250>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Feb 2021 11:05:01 -0500

On Tue, Feb 23, 2021 at 11:05 PM Brian Dickson <
[email-masked]> wrote:
...

> feasible to be adopted should be an explicit goal.

I don't think this is realistic.  Consider, for example, the deprecation of
TLS 1.0 [1] 15 years after it was superseded by TLS 1.1.  I see no reason
to expect that DNSSEC validator update cycles will be faster.

Thanks to secure negotiation, TLS was not subject to all the weaknesses of
TLS 1.0 and its ciphers during that time.  Without Strict Mode, DNSSEC has
no such protection.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/

> breaking validation for unmanaged or unmaintained resolvers or forwarders.

Note that "newness" is not the only factor.  There are also persistent
disagreements about security levels (esp. national crypto).

> capabilities), that would seem to be a good thing to pursue.

Given the experience with TLS, I don't think we can reasonably assume that
"clients" are on a much faster update cycle.

I think, at core, there's a philosophical question here.  Do we intend for
DNSSEC to actually be used for critical security in open systems?  If so,
it will have to work like TLS: a 1% failure rate will be utterly
intolerable, so servers will have to retain support for the 99th percentile
of awful ancient clients.

Alternatively, we can admit that DNSSEC is only intended for critical use
in closed systems, where zones and validators can be updated together.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Feb 2021 11:55:40 -0500 (EST)

On Wed, 24 Feb 2021, Ben Schwartz wrote:

> On Tue, Feb 23, 2021 at 11:05 PM Brian Dickson <[email-masked]> wrote:
> ...
>       My perspective is that most zone operators will only want to deploy a single algorithm, and improving the rate at which new
>       algorithms are feasible to be adopted should be an explicit goal.
> 
> I don't think this is realistic.  Consider, for example, the deprecation of TLS 1.0 [1] 15 years after it was superseded by TLS 1.1.  I
> see no reason to expect that DNSSEC validator update cycles will be faster.

I think there are two things confused here. Obsoleting an algorithm from
a single zone using migration to a newer algorithm, and exorcising an
old algorithm from the planet.

The first is clearly defined on how it is done. It is also known that if
the losing Registrar is uncooperative, things will be a bit wonky during
the transfer. That can only be fixed by contractual obligations, not
technology.

> Given the experience with TLS, I don't think we can reasonably assume that "clients" are on a much faster update cycle.

I don't see the relevance of this at all. The "strict mode" seems to
be originating from a believe that having two algorithms in the zone,
either briefly during migration, or permanently to satisfy multiple
government requirements, is a problem. I have not been convinced there
is a problem that this draft would remedy.

> I think, at core, there's a philosophical question here.  Do we intend for DNSSEC to actually be used for critical security in open
> systems?  If so, it will have to work like TLS: a 1% failure rate will be utterly intolerable, so servers will have to retain support
> for the 99th percentile of awful ancient clients.

No, because the failure mode of no longer trusting obsoleted DNSSEC
algorithms is to treat them as "unsigned". So there is no failure
rate of any percentage (other than implementation errors, such as
returning ServFail when the system doesn't allow SHA1, instead of
marking SHA1 as untrusted and returning data without the AD bit,
which has happened recently in fedora with knot for example)

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Feb 2021 16:38:06 -0500

On Wed, Feb 24, 2021 at 11:56 AM Paul Wouters <[email-masked]> wrote:
...

> The "strict mode" seems to
> government requirements, is a problem.

Agreed.  At least, that's one of the reasons.

...

> > I think, at core, there's a philosophical question here.  Do we intend
> for DNSSEC to actually be used for critical security in open
> > systems?  If so, it will have to work like TLS: a 1% failure rate will
> be utterly intolerable, so servers will have to retain support
> rate of any percentage

If your system continues to function when records are unsigned, then you
are not using DNSSEC for critical security.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Feb 2021 08:44:09 +1100

> On 25 Feb 2021, at 02:01, Ulrich Wisser <ulrich=[email-masked]> wrote:
> 
>> 

You can’t do that as the logic doesn’t allow it.  Perform algorithm roles to and from mandatory to implement algorithms before and after the move if necessary.

>> [1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-iana-cons-00

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Feb 2021 17:13:29 -0500

...

> could change DNS operators securely if these operators do not sign the zone
> with the same algorithm.
>
> You can’t do that as the logic doesn’t allow it.  Perform algorithm roles
> to and from mandatory to implement algorithms before and after the move if
> necessary.
>

What if you set all TTLs to zero on both sides until the transition is
complete?

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Feb 2021 15:57:26 -0800

> What if you set all TTLs to zero on both sides until the transition is

That's not possible. The DS records are on the parent side (TLD) and the
TTL is set by the TLD per whatever their standard policy is. Same for
RRSIGs over those DS records.

Brian

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Feb 2021 16:10:36 -0800

> necessary for secure DNSSEC operation.

I almost wrote up an ID specifically to say validation should always
be lax but be much more clear about it than the current specs.

I kind of like Ben's proposal, *if* it was married with a clear set of
text saying without it validators should take any acceptable validation
path (and not "all or nothing").

Only operators understand their situations with respect to "should I be
more robust or more secure?"  You can't have both, and right now I know
operators that refuse to roll their algorithm because the complexity is
too high (hence my other draft).  So they stick with an insecure
algorithm instead.  Is that better?  Wouldn't it be better for people
that just want security but robustness to give them an option that
provides that without the ultra-security required by others? 
-- 
Wes Hardaker
USC/ISI

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 24 Feb 2021 19:50:59 -0500

> RRSIGs over those DS records.

That's fine.  I meant the TTLs of the ZSKs and zone contents.  Switching
from provider A to provider B, the sequence would be
1. Set all TTLs in the zone to zero
2. Wait
3. Copy zone to provider B
4. Add DS for B's keys to the parent
5. Wait
6. Add B's NS to the parent
7. Remove A's NS from the parent
8. Wait
9. Remove DS for A's keys from the parent
10. Set zone TTLs to > 0

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Feb 2021 12:04:34 +1100

> On 25 Feb 2021, at 09:13, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> What if you set all TTLs to zero on both sides until the transition is complete?

You still can’t do it.  You need to publish simultaneous DS records for the loosing and gaining zones.  Zone transfers take time.  The DNS is loosely coherent.

---

From: "libor.peltan" <[email-masked]>
Date: Thu, 25 Feb 2021 08:58:38 +0100

Hi Ben,

Dne 25. 02. 21 v 1:50 Ben Schwartz napsal(a):
>
>
> On Wed, Feb 24, 2021 at 6:57 PM Brian Dickson 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>     That's not possible. The DS records are on the parent side (TLD)
>     and the TTL is set by the TLD per whatever their standard policy
>     is. Same for RRSIGs over those DS records.
>
>
> That's fine.  I meant the TTLs of the ZSKs and zone contents.  
> Switching from provider A to provider B, the sequence would be

This wouldn't work as well. The resolver would see two DSs with 
different algorithms at the parent zone, but only one (pair of) DNSKEYs 
with single algorithm, whichever provider of your zone it'll query.

This would violate RFC 4035: "The apex DNSKEY RRset itself MUST be 
signed by each algorithm appearing in the DS RRset located at the 
delegating parent (if any)."

> 9. Remove DS for A's keys from the parent

IMHO, performing an algorithm rollover while switching DNSSEC providers 
is indeed difficult, if possible at all. Even the lax validation doesn't 
help much.

However, performing an algorithm rollover normally isn't that hard using 
proper tooling, so I don't think we should continue to justify lax 
validation only in order to encourage signers to switch from using 
obsolete algorithms.

Libor

---

From: Ulrich Wisser <[email-masked]>
Date: Thu, 25 Feb 2021 12:52:53 +0100

> On 24 Feb 2021, at 22:44, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

But this is a real world problem, one that is holding DNSSEC back.
If you buy DNS operations the operator will usually tell you what algorithm they use, you have no choice in that.
Now if your new operator doesn’t use the same algorithm you can’t switch without going insecure.
I don’t think this is an acceptable situation.

> PHONE: +61 2 9871 4742              INTERNET: [email-masked] <mailto:[email-masked]>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 25 Feb 2021 09:45:38 -0500

On Thu, Feb 25, 2021 at 2:58 AM libor.peltan <[email-masked]> wrote:

> On Wed, Feb 24, 2021 at 6:57 PM Brian Dickson <
> This wouldn't work as well. The resolver would see two DSs with different
> algorithms at the parent zone, but only one (pair of) DNSKEYs with single
> algorithm, whichever provider of your zone it'll query.
>
> This would violate RFC 4035: "The apex DNSKEY RRset itself MUST be signed
> by each algorithm appearing in the DS RRset located at the delegating
> parent (if any)."
>
Yes, but RFC 6840 appears to prohibit validators from enforcing this
requirement.

> IMHO, performing an algorithm rollover while switching DNSSEC providers is
> indeed difficult, if possible at all. Even the lax validation doesn't help
> much.
>
> validation only in order to encourage signers to switch from using obsolete
> algorithms.
>
Agreed.  I'm just exploring the implications of the current rules.

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Feb 2021 10:11:10 -0500

Hi Ulrich,

> If you buy DNS operations the operator will usually tell you what algorithm they use, you have no choice in that.

This feels like one of those areas where more specificity is needed. "DNS operations" is is over-broad; what you mean, I think, is "if you outsource zone-signing". If you sign yourself and distribute your zone to external DNS operators then you can add and drop vendors without worrying about key rollovers, for example.

> I don’t think this is an acceptable situation.

I agree that this is a factor that ought to be included in the process of deciding to move vendors. If your proposed new vendor can't do what you want, then presumably you don't move there. While it's always possible to make mistakes, it's not at all clear to me that particular problem is something that needs protocol-level mitigations.

DNSSEC is normally part of a layered set of defences. In such an architecture relaxing one layer for a period in order to fix a problem or avoid a more complicated transition can be a perfectly acceptable answer. Going insecure for a short period in that context is not necessarily a cop-out; it could well be smart thinking.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Feb 2021 15:26:30 +0000

In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't understand why it is even useful. If I am signing one of my zones with two algorithms, I must intend to do so. What is the value of me saying that only one of the signing algorithms is the strong one?

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 25 Feb 2021 11:06:19 -0500

On Thu, Feb 25, 2021 at 10:26 AM Paul Hoffman <[email-masked]>
wrote:

> In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't
> understand why it is even useful. If I am signing one of my zones with two
> algorithms, I must intend to do so. What is the value of me saying that
> only one of the signing algorithms is the strong one?
>

That's not especially the intent.  Currently, if you sign with two
algorithms, and either of those algorithms becomes insecure*, your zone
becomes susceptible to forgery.  If you mark both algorithms as Strict,
then your zone remains secure (for validators who implement both algorithms
and this draft).

Marking only one algorithm as Strict is necessary during certain
transitions but is not otherwise very useful.

*possibly unbeknownst to the public

---

From: Paul Wouters <[email-masked]>
Date: Thu, 25 Feb 2021 12:39:45 -0500

On Feb 25, 2021, at 11:06, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> That's not especially the intent.  Currently, if you sign with two algorithms, and either of those algorithms becomes insecure*, your zone becomes susceptible to forgery.

Which is why we have RFC 8624 and it’s successors. It really should prevent you from using “insecure” or weak algorithms. The [*] doesn’t really help you. If sha2 is broken and we don’t know it, you wouldn’t know to not use it as “secure”

>   If you mark both algorithms as Strict, then your zone remains secure (for validators who implement both algorithms and this draft).

That cannot be true, unless your draft requires validaties to validate with all algorithms for a double signed zone (also double signed zones are rare and really only transition during a migration)

I’m with Paul H here, I don’t see a use case.

As I think Petr said, we need to make the software do algorithm rollovers easier so people don’t avoid migration.

Paul

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 25 Feb 2021 13:22:30 -0500 (EST)

On Thu, 25 Feb 2021, Ben Schwartz wrote:

> On Thu, Feb 25, 2021 at 10:26 AM Paul Hoffman <[email-masked]> wrote:
>       In reading draft-schwartz-dnsop-dnssec-strict-mode, I still don't understand why it is even useful. If I am
>       signing one of my zones with two algorithms, I must intend to do so. What is the value of me saying that only one
>       of the signing algorithms is the strong one?
> 
> 
> That's not especially the intent.  Currently, if you sign with two algorithms, and either of those algorithms becomes
> insecure*, your zone becomes susceptible to forgery.  If you mark both algorithms as Strict, then your zone remains secure
> (for validators who implement both algorithms and this draft).
> 
> Marking only one algorithm as Strict is necessary during certain transitions but is not otherwise very useful.
> 

While I remain unconvinced...

This piece of the use case - though not the "my algorithm isn't 
supported everywhere" case - seems like it could also be solved by 
defining a new signature algorithm type, e.g. 
RSASHA512+ECDSAP384SHA384 [*], where a single (very long) DNSKEY 
record has keying material for multiple underlying crypto suites and a 
single (likely also long) RRSIG of this type has signatures for 
multiple suites.  Specify the "algorithm" as only validating when all 
of the pieces separately are valid - essentially, define an algorithm 
that is at least as strong as the strongest, not the weakest, one of 
the set.

Someone will aruge that this needlessly burns a codepoint from an 
8-bit field, potentially even burning them as pairwise combinations of 
underlying algorithms.  But it is a different way of doing the 
signaling, and the resolver logic feels, intuitively, a little 
simpler.

-- Sam

[*] is that an algorithm identifier or a crypto key in its own right?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Feb 2021 18:32:57 -0200

> On Feb 23, 2021, at 1:08 PM, Ben Schwartz <[email-masked]> wrote:
> 

This would harden DNSSEC against downgrade attacks in the scenario that
some widely supported algorithm loses its shine, and all the alternatives
are too new and are not yet broadly adopted.

The weak algorithm would have to still be sufficiently strong to bother
to keep publishing, thus able to withstand attacks by attackers of modest
means, and succumb only to nation-state level resources and non-trivial
costs even for these.

We should also keep in mind that DNSSEC use of algorithms is for signatures
only, and so need only resist attacks while the key is in use.  There's no
need to remain secure 30+ years after the fact.

Thus, while on the face of it, downgrade-resistance is a sensible goal, and
the proposed mechanism is reasonably simple, it is not clear that it addresses
a sufficiently "dire" problem.

Our practical algorithm difficulties are:

   * ~95% of domains use 0-bit keys (no DNSSEC at all)
   * ~8K out of the 14.2 million signed domains are using 512-bit RSA keys
   * ~2 million domains are using RSA-SHA1 (algorithm 7 primarily with 27k using 5)
   * ~1.8 million domains have SHA1 DS RRs
   * ~120k domains are using "unreasonably large" 4096-bit RSA keys, also futile
     given 2048-bit keys in the root zone.
   * ~130k domains have 1024-bit RSA KSKs, these should be at least 1536, BCP 2048-bits.
      They should be rolled more often.
   * RSA ZSKs are predominatly (~7.3 million) 1024-bit, BCP is 1280.  They should
     be rolled more often.

And of course we need registrars/registries that support CDS/CDNSKEY, more
attention to registrar account security, ...

So downgrade issues are quite a long way down the list of priorities.

When (and if) the quantum crypto apocalypse is more realistically in
our near future, we'll probably need to be doing DNS over QUIC to
transport large public keys and signatures over a new transport that
can effectively handle them.

That may be the time to consider whether we need to guard against
plausible downgrades from PQC to legacy PK cryptography with many
resolvers and/auth servers not yet ready to do the new thing.

Thus I look at DoQ not as a dprive mechanism, but as a hedge against
scalable QCs.  In that context it may some day make sense to be
concerned about downgrades, but I think there are more immediate
issues to be addressed.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Feb 2021 08:08:50 +1100

> On 26 Feb 2021, at 04:39, Paul Wouters <[email-masked]> wrote:
> 

And the first thing to do is to stop saying “Roll DNSSEC Algorithms”. You are adding a new algorithm then dropping the old algorithm.  TLD operators made this sound dangerous.  They created the myth that it is hard to do.  Every signed zone in existence “added a new algorithm” when they signed their zones for the first time.  Trying to do the two things at once complicates things.

Add a new algorithm:

Create keys for the new algorithm.  Start signing the zone with them.  Wait a while for any old DNSKEY RRsets (or the negative cache when signing the first time) to expire from caches.  Add DS records for them.

Remove a algorithm:

Remove DS records for the algorithm.  Wait a while for the DS records to go from caches.  Stop signing the zone with the algorithm and remove the DNSKEYs and associate RRSIGs.

Thats it except when there are trust anchors involved like for the root zone.  You add trust anchors last and remove them first.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Feb 2021 21:21:08 +0000

On Feb 25, 2021, at 8:06 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> That's not especially the intent.  Currently, if you sign with two algorithms, and either of those algorithms becomes insecure*, your zone becomes susceptible to forgery.  If you mark both algorithms as Strict, then your zone remains secure (for validators who implement both algorithms and this draft).

If the algorithm becomes insecure and the public knows about it, I remove that signature from my zone.

If the algorithm because insecure and I don't know about it, I am at the same risk as if my private key was compromised and I don't know about it.

Again, this seems like it could only be marginally useful relative to good signing practices.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Fri, 26 Feb 2021 10:06:19 -0500

If you sign your zone with several algorithms, and mark them all 'Strict",
you are asking my resolver to do extra work.  I will probably configure my
resolver to only validate with one algorithm.  Maybe the strongest, maybe
the least cpu intensive, my choice, not yours.

-- 
Bob Harold

On Thu, Feb 25, 2021 at 4:21 PM Paul Hoffman <[email-masked]> wrote:

> If the algorithm because insecure and I don't know about it, I am at the
> same risk as if my private key was compromised and I don't know about it.
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Feb 2021 17:20:38 -0200

> On Feb 26, 2021, at 1:06 PM, Bob Harold <[email-masked]> wrote:
> 
> If you sign your zone with several algorithms, and mark them all 'Strict", you are asking my resolver to do extra work.  I will probably configure my resolver to only validate with one algorithm.  Maybe the strongest, maybe the least cpu intensive, my choice, not yours.

In terms of downgrade resistance, that's just fine.  The signal
should not be interpreted to require the resolver to check them
all, or any particular one.  Rather, it would indicate that you're
free to conclude there's an attack and fail, if your preferred
strict algorithm is not included in the set of returned signatures.

This is sufficient to protect against downgrades from whatever
algorithm you would have chosen if you had them all, to some other
one that you would not have chosen.

One could also take the view that all the algorithms are equally
good, and ignore the signal, though if I saw a promise of P256 + RSA,
and got back just a 512-bit RSA signature, I'd be reluctant to
conclude that it is as strong as the missing P256 signature... :-)

So, in principle the proposal is a fairly natural anti-downgrade
mechanism.  The main question is whether this is plausibly needed,
and here I am not so sure.  I'd prefer to instead see more attention
to avoiding weak parameters.

This looking at SHA-1, we need to:

  * Phase out DS hash algorithms 1 (and outdated GOST 3)

  * Phase out DNSKEY algorithms 5 and 7.

Looking RSA-base DNSKEY algorithms, the the most widely used
RSA key sizes are: 

             # domains  key bits
             ---------  --------
             7,972,397      2048
             7,342,144      1024
               122,529      4096
                22,678      1280
                13,763      1536
                 8,273       512
                 1,502     Other [1]

I would therefore propose that we:

  * Update the RSA-based algorithms to require keys of
    at least 1024 bits and at most 2048 bits.

  * After the sunset date, shorter keys are treated the
    same way as unsupported algorithms (zone is unsigned).

  * After the sunset date, longer keys are treated as
    signature verification failure!  For better security
    than RSA-2048, use P256 or Ed25519.

  * Set a sunset date for KSKs shorter than 1536 bits,
    after which time KSKs with < 1536 bits are equivalent
    to unsigned.

  * Strongly recommend ZSKs of at least 1280 bits, and update
    defaults in signing tools to be 1280 bits, if currently
    set to 1024-bits.

  * Recommend 1280 bits for ZSKs.

  * Recommend 2048 bits or 1536 bits for KSKs

  * Require the RSA exponent to be one of the 4
    used in the wild that are not outright errors:

          2^2^4 + 1     = 0x10001 = 65537      (8,126,993 domains)
          2^2^30 + 3 = 0x40000003 = 1073741827 (   29,398 domains)
          2^2^0 + 1               = 3          (      218 domains)
          2^2^5 + 1 = 0x100000001 = 4294967297 (       21 domains)

	  [ https://stats.dnssec-tools.org/ ]

    possibly just the first 3, the 21 domains using 2^2^5+1 can
    migrate to a more sensible exponent.

Improving practices in this space will do a lot more to improve
DNSSEC security than downgrade-resistant key algorithm signalling.

-- 
	Viktor.

[1] Full RSA key bit size frequency table:

   7972397 2048
   7342144 1024
    122529 4096
     22678 1280
     13763 1536
      8273 512
       345 1028
       299 2304
       268 2560
       124 2024
       114 1300
        99 3072
        72 2047
        34 1023
        22 1152
        17 768
        12 1350
        12 1550
        12 1048
        10 2046
         4 2014
         4 2096
         3 4086
         3 2044
         3 2045
         3 1304
         3 2112
         3 1400
         2 4095
         1 1475
         1 1483
         1 1527
         1 1530
         1 1294
         1 1972
         1 1984
         1 256
         1 1292
         1 2028
         1 2038
         1 2043
         1 1291
         1 1283
         1 1248
         1 1014
         1 2119
         1 1155
         1 2319
         1 2480
         1 1080
         1 1042
         1 3096
         1 3968
         1 4075
         1 4092
         1 1336
         1 1330
         1 1345
         1 1315
         1 1430
         1 1444
         1 1455
         1 1456

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 26 Feb 2021 14:58:53 -0500

Viktor,

I think your analysis of the problems of current deployment are convincing
and useful.  Thanks!

> DNSSEC security than downgrade-resistant key algorithm signalling.

I agree.  The Strict Mode draft is, in a sense, based on the pessimistic
assumption that we won't be able to sufficiently improve these practices,
so we'll need to be able to tolerate second-rate signature algorithms.
That could be because of outdated clients, postquantum concerns, or
conflicting national crypto requirements.  Also, the bar will be higher if
we believe that DNSSEC is not only for partial defense and special uses,
but a global security layer on par with HTTPS.

It's clear that the working group is not convinced.  That's fine!  As long
as everyone is aware of the challenge, we can revive this approach if it
becomes necessary.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Feb 2021 20:26:06 -0200

> On Feb 26, 2021, at 5:58 PM, Ben Schwartz <[email-masked]> wrote:
> 
> I agree.  The Strict Mode draft is, in a sense, based on the pessimistic assumption that we won't be able to sufficiently improve these practices, so we'll need to be able to tolerate second-rate signature algorithms.  That could be because of outdated clients, postquantum concerns, or conflicting national crypto requirements.  Also, the bar will be higher if we believe that DNSSEC is not only for partial defense and special uses, but a global security layer on par with HTTPS.
> 
> It's clear that the working group is not convinced.  That's fine!  As long as everyone is aware of the challenge, we can revive this approach if it becomes necessary.

I am much closer to convinced than it may appear.  The protocol
is logically and technically sound.  I hesitate primarily because
I think we're not doing the basics well enough yet to set the bar
even higher, and users are likely to make mistakes.  I'd like to
revisit this proposal as use of DNSSEC expands and we start to
expect more from operators and we see evidence that practices
have improved to a point where we might legitimately worry about
downgrades as much as about operational errors.

-- 
	Viktor.