Re: [DNSOP] On removing a pargraph in RFC4035

[Mark Andrews]

> On 25 Mar 2022, at 03:50, Ulrich Wisser  wrote:
> 
> Hi Mark,
> 
> Sorry for the late answer, IETF and some other stuff keeps me busy.
> 
> 
> Let’s start with this
> 
> We did not and do not propose to remove anything from RFC 4035. Currently we 
> are asking for RFC 6840 to be amended 
> 
> RFC 6840 Section 5.11
>This requirement applies to servers, not validators.  Validators
>SHOULD accept any single valid path.  They SHOULD NOT insist that all
>algorithms signaled in the DS RRset work, and they MUST NOT insist
>that all algorithms signaled in the DNSKEY RRset work. 
> 
> 
> PROPOSED CHANGE
>This requirement applies to servers, not validators.  Validators
>SHOULD accept any single valid path.  They MUST NOT insist that all
>algorithms signaled in the DS RRset work, and they MUST NOT insist
>that all algorithms signaled in the DNSKEY RRset work. 
> 
> 
> 
> We absolutely do not want to enable lying. We want to enable transfer of 
> domains between to signers using different algorithms.
> 
> I share your analysis that this is possible today. It violates RFC 4035 
> section 2.2. It should work given that you use two fairly well supported 
> algorithms and your resolver follows the “SHOULD” in RFC 6840 section 5.11. 

If you are really worried about that you can do it in 3 stages.  Provider A 
adds A DNSKEYs and RRSIGs, provider B then adds B DNSKEYs and RRSIGs (the A 
RRSIGs for DNSKEY will now be invalid), then provider A re-signs the DNSKEY 
RRset.

The whole point of the rules in section 2.2 is to *ensure* that a validator 
which supports only A gets A RRSIGs and that a validator that only supports 
algorithm B gets B RRSIGs when the DS RRset says there are both algorithms are 
present. The rules are there to ensure that.  That said the written rule is not 
the only way to achieve this goal, it is just the simplest rule that will 
achieve this goal.  If a signer follows the rule it can’t defeat the goal of 
the rule.

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

Note a signer can violate this and still achieve the goal of the rules but it 
requires knowledge that the signer usually doesn’t have (i.e. that an algorithm 
isn’t in the DS RRset so that it is safe to not have every RRset signed with 
every algorithm.  Validators can’t determine this as the DNS is loosely 
coherent so they have to assume that the DNSKEY RRset comes from a different 
instance of the zone to the RRset they are validating.).  If we ever revise 
this section we should add in the goal of the section.

> So the first step is to change 6840 to “MUST”, so that resolvers use any 
> validation path and do not insist on a specific or all algorithms being 
> present.

Changing the SHOULD to a MUST doesn’t solve the problem that a client that only 
supports algorithm A can’t validate the RRset after it has been told that 
signatures for algorithm A are present (see the DS RRset) when it gets answers 
from B.  Add to that clients don’t always talk *directly* to the authoritative 
servers so there is no "go ask another authoritative server"
to get a set of RRSIGs that work.

> Secondly, problems arise if a resolver only supports one of the algorithms. 
> In that case half of the answers would be considered bogus. We are looking 
> for a way to make this work. 
> 
> I admit, the problem is not trivial, but I have faith in DNSOP! ( Please 
> don’t prove me wrong. Pretty please!)
>  
> /Ulrich
> 
> 
> 
> 
>> On 22 Mar 2022, at 00:59, Mark Andrews  wrote:
>> 
>> Also the whole point of mandatory to implement (which includes business 
>> practices) is to prevent cases like this.
>> If a business wants to lie to its customers about supporting DNSSEC it 
>> should be taken to court, preferably by
>> bodies like the ACCC.
>> 
>> As for migration between providers, provided there is some co-operation, it 
>> is possible to migrate between two providers with non overlapping 
>> algorithms. It does require the signed zone data to be transferred back and 
>> forth between the operators.  It does require DNSKEY records to be swapped.
>> 
>> raw zone + provider B keys -> add A keys and sign by A -> sign by B 
>> preserving A signatures and keys -> transfer to A for serving.
>> 
>> This works today and requires no DNSSEC protocol changes.  It may require 
>> some minor implementation changes.  For BIND that would be to stop stripping 
>> out DNSSEC stuff from A at B when inline signing.  It could all be done in 
>> single server instances with views.  This is conceptually what BIND does 
>> when introducing a new algorithm with incremental signing except for 
>> transferring the new zone back and forth.
>> 
>>> On 22 Mar 2022, at 06:58, Ben Schwartz  
>>> wrote:
>>> 
>>> If we assume the existing install base 

Re: [DNSOP] On removing a pargraph in RFC4035

[Brian Dickson]

On Thu, Mar 24, 2022 at 9:53 AM Ulrich Wisser  wrote:

> Hi Mark,
>
> Sorry for the late answer, IETF and some other stuff keeps me busy.
>
>
> Let’s start with this
>
> *We did not and do not propose to remove anything from RFC 4035. Currently
> we are asking for RFC 6840 to be amended *
>
> *RFC 6840 Se*ction 5.11
>
>This requirement applies to servers, not validators.  Validators
>SHOULD accept any single valid path.  They SHOULD NOT insist that all
>algorithms signaled in the DS RRset work, and they MUST NOT insist
>that all algorithms signaled in the DNSKEY RRset work.
>
>
> PROPOSED CHANGE
>
>This requirement applies to servers, not validators.  Validators
>SHOULD accept any single valid path.  They *MUST* NOT insist that all
>algorithms signaled in the DS RRset work, and they MUST NOT insist
>that all algorithms signaled in the DNSKEY RRset work.
>
>
>
> We absolutely do not want to enable lying. We want to enable transfer of
> domains between to signers using different algorithms.
>
> I share your analysis that this is possible today. It violates RFC 4035
> section 2.2. It should work given that you use two fairly well supported
> algorithms and your resolver follows the “SHOULD” in RFC 6840 section 5.11.
>
> So the first step is to change 6840 to “MUST”, so that resolvers use any
> validation path and do not insist on a specific or all algorithms being
> present.
>
> Secondly, problems arise if a resolver only supports one of the
> algorithms. In that case half of the answers would be considered bogus. We
> are looking for a way to make this work.
>
> I admit, the problem is not trivial, but I have faith in DNSOP! ( Please
> don’t prove me wrong. Pretty please!)
>

So, just to recap the problem(s) for which a solution is desired, and also
the implications/dependencies of various solutions to the problem(s):

   - Migrate a signed delegation from provider X using algorithm A only to
   provider Y using algorithm B only
   - Validators that support both A and B must always have validation
   result "secure" during the migration (before/during/after)
   - Validators that support only A or only B must always have validation
   result of "secure" or "insecure", never "bogus"
   - There may be (are?) validators deployed which, if they understand two
   algorithms (call them C and D, which may or may not be A and/or B
   respectively) require that if two DS exists (C and D), that the DNSKEY
   RRSET be signed by both C and D (signed == with SEP bit set)

Starting with the simplest corner case:

   - A validator that supports A but does not support B, will treat a DS
   RRSET which has both A and B, as if the B records do not exist, and thus
   the DS RRSET only contains A record(s). This means that if alg A DS record
   exists, the DNSKEY set MUST be signed with alg A.
   - Ditto for B
   - This results in a requirement that if two alg DS records exist (A and
   B), the DNSKEY set must be signed by both.
   - Changing the requirement on how a validator that supports both (A and
   B) does not remove this requirement, unfortunately.

This is a different corner case than the one for one algorithm, but two
provider's DS records, where each provider's version of the zone has one
KSK (their own) and two ZSKs (theirs and the other provider's). In that
situation, the DNSKEY set is validated by either KSK (which has a matching
DS), and enables both ZSKs (only one of which will actually sign each
provider's records), permitting validation of records of a mix/match
record+RRSIG in a cache.

I do have a solution which allows each provider to have exclusive control
of their respective private keys. It does not, however, involve both
providers both being "active" at any point in time.

I think this is the only viable mechanism, without having to go back to the
design phase of DNSSEC, unfortunately:

   - Start with provider X using algorithm A
   - Add provider Z also using algorithm A. The provider Z MUST support
   both A and B algorithms. (This might actually be the zone owner, or could
   be a third provider.)
   - Do the usual thing with each provider having their own KSK, and both
   ZSKs. Publish both DS records (one for each provider's KSK).
   - Remove provider X, unpublish X's DS, remove X's ZSKs (in the normal
   order of operations needed to not go insecure and not go bogus)
   - Have provider Z do an algorithm roll from A to B. Z can do this
   unilaterally, since Z would have private keys for both KSKs (one each of
   algorithm A and B)
   - Provider Z is now only publishing with algorithm B
   - Add provider Y using algorithm B (Y and Z both using algorithm B,
   normal single algorithm dual signer)
   - Remove provider Z
   - Profit

It should always be possible to find someone who can temporarily operate a
zone, who supports the two algorithms of the respective before and after
providers. At worst, this could involve self-hosting (possibly with use of
added providers 

Re: [DNSOP] On removing a pargraph in RFC4035

[Ulrich Wisser]

Hi Mark,

Sorry for the late answer, IETF and some other stuff keeps me busy.


Let’s start with this

We did not and do not propose to remove anything from RFC 4035. Currently we 
are asking for RFC 6840 to be amended 

RFC 6840 Section 5.11
   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work. 


PROPOSED CHANGE
   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They MUST NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work. 



We absolutely do not want to enable lying. We want to enable transfer of 
domains between to signers using different algorithms.

I share your analysis that this is possible today. It violates RFC 4035 section 
2.2. It should work given that you use two fairly well supported algorithms and 
your resolver follows the “SHOULD” in RFC 6840 section 5.11. 

So the first step is to change 6840 to “MUST”, so that resolvers use any 
validation path and do not insist on a specific or all algorithms being present.

Secondly, problems arise if a resolver only supports one of the algorithms. In 
that case half of the answers would be considered bogus. We are looking for a 
way to make this work. 

I admit, the problem is not trivial, but I have faith in DNSOP! ( Please don’t 
prove me wrong. Pretty please!)
 
/Ulrich




> On 22 Mar 2022, at 00:59, Mark Andrews  wrote:
> 
> Also the whole point of mandatory to implement (which includes business 
> practices) is to prevent cases like this.
> If a business wants to lie to its customers about supporting DNSSEC it should 
> be taken to court, preferably by
> bodies like the ACCC.
> 
> As for migration between providers, provided there is some co-operation, it 
> is possible to migrate between two providers with non overlapping algorithms. 
> It does require the signed zone data to be transferred back and forth between 
> the operators.  It does require DNSKEY records to be swapped.
> 
> raw zone + provider B keys -> add A keys and sign by A -> sign by B 
> preserving A signatures and keys -> transfer to A for serving.
> 
> This works today and requires no DNSSEC protocol changes.  It may require 
> some minor implementation changes.  For BIND that would be to stop stripping 
> out DNSSEC stuff from A at B when inline signing.  It could all be done in 
> single server instances with views.  This is conceptually what BIND does when 
> introducing a new algorithm with incremental signing except for transferring 
> the new zone back and forth.
> 
>> On 22 Mar 2022, at 06:58, Ben Schwartz  
>> wrote:
>> 
>> If we assume the existing install base of resolvers isn't going away, then I 
>> don't see how we could relax the requirement.  There are already deployed 
>> resolvers enforcing it.  You would need a "flag day" to deprecate them, 
>> which could not happen for many years.
>> 
>> This seems a lot harder than just telling your next DNS provider that you 
>> can't do business with them until they implement another one of the (very 
>> small number of) widely implemented algorithms.
>> 
>> Of course, I've personally argued for essentially the opposite of this 
>> proposal [1].  Until DNSSEC has algorithmic agility without sacrificing 
>> compatibility or security, it's only usable as "extra" security.
>> 
>> [1] 
>> https://www.ietf.org/archive/id/draft-schwartz-dnsop-dnssec-strict-mode-00.html
>> 
>> On Mon, Mar 21, 2022 at 12:06 PM Ulrich Wisser  wrote:
>> Hi Ben,
>> 
>> The proposal is not to remove the possibility of double signatures, but to 
>> relax the requirement so that other use cases become possible.
>> 
>> Our use case is the transition from one dns provider to another without 
>> going insecure. If both use the same algorithm you can use the multi-signer 
>> dnssec to do this. But if the signers only support a distinct set of 
>> algorithms you are out of luck. 
>> 
>> As Libor pointed out, there are some implications to validation that must be 
>> considered.
>> 
>> I would say, there are no obvious or easy solutions. But I think/hope that 
>> DNSOP will be able to come up with some ideas that we can explore.
>> 
>> 
>> /Ulrich
>> 
>> 
>>> On 21 Mar 2022, at 10:32, Ben Schwartz  wrote:
>>> 
>>> I'm concerned about this.  Concretely, this seems like it would raise a 
>>> major barrier to rolling out new algorithms.  For example, any zone that 
>>> offers ECDSA and RSA signatures would be insecure for any RSA-only 
>>> resolvers.  It's hard to see how new algorithms could be adopted at scale 
>>> if this rule were in place.
>>> 
>>> On Sun, Mar 20, 2022 at 4:42 PM libor.peltan 
>>>  wrote:
>>> Hi Ulrich, dnsop,
>>> thank you for your effort in improving DNS.
>>> 
>>> This is a 

Re: [DNSOP] On removing a pargraph in RFC4035

[Mark Andrews]

Also the whole point of mandatory to implement (which includes business 
practices) is to prevent cases like this.
If a business wants to lie to its customers about supporting DNSSEC it should 
be taken to court, preferably by
bodies like the ACCC.

As for migration between providers, provided there is some co-operation, it is 
possible to migrate between two providers with non overlapping algorithms. It 
does require the signed zone data to be transferred back and forth between the 
operators.  It does require DNSKEY records to be swapped.

raw zone + provider B keys -> add A keys and sign by A -> sign by B preserving 
A signatures and keys -> transfer to A for serving.

This works today and requires no DNSSEC protocol changes.  It may require some 
minor implementation changes.  For BIND that would be to stop stripping out 
DNSSEC stuff from A at B when inline signing.  It could all be done in single 
server instances with views.  This is conceptually what BIND does when 
introducing a new algorithm with incremental signing except for transferring 
the new zone back and forth.

> On 22 Mar 2022, at 06:58, Ben Schwartz  
> wrote:
> 
> If we assume the existing install base of resolvers isn't going away, then I 
> don't see how we could relax the requirement.  There are already deployed 
> resolvers enforcing it.  You would need a "flag day" to deprecate them, which 
> could not happen for many years.
> 
> This seems a lot harder than just telling your next DNS provider that you 
> can't do business with them until they implement another one of the (very 
> small number of) widely implemented algorithms.
> 
> Of course, I've personally argued for essentially the opposite of this 
> proposal [1].  Until DNSSEC has algorithmic agility without sacrificing 
> compatibility or security, it's only usable as "extra" security.
> 
> [1] 
> https://www.ietf.org/archive/id/draft-schwartz-dnsop-dnssec-strict-mode-00.html
> 
> On Mon, Mar 21, 2022 at 12:06 PM Ulrich Wisser  wrote:
> Hi Ben,
> 
> The proposal is not to remove the possibility of double signatures, but to 
> relax the requirement so that other use cases become possible.
> 
> Our use case is the transition from one dns provider to another without going 
> insecure. If both use the same algorithm you can use the multi-signer dnssec 
> to do this. But if the signers only support a distinct set of algorithms you 
> are out of luck. 
> 
> As Libor pointed out, there are some implications to validation that must be 
> considered.
> 
> I would say, there are no obvious or easy solutions. But I think/hope that 
> DNSOP will be able to come up with some ideas that we can explore.
> 
> 
> /Ulrich
> 
> 
>> On 21 Mar 2022, at 10:32, Ben Schwartz  wrote:
>> 
>> I'm concerned about this.  Concretely, this seems like it would raise a 
>> major barrier to rolling out new algorithms.  For example, any zone that 
>> offers ECDSA and RSA signatures would be insecure for any RSA-only 
>> resolvers.  It's hard to see how new algorithms could be adopted at scale if 
>> this rule were in place.
>> 
>> On Sun, Mar 20, 2022 at 4:42 PM libor.peltan 
>>  wrote:
>> Hi Ulrich, dnsop,
>> thank you for your effort in improving DNS.
>> 
>> This is a follow-up to your proposal on easing the requirements by 
>> RFC4035, which say, in short, that if there's a DS of an algorithm, 
>> there must be a complete DNSKEY set of that algorithm, and if there is a 
>> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that 
>> algorithm.
>> 
>> The counter-proposal is to only require at least one valid 
>> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this 
>> would enable multi-signer setups with the signers supporting different 
>> algorithms, which in turn is beneficial to enable smooth transitions 
>> between such signers.
>> 
>> Let's suppose we go this way. How do we specify the validator behaviour 
>> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and 
>> the validator only understands algorithm A, but not B? I guess BOGUS 
>> will be no longer proper here, we would probably stick at INSECURE. Am I 
>> correct?
>> 
>> Now a different scenario. There are algorithm A and B DNSKEYs, the whole 
>> zone is also signed by both alg A and B RRSIGs, and the validator only 
>> understands alg A. Some man-in-the-middle attacker intercepts the 
>> answers by fiddling with the records, while removing algorithm A RRSIGs 
>> from the packets. The validator ends up with INSECURE and lets the 
>> attacker poison some cache...
>> 
>> With current DNSSEC requirements, it is enough for security if there is 
>> any intersection between the algorithms which the zone is signed by, and 
>> the algorithms supported by the validator, respectively. With your 
>> proposal, it would be required that the validator supports all the 
>> algorithms, which the zone is signed by.
>> 
>> I agree that in case the zone is signed by just one algorithm 
>> (occasionally 

Re: [DNSOP] On removing a pargraph in RFC4035

[Ben Schwartz]

If we assume the existing install base of resolvers isn't going away, then
I don't see how we could relax the requirement.  There are already deployed
resolvers enforcing it.  You would need a "flag day" to deprecate them,
which could not happen for many years.

This seems a lot harder than just telling your next DNS provider that you
can't do business with them until they implement another one of the (very
small number of) widely implemented algorithms.

Of course, I've personally argued for essentially the opposite of this
proposal [1].  Until DNSSEC has algorithmic agility without sacrificing
compatibility or security, it's only usable as "extra" security.

[1]
https://www.ietf.org/archive/id/draft-schwartz-dnsop-dnssec-strict-mode-00.html

On Mon, Mar 21, 2022 at 12:06 PM Ulrich Wisser  wrote:

> Hi Ben,
>
> The proposal is not to remove the possibility of double signatures, but to
> relax the requirement so that other use cases become possible.
>
> Our use case is the transition from one dns provider to another without
> going insecure. If both use the same algorithm you can use the multi-signer
> dnssec to do this. But if the signers only support a distinct set of
> algorithms you are out of luck.
>
> As Libor pointed out, there are some implications to validation that must
> be considered.
>
> I would say, there are no obvious or easy solutions. But I think/hope that
> DNSOP will be able to come up with some ideas that we can explore.
>
>
> /Ulrich
>
>
> On 21 Mar 2022, at 10:32, Ben Schwartz  wrote:
>
> I'm concerned about this.  Concretely, this seems like it would raise a
> major barrier to rolling out new algorithms.  For example, any zone that
> offers ECDSA and RSA signatures would be insecure for any RSA-only
> resolvers.  It's hard to see how new algorithms could be adopted at scale
> if this rule were in place.
>
> On Sun, Mar 20, 2022 at 4:42 PM libor.peltan  40nic...@dmarc.ietf.org> wrote:
>
>> Hi Ulrich, dnsop,
>> thank you for your effort in improving DNS.
>>
>> This is a follow-up to your proposal on easing the requirements by
>> RFC4035, which say, in short, that if there's a DS of an algorithm,
>> there must be a complete DNSKEY set of that algorithm, and if there is a
>> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that
>> algorithm.
>>
>> The counter-proposal is to only require at least one valid
>> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this
>> would enable multi-signer setups with the signers supporting different
>> algorithms, which in turn is beneficial to enable smooth transitions
>> between such signers.
>>
>> Let's suppose we go this way. How do we specify the validator behaviour
>> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and
>> the validator only understands algorithm A, but not B? I guess BOGUS
>> will be no longer proper here, we would probably stick at INSECURE. Am I
>> correct?
>>
>> Now a different scenario. There are algorithm A and B DNSKEYs, the whole
>> zone is also signed by both alg A and B RRSIGs, and the validator only
>> understands alg A. Some man-in-the-middle attacker intercepts the
>> answers by fiddling with the records, while removing algorithm A RRSIGs
>> from the packets. The validator ends up with INSECURE and lets the
>> attacker poison some cache...
>>
>> With current DNSSEC requirements, it is enough for security if there is
>> any intersection between the algorithms which the zone is signed by, and
>> the algorithms supported by the validator, respectively. With your
>> proposal, it would be required that the validator supports all the
>> algorithms, which the zone is signed by.
>>
>> I agree that in case the zone is signed by just one algorithm
>> (occasionally being rolled-over to just one different one), these
>> conditions are equivalent. Fortunately, it did not happen yet (or I'm
>> not aware of), that the existence of different validators with distinct
>> sets of supported algorithms forced signers to permanently sign zones
>> with two algorithms in parallel. The question is, if it remains so for
>> the future. I can't imagine what would happen in case of a "post-quantum
>> apocalypse", maybe it wouldn't be a problem, but it might.
>>
>> It would also cause the paradox and indeed creepy security quirk, that
>> if you sign your zone with one more algorithm, which is
>> cryptographically strong but poorly adopted (perhaps experimental), it
>> will result in _less_ security. Hardly anyone does this, but if they do,
>> they will be surprised, I think.
>>
>> Just to be clear, I don't want to fight against your ideas. I'm just
>> pointing at possible problems that could emerge.
>>
>> Thanks,
>> Libor
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list

Re: [DNSOP] On removing a pargraph in RFC4035

[Ulrich Wisser]

Hi Ben,

The proposal is not to remove the possibility of double signatures, but to 
relax the requirement so that other use cases become possible.

Our use case is the transition from one dns provider to another without going 
insecure. If both use the same algorithm you can use the multi-signer dnssec to 
do this. But if the signers only support a distinct set of algorithms you are 
out of luck. 

As Libor pointed out, there are some implications to validation that must be 
considered.

I would say, there are no obvious or easy solutions. But I think/hope that 
DNSOP will be able to come up with some ideas that we can explore.


/Ulrich


> On 21 Mar 2022, at 10:32, Ben Schwartz  wrote:
> 
> I'm concerned about this.  Concretely, this seems like it would raise a major 
> barrier to rolling out new algorithms.  For example, any zone that offers 
> ECDSA and RSA signatures would be insecure for any RSA-only resolvers.  It's 
> hard to see how new algorithms could be adopted at scale if this rule were in 
> place.
> 
> On Sun, Mar 20, 2022 at 4:42 PM libor.peltan 
> mailto:40nic...@dmarc.ietf.org>> wrote:
> Hi Ulrich, dnsop,
> thank you for your effort in improving DNS.
> 
> This is a follow-up to your proposal on easing the requirements by 
> RFC4035, which say, in short, that if there's a DS of an algorithm, 
> there must be a complete DNSKEY set of that algorithm, and if there is a 
> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that 
> algorithm.
> 
> The counter-proposal is to only require at least one valid 
> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this 
> would enable multi-signer setups with the signers supporting different 
> algorithms, which in turn is beneficial to enable smooth transitions 
> between such signers.
> 
> Let's suppose we go this way. How do we specify the validator behaviour 
> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and 
> the validator only understands algorithm A, but not B? I guess BOGUS 
> will be no longer proper here, we would probably stick at INSECURE. Am I 
> correct?
> 
> Now a different scenario. There are algorithm A and B DNSKEYs, the whole 
> zone is also signed by both alg A and B RRSIGs, and the validator only 
> understands alg A. Some man-in-the-middle attacker intercepts the 
> answers by fiddling with the records, while removing algorithm A RRSIGs 
> from the packets. The validator ends up with INSECURE and lets the 
> attacker poison some cache...
> 
> With current DNSSEC requirements, it is enough for security if there is 
> any intersection between the algorithms which the zone is signed by, and 
> the algorithms supported by the validator, respectively. With your 
> proposal, it would be required that the validator supports all the 
> algorithms, which the zone is signed by.
> 
> I agree that in case the zone is signed by just one algorithm 
> (occasionally being rolled-over to just one different one), these 
> conditions are equivalent. Fortunately, it did not happen yet (or I'm 
> not aware of), that the existence of different validators with distinct 
> sets of supported algorithms forced signers to permanently sign zones 
> with two algorithms in parallel. The question is, if it remains so for 
> the future. I can't imagine what would happen in case of a "post-quantum 
> apocalypse", maybe it wouldn't be a problem, but it might.
> 
> It would also cause the paradox and indeed creepy security quirk, that 
> if you sign your zone with one more algorithm, which is 
> cryptographically strong but poorly adopted (perhaps experimental), it 
> will result in _less_ security. Hardly anyone does this, but if they do, 
> they will be surprised, I think.
> 
> Just to be clear, I don't want to fight against your ideas. I'm just 
> pointing at possible problems that could emerge.
> 
> Thanks,
> Libor
> 
> ___
> 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] On removing a pargraph in RFC4035

[libor.peltan]

On the other hand, do you know any zones that permanently (other than 
active roll-over) sign with two algorithms in parallel? AFAIK this is 
_not_ the usual way how new algorithms are being rolled out. I guess new 
algorithms would continue to be adopted in the same way: first wide 
enough support in validators, second adoption (exclusive) by some 
pioneering zones who "risk" being insecure for older validators, third 
general adoption. I don't think it would be so huge an issue, but still 
a bit of an issue, as I described in the first e-mail.


Libor

Dne 21. 03. 22 v 10:32 Ben Schwartz napsal(a):
I'm concerned about this.  Concretely, this seems like it would raise 
a major barrier to rolling out new algorithms.  For example, any zone 
that offers ECDSA and RSA signatures would be insecure for any 
RSA-only resolvers.  It's hard to see how new algorithms could be 
adopted at scale if this rule were in place.


On Sun, Mar 20, 2022 at 4:42 PM libor.peltan 
 wrote:


Hi Ulrich, dnsop,
thank you for your effort in improving DNS.

This is a follow-up to your proposal on easing the requirements by
RFC4035, which say, in short, that if there's a DS of an algorithm,
there must be a complete DNSKEY set of that algorithm, and if
there is a
DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of
that
algorithm.

The counter-proposal is to only require at least one valid
DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how
this
would enable multi-signer setups with the signers supporting
different
algorithms, which in turn is beneficial to enable smooth transitions
between such signers.

Let's suppose we go this way. How do we specify the validator
behaviour
when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs,
and
the validator only understands algorithm A, but not B? I guess BOGUS
will be no longer proper here, we would probably stick at
INSECURE. Am I
correct?

Now a different scenario. There are algorithm A and B DNSKEYs, the
whole
zone is also signed by both alg A and B RRSIGs, and the validator
only
understands alg A. Some man-in-the-middle attacker intercepts the
answers by fiddling with the records, while removing algorithm A
RRSIGs
from the packets. The validator ends up with INSECURE and lets the
attacker poison some cache...

With current DNSSEC requirements, it is enough for security if
there is
any intersection between the algorithms which the zone is signed
by, and
the algorithms supported by the validator, respectively. With your
proposal, it would be required that the validator supports all the
algorithms, which the zone is signed by.

I agree that in case the zone is signed by just one algorithm
(occasionally being rolled-over to just one different one), these
conditions are equivalent. Fortunately, it did not happen yet (or I'm
not aware of), that the existence of different validators with
distinct
sets of supported algorithms forced signers to permanently sign zones
with two algorithms in parallel. The question is, if it remains so
for
the future. I can't imagine what would happen in case of a
"post-quantum
apocalypse", maybe it wouldn't be a problem, but it might.

It would also cause the paradox and indeed creepy security quirk,
that
if you sign your zone with one more algorithm, which is
cryptographically strong but poorly adopted (perhaps
experimental), it
will result in _less_ security. Hardly anyone does this, but if
they do,
they will be surprised, I think.

Just to be clear, I don't want to fight against your ideas. I'm just
pointing at possible problems that could emerge.

Thanks,
Libor

___
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] On removing a pargraph in RFC4035

[Ulrich Wisser]

Hi Libor,

You are absolutely right. The problem is not easily solved.

We will need a way to signal when this is ok and when not. 

My own security assessment goes like this:
If the domain is in transition from one signer to another and a resolver only 
supports one of the algorithms, the transition is either away from the 
supported algorithm or to a supported algorithm. So either the old state is 
insecure or the new state is insecure with regard to this resolver. So 
signaling to go insecure in case of missing rrsigs doesn’t make the situation 
worse, but is no improvement either.

But the signaling mechanism is an unsolved problem (so far).

/Ulrich






> thank you for your effort in improving DNS.
> 
> This is a follow-up to your proposal on easing the requirements by RFC4035, 
> which say, in short, that if there's a DS of an algorithm, there must be a 
> complete DNSKEY set of that algorithm, and if there is a DNSKEY of an 
> algorithm, the whole zone must be signed by RRSIGs of that algorithm.
> 
> The counter-proposal is to only require at least one valid DS-DNSKEY-RRSIG 
> path to sign each RR in the zone. I understand how this would enable 
> multi-signer setups with the signers supporting different algorithms, which 
> in turn is beneficial to enable smooth transitions between such signers.
> 
> Let's suppose we go this way. How do we specify the validator behaviour when 
> there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and the 
> validator only understands algorithm A, but not B? I guess BOGUS will be no 
> longer proper here, we would probably stick at INSECURE. Am I correct?
> 
> Now a different scenario. There are algorithm A and B DNSKEYs, the whole zone 
> is also signed by both alg A and B RRSIGs, and the validator only understands 
> alg A. Some man-in-the-middle attacker intercepts the answers by fiddling 
> with the records, while removing algorithm A RRSIGs from the packets. The 
> validator ends up with INSECURE and lets the attacker poison some cache...
> 
> With current DNSSEC requirements, it is enough for security if there is any 
> intersection between the algorithms which the zone is signed by, and the 
> algorithms supported by the validator, respectively. With your proposal, it 
> would be required that the validator supports all the algorithms, which the 
> zone is signed by.
> 
> I agree that in case the zone is signed by just one algorithm (occasionally 
> being rolled-over to just one different one), these conditions are 
> equivalent. Fortunately, it did not happen yet (or I'm not aware of), that 
> the existence of different validators with distinct sets of supported 
> algorithms forced signers to permanently sign zones with two algorithms in 
> parallel. The question is, if it remains so for the future. I can't imagine 
> what would happen in case of a "post-quantum apocalypse", maybe it wouldn't 
> be a problem, but it might.
> 
> It would also cause the paradox and indeed creepy security quirk, that if you 
> sign your zone with one more algorithm, which is cryptographically strong but 
> poorly adopted (perhaps experimental), it will result in _less_ security. 
> Hardly anyone does this, but if they do, they will be surprised, I think.
> 
> Just to be clear, I don't want to fight against your ideas. I'm just pointing 
> at possible problems that could emerge.
> 
> Thanks,
> Libor
> 

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

Re: [DNSOP] On removing a pargraph in RFC4035

[Ben Schwartz]

I'm concerned about this.  Concretely, this seems like it would raise a
major barrier to rolling out new algorithms.  For example, any zone that
offers ECDSA and RSA signatures would be insecure for any RSA-only
resolvers.  It's hard to see how new algorithms could be adopted at scale
if this rule were in place.

On Sun, Mar 20, 2022 at 4:42 PM libor.peltan  wrote:

> Hi Ulrich, dnsop,
> thank you for your effort in improving DNS.
>
> This is a follow-up to your proposal on easing the requirements by
> RFC4035, which say, in short, that if there's a DS of an algorithm,
> there must be a complete DNSKEY set of that algorithm, and if there is a
> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that
> algorithm.
>
> The counter-proposal is to only require at least one valid
> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this
> would enable multi-signer setups with the signers supporting different
> algorithms, which in turn is beneficial to enable smooth transitions
> between such signers.
>
> Let's suppose we go this way. How do we specify the validator behaviour
> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and
> the validator only understands algorithm A, but not B? I guess BOGUS
> will be no longer proper here, we would probably stick at INSECURE. Am I
> correct?
>
> Now a different scenario. There are algorithm A and B DNSKEYs, the whole
> zone is also signed by both alg A and B RRSIGs, and the validator only
> understands alg A. Some man-in-the-middle attacker intercepts the
> answers by fiddling with the records, while removing algorithm A RRSIGs
> from the packets. The validator ends up with INSECURE and lets the
> attacker poison some cache...
>
> With current DNSSEC requirements, it is enough for security if there is
> any intersection between the algorithms which the zone is signed by, and
> the algorithms supported by the validator, respectively. With your
> proposal, it would be required that the validator supports all the
> algorithms, which the zone is signed by.
>
> I agree that in case the zone is signed by just one algorithm
> (occasionally being rolled-over to just one different one), these
> conditions are equivalent. Fortunately, it did not happen yet (or I'm
> not aware of), that the existence of different validators with distinct
> sets of supported algorithms forced signers to permanently sign zones
> with two algorithms in parallel. The question is, if it remains so for
> the future. I can't imagine what would happen in case of a "post-quantum
> apocalypse", maybe it wouldn't be a problem, but it might.
>
> It would also cause the paradox and indeed creepy security quirk, that
> if you sign your zone with one more algorithm, which is
> cryptographically strong but poorly adopted (perhaps experimental), it
> will result in _less_ security. Hardly anyone does this, but if they do,
> they will be surprised, I think.
>
> Just to be clear, I don't want to fight against your ideas. I'm just
> pointing at possible problems that could emerge.
>
> Thanks,
> Libor
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop