Subject: [DNSOP] Fwd: [Ext] DNSSEC Strict Mode

From: Ulrich Wisser <[email-masked]>
Date: Mon, 1 Mar 2021 14:29:55 +0100

In the .se zone dnssec penetration is quite high (approx. 50%). And validation is high in Sweden too, all major ISPs validate.
Government agencies and government owned companies in Sweden are required to sign their zones. Not all do it - yet, but we are working on it.
Our goal is to drive .se to become 100% signed. 

100% signed would mean unsigned zones do not get delegated, going insecure is no longer an option.
I would like the protocol to be able to handle that case. 

The “easy” solution is to require lax-validation. It doesn’t make a zone less secure and allows to transfer zones between operators using different algorithms.

/Ulrich

> 
> 
> 
>> On 1 Mar 2021, at 14:14, Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Ulrich,
>> 
>> On Mar 1, 2021, at 05:43, Ulrich Wisser <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On 25 Feb 2021, at 16:11, Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> 
>> 
>>>> On Feb 25, 2021, at 06:53, Ulrich Wisser <ulrich=[email-masked] <mailto:ulrich=[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.
>>>> 
>>>> 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.
>>> 
>>> Ok, I can be more specific. 
>>> 
>>> As a small business owner you have no way to move your hosting company to change their DNSSEC configuration. (Besides that you most probably have no idea that it exists.) You should be able to switch hosting providers without thinking about security, a secure transition should be guaranteed by the hosting companies, who can only do it if it is enabled by the protocol.
>> 
>> Even this really requires more specificity. What is a "hosting company"?
>> 
>> I think a lot of the problems we face with these kinds of scenarios is that various functionally-overlapping industries have sprung up without DNSSEC being much more than an afterthought in the way that products are structured and sold. It's perhaps unremarkable that the mechanics of offering these services are not a great fit.
>> 
>> We can try harder and harder to shoe-horn DNSSEC into products that don't easily accommodate it, for sure. However, there's an attendant risk that by doing so all we really achieve is making DNSSEC more operationally complex than it already is, and I think there's an argument that such an outcome would not make it easier to deploy.
>> 
>>> As a larger entity you might have compliance requirements for dnssec.
>> 
>> [As an entity large enough to pay significant fees for enterprise DNS service, the reality today is that you probably don't use DNSSEC at all.]
>> 
>>>> 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.
>>> 
>>> I totally disagree. When has switching off security ever been a smart option?
>> 
>> If security was the only consideration, then nobody would connect anything to a network in the first place.
>> 
>>> It is only considered smart because the process of moving is so complex and error prone. 
>>> And that is a “feature” of the protocol design. It’s not a law of nature.
>>> We could change the design to allow for secure transfer.
>> 
>> ... and by doing so we could increase the complexity somewhere else.
>> 
>> I'm really just pushing back on the idea that going insecure for a planned, controlled period of time is necessarily a terrible idea. I often see these kinds of reactions from people seeing particular security measures as binary options, instead of taking a more holistic and risk-based approach, which is why my knee is jerking (I'm not suggesting that you are one of them).
>> 
>> If I rely upon a DNS vendor to sign my zone and I want to change vendors for some business reason, being able to switch easily at the cost of going insecure for 6 hours might be a much better answer than not being able to switch at all, or even having the cost of switching amplified by 100 person-hours of planning, or dealing with the risk of going dark to users downstream of 8.8.8.8 when it turns out that the change triggers another corner-case in Google's code base.
>> 
>> To the end-user, I can see why having a protocol element designed to make this easier and avoid the practical need to go insecure seems highly attractive, but we're really just shifting the cost of dealing with what might very well be a somewhat rare corner case to the developers, operators and users of every DNS server that supports DNSSEC. Even if the costs are low in the latter case, I think it's reasonable to say they are non-zero and universal, which means they might not be so low in aggregate.
>> 
>> In this context, the determination of what is smart and what is silly seems a little more grey to me than your message ("totally") suggests.
>> 
>> 
>> Joe
>

---

From: Jim Reid <[email-masked]>
Date: Mon, 1 Mar 2021 14:18:59 +0000

> On 1 Mar 2021, at 13:29, Ulrich Wisser <ulrich=[email-masked]> wrote:
> 

Ulrich, that seems to be a (registry-specific?) policy matter => probably out of scope for the DNS protocol.

How could a parent signal “everything below this point of the tree is signed”? How could they guarantee that was true, given delegation means there’s a change of control for some part of the name space? How would resolving servers be expected to use this signalling information? If they come across an unsigned but working delegation, should they treat that as a validation failure or continue to resolve the query? That would seem to be a local policy/configuration matter too.

I’m not sure it matters to anyone if some parent zone has this sort of policy or not. Could you explain the use case or problem statement?

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 1 Mar 2021 16:46:30 +0100

Hi Jim,

I don’t want to signal this to resolvers, there is no need to. As domains are resolved by themselves a resolvers doesn’t need to know if all other subdomains of .se are signed too, just that the one it is interested in is signed.

But if .se would have that policy, how would you move a domain between name server operators?
- If approved by the chairs Shumon and I will present our work on automating this at the next dnsop meeting.
- if the operators do not support the same algorithm, only lax validation can save you. (And that is how this discussion started)

/Ulrich

> On 1 Mar 2021, at 15:18, Jim Reid <[email-masked]> wrote:
> 
> 
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 1 Mar 2021 11:11:44 -0500

Given the existence of MTI algorithms, do we need to be so concerned about
operators who support non-overlapping subsets?  It seems like the guidance
is clear: follow the MTI!

On Mon, Mar 1, 2021 at 10:46 AM Ulrich Wisser <ulrich=
[email-masked]> wrote:

> Hi Jim,
>
> I don’t want to signal this to resolvers, there is no need to. As domains
> are resolved by themselves a resolvers doesn’t need to know if all other
> subdomains of .se are signed too, just that the one it is interested in is
> signed.
>
> - If approved by the chairs Shumon and I will present our work on
> automating this at the next dnsop meeting.
> - if the operators do not support the same algorithm, only lax validation
> can save you. (And that is how this discussion started)
>
> /Ulrich
>
>
> > Ulrich, that seems to be a (registry-specific?) policy matter =>
> probably out of scope for the DNS protocol.
> >
> > How could a parent signal “everything below this point of the tree is
> signed”? How could they guarantee that was true, given delegation means
> there’s a change of control for some part of the name space? How would
> resolving servers be expected to use this signalling information? If they
> come across an unsigned but working delegation, should they treat that as a
> validation failure or continue to resolve the query? That would seem to be
> a local policy/configuration matter too.
> >
> > I’m not sure it matters to anyone if some parent zone has this sort of
> policy or not. Could you explain the use case or problem statement?
> >
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Mar 2021 11:37:28 -0500 (EST)

On Mon, 1 Mar 2021, Ben Schwartz wrote:

> Given the existence of MTI algorithms, do we need to be so concerned about operators who support non-overlapping
> subsets?  It seems like the guidance is clear: follow the MTI!

MTI is not mandatory to deploy. If your new DNS operator is fully ECDSA,
and your old one is RSA only, and both are MTI, there is still a
problem to solve.

I still think this is mostly a tooling problem. With the right tools,
the new registrar can give a DNSKEY to the old registrar, who is
mandated by contract to add it to their zone.

The old registrar that is uncooperative, an always break things. eg
simply by decomissioning the domain in question completely from their
namesevers.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Mon, 1 Mar 2021 09:27:50 -0800

> can save you. (And that is how this discussion started)
This should be highlighted to keep the conversation moving in the right
direction:

   - Switching providers while staying secure requires inter-provider
   cooperation, including publishing ZSKs from both providers in the DNSKEY
   RRSET served by both providers.
   - Doing lax validation MAY be necessary (if the algorithms used for
   signing the zone do not overlap)
   - Doing lax validation is NOT SUFFICIENT, i.e. only adding lax
   validation is not enough to not break validation - the inter-provider stuff
   is necessary too

Brian

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 01 Mar 2021 20:54:59 +0100 (CET)

>    - Switching providers while staying secure requires
>    inter-provider cooperation, including publishing ZSKs from
>    both providers in the DNSKEY RRSET served by both providers.

What?

Maybe I just don't understand the context or conditions here, but
...

Isn't it possible to stand up a new signing and publishing setup
with new ZSKs and new KSKs, and have both the old DS record
pointing to the old setup's KSK and a new DS record pointing to
the KSK of the new setup registered in the parent zone, and then
change the actual delegation (NS records), while still retaining
both the two DS records for a while until the data from the old
setup has timed out?

There is then no need to share the secret part of the KSKs or the
ZSKs between the old and the new providers, or to include both
the new and the old ZSKs in the zone.

Regards,

- Håvard

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Mar 2021 06:58:50 +1100

Throw a forced algorithm change in on top where neither provider is willing to sign with the other providers algorithm. 

-- 
Mark Andrews

> On 2 Mar 2021, at 06:55, Havard Eidnes <he=[email-masked]> wrote:
> 
> 
>>

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 2 Mar 2021 12:52:41 +0100

@Håvard No, that isn’t sufficient. A resolver could have the old DNSKEY set in cache but get signatures from the new servers. This can be solved by cross signing the ZSK -> put the ZSK of the other provider in the respective DNSKEY set, no need to exchange private keys, only the DNSKEY records. Then you will always have a validation path.

@Mark, that is exactly what I am talking about, a forced algorithm change can only work, when both operators cooperate and if we insist on lax-validation. We need both!

Cooperation is of course another problem.There is no incentive for the “losing” operator to cooperate. And because today moving a secure domain is a complex manual task, no-one is interested in helping out. We could make this much easier with the right support in protocol and software. Shumon and I will talk on this next week.

/Ulrich

> On 1 Mar 2021, at 20:58, Mark Andrews <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Mar 2021 22:55:48 +1100

> On 2 Mar 2021, at 22:52, Ulrich Wisser <[email-masked]> wrote:
> 

It doesn’t even work then as there the signatures of the non DNSKEY records are of the wrong algorithm.

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

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 2 Mar 2021 13:06:54 +0100

> On 2 Mar 2021, at 12:55, Mark Andrews <[email-masked]> wrote:
> 
> 
> 

Why would the signatures of the non DNSKEY RRset need to be of the same algorithm as the KSK?
Lax-validation says that “any validation path” should be accepted. 

example.com. DS 123 8 2 xxx

example.com <http://example.com/>. DNSKEY 257 3 8 xxx
Example.com. DNSKEY 256 3 8 yyy
example.com <http://example.com/>. DNSKEY 256 3 13 zzz
example.com <http://example.com/>. RRSIG DNSKEY 8 …

www.example.com <http://www.example.com/>. TXT “example”
www.example.com. RRSIG TXT 13 …

In my eyes there is a clear validation path to the www rr.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Mar 2021 23:46:36 +1100

> On 2 Mar 2021, at 23:06, Ulrich Wisser <[email-masked]> wrote:
> 
> 
> 
> example.com. DNSKEY 257 3 8 xxx
> example.com. DNSKEY 256 3 13 zzz
> example.com. RRSIG DNSKEY 8 …
> 
> www.example.com. TXT “example”

It leads to bogus in a server that *only* support algorithm 8 because THERE IS NOT AN RRSIG OF WITH ALGORITHM 8

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 2 Mar 2021 14:16:00 +0100

> On 2 Mar 2021, at 13:46, Mark Andrews <[email-masked]> wrote:
> 
> 

I understand that RRSIGs are missing, but what does “bogus in a server” mean?

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 2 Mar 2021 10:20:49 -0500

...

> > It leads to bogus in a server that *only* support algorithm 8 because
> THERE IS NOT AN RRSIG OF WITH ALGORITHM 8
>

A validator that implements algorithm 8 but not algorithm 13 will declare
the resolution Bogus.

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 2 Mar 2021 16:55:23 +0100

> On 2 Mar 2021, at 14:32, Joe Abley <[email-masked]> wrote:
> 
> On Mar 2, 2021, at 08:16, Ulrich Wisser <ulrich=[email-masked]> wrote:
> 
> I think Mark's point that a validator that only supports algorithm 8 will consider the response bogus.
> 

Yes, of course. But as long as the validator supports both algorithms and uses lax-validation, it should work.
It is at least something, not a perfect solution, but it solves some of the use cases.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 2 Mar 2021 09:25:07 -0800

On Tue, Mar 2, 2021 at 4:47 AM Mark Andrews <[email-masked]> wrote:

> >>> @Håvard No, that isn’t sufficient. A resolver could have the old
> DNSKEY set in cache but get signatures from the new servers. This can be
> solved by cross signing the ZSK -> put the ZSK of the other provider in the
> respective DNSKEY set, no need to exchange private keys, only the DNSKEY
> records. Then you will always have a validation path.
> >>>
> >>> @Mark, that is exactly what I am talking about, a forced algorithm
> change can only work, when both operators cooperate and if we insist on
> lax-validation. We need both!
> >>

Rather than argue about this example (which may be incomplete and/or
erroneous), let's try to "fix" the example, and clarify which algorithm is
new, and which algorithm is old, including what is on each of the two
servers in terms signatures and keys?

(Clearly this cannot be valid to be on one server, given the DS and
RRSIG(TXT) are not the same algorithm).

I think the requirement for considering the addition, is the inclusion of
both ZSKs in both instances of the zone, AND the publication of both DS
records in the parent.

If this happens well in advance of the change of NS record in the parent,
what else needs to happen?
And how is this handled by validators that handle algorithm 8 but not
algorithm 13?

If the example is expanded and corrected, I believe the answer should be,
the algorithm 13 only zone is either insecure, or bogus, depending on the
absence or presence of the algorithm 8 DS.

I don't see a clean way to avoid a race condition between the NS records in
the parent, and the DS records in the parent, given caching.

This is likely why Joe Abley was suggesting going insecure for a brief
period is the only way to avoid anyone getting "bogus" as a validation
state.

Algorithm 8 would go insecure permanently, while Algorithm 13 would go
insecure for a brief period then go secure again.

Perhaps the brief bogus for Algorithm 8 is acceptable, in which case the
decision is really one to be made by the zone owner.

Brian

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 2 Mar 2021 18:44:13 +0100

I don’t think the dnssec specification say that a rr set has to be signed with an algorithm that is specified in the ds rr set.
The spec requires rrsigs of each algorithm to be present at the authoritative. But there is no requirement on the validation to stay with one algorithm.

What I want to accomplish is that two name server operators can move a domain between them even when they use different algorithms. With lax-validation this is possible, at least when the validator supports both algorithms.

This move would of course make the authoritatives not rfc compliant for some time.
Both authoritative would have to have a ZSK in their dnskey set that uses an algorithm for which they do not serve rrsigs.
I believe this to be a lesser problem than switching dnssec off.

/Ulrich

> On 2 Mar 2021, at 18:25, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> On Tue, Mar 2, 2021 at 4:47 AM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 2 Mar 2021, at 23:06, Ulrich Wisser <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > 
> >> On 2 Mar 2021, at 12:55, Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> 
> >> 
> >>> On 2 Mar 2021, at 22:52, Ulrich Wisser <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> > example.com <http://example.com/>. DS 123 8 2 xxx
> > 
> > www.example.com <http://www.example.com/>. RRSIG TXT 13 …
> > 
> Rather than argue about this example (which may be incomplete and/or erroneous), let's try to "fix" the example, and clarify which algorithm is new, and which algorithm is old, including what is on each of the two servers in terms signatures and keys?
> 
> (Clearly this cannot be valid to be on one server, given the DS and RRSIG(TXT) are not the same algorithm).
> 
> I think the requirement for considering the addition, is the inclusion of both ZSKs in both instances of the zone, AND the publication of both DS records in the parent.
> 
> If this happens well in advance of the change of NS record in the parent, what else needs to happen?
> And how is this handled by validators that handle algorithm 8 but not algorithm 13?
> 
> If the example is expanded and corrected, I believe the answer should be, the algorithm 13 only zone is either insecure, or bogus, depending on the absence or presence of the algorithm 8 DS.
> 
> I don't see a clean way to avoid a race condition between the NS records in the parent, and the DS records in the parent, given caching.
> 
> This is likely why Joe Abley was suggesting going insecure for a brief period is the only way to avoid anyone getting "bogus" as a validation state.
> 
> Algorithm 8 would go insecure permanently, while Algorithm 13 would go insecure for a brief period then go secure again.
> 
> Perhaps the brief bogus for Algorithm 8 is acceptable, in which case the decision is really one to be made by the zone owner.
> 
> Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 2 Mar 2021 09:44:49 -0800

Okay, it's a "top reply to myself" kind of day...

I think the work on cooperative cross signing being done by Shumon will be
necessary to solve this problem.
The TL;DR: is, it is tricky
I think the following captures the requirements:

For the period of time where cached entries signed by the previous ZSK
might exist, starting with when the delegation NS is changed to point at
the new provider:

   - The DNSKEY set would need to contain both ZSKs and both KSKs,
   - The DNSKEY set would need to be signed by both KSKs
   - Both DS records would be necessary.
   - The new version of the zone would need to be served with both sets of
   signatures (that's going to be challenging)

Only then can the old DS record be removed, at which point the Algorithm 8
validator will consider the zone to be insecure, without going bogus.

Ick.

Brian

On Tue, Mar 2, 2021 at 9:25 AM Brian Dickson <[email-masked]>
wrote:

> I don't see a clean way to avoid a race condition between the NS records
> in the parent, and the DS records in the parent, given caching.
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 3 Mar 2021 06:46:59 +1100

> On 3 Mar 2021, at 04:44, Ulrich Wisser <[email-masked]> wrote:
> 

It does with formal MUSTs.

> The spec requires rrsigs of each algorithm to be present at the authoritative. But there is no requirement on the validation to stay with one algorithm.

No there isn’t but when you only support one algorithm in the validator, if the signers fail to meet the MUST then validation fails.  The MUST on the authoritative side is there to prevent failures in the validator.

> What I want to accomplish is that two name server operators can move a domain between them even when they use different algorithms. With lax-validation this is possible, at least when the validator…

But it doesn’t work when it doesn’t. This part of DNSSEC was carefully designed this way.

> I believe this to be a lesser problem than switching dnssec off.

So you agree with me.  There is no way to transfer signing between operators and perform an algorithm change at the same time if the operators refuse (or can’t because it is not supported by the software) to sign the zone with the algorithm the other operator is using.  When I use the term “work” that means that answers validates for *every* validator that is correctly following the protocol.  That was the design goal from the very beginning.

---

From: Ulrich Wisser <[email-masked]>
Date: Thu, 4 Mar 2021 13:11:56 +0100

Mark, I totally agree with you. And I didn’t propose a change to the specs or anything. I just promoted to continue with lax-validation, because it helps with some operational problems.

> On 2 Mar 2021, at 20:46, Mark Andrews <[email-masked]> wrote:
> 
> 
>