Re: [dns-operations] help with a resolution

[Viktor Dukhovni]

On Fri, Jan 10, 2020 at 08:09:20PM +0530, Mukund Sivaraman wrote:

> > > If there is a default, it should promptly change to 8 or 13.
> > 
> > I will prioritize it.
> 
> This work has been merged now in Loop, to match the recommendations of
> RFC 8624:
> 
> * dnssec-keygen by default creates ECDSAP256SHA256 keys
> * dnssec-dsfromkey by default generates DS with SHA-256 and SHA-384 digests
> * dnssec-dsfromkey cannot be used to create DS with a SHA-1 digest
> * dnssec-keygen -3 argument has been removed (redundant with -a)
> * dnssec-dsfromkey -1 and -2 arguments have been removed (redundant with -a)
> * Documentation and tests were updated for the above

This is welcome news.  Many thanks.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Thu, Jan 09, 2020 at 12:38:05PM +0530, Mukund Sivaraman wrote:
> > > Loop's toolchain has had the default algorithms so, which it inherited. 
> > > There
> > > is a branch that changes the defaults, but it won't be merged in the first
> > > quarter of this year.
> > 
> > If there is a default, it should promptly change to 8 or 13.
> 
> I will prioritize it.

This work has been merged now in Loop, to match the recommendations of
RFC 8624:

* dnssec-keygen by default creates ECDSAP256SHA256 keys
* dnssec-dsfromkey by default generates DS with SHA-256 and SHA-384 digests
* dnssec-dsfromkey cannot be used to create DS with a SHA-1 digest
* dnssec-keygen -3 argument has been removed (redundant with -a)
* dnssec-dsfromkey -1 and -2 arguments have been removed (redundant with -a)
* Documentation and tests were updated for the above

[muks@jurassic ~/tmp-dnssec]$ dnssec-keygen example.org
Generating key pair.
Kexample.org.+013+21773
[muks@jurassic ~/tmp-dnssec]$ cat Kexample.org.+013+21773.key 
; This is a zone-signing key, keyid 21773, for example.org.
; Created: 20200110143300 (Fri Jan 10 20:03:00 2020)
; Publish: 20200110143300 (Fri Jan 10 20:03:00 2020)
; Activate: 20200110143300 (Fri Jan 10 20:03:00 2020)
example.org. IN DNSKEY 256 3 13 
X5t7zeDf1PSTfkXbZBXcEJUK0PU15GlNlANqSDt9GsTL68FkA4R2H66D 
zaz+Xeqe+wZKJikqcpSeQweDbJ7tEA==
[muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+013+21773
example.org. IN DS 21773 13 2 
86A48213B13F14A92865CFDAB9D0F6536979609729018DA52EED4684D110A95E
example.org. IN DS 21773 13 4 
21A134504A1553844B86D01FBB4F8B383BF2924CCC82BE54D7ABD371F45C33FF5E602CA02168C9AB7915B1D14F60A201
[muks@jurassic ~/tmp-dnssec]$ 

The RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms are still available for
selection during key generation using dnssec-keygen -a. We will wait for
dnsop activity before removing them. Separately, the resolver's
validator continues to support them.

The dist builder has been triggered; packages will appear in the
repositories in a few hours after the platform workers finish their
builds and tests.

It appears that the dnssec-* programs ought to be renamed so that
there's no confusion with BIND's utilities. There's already a bug
ticket. I will make a note on it.

(BTW, thank you for kindly mentioning that the default should be
promptly changed, and not being overly critical as RFC 8624 has been out
for ~7 months now. It is much appreciated.)

   Mukund


signature.asc
Description: PGP signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 01:45:44PM -0500, Viktor Dukhovni wrote:
> On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote:
> 
> > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > > > example.org. IN DS 4222 5 2 
> > > > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> > > 
> > > Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> > > deployments.  The current best-practice choices are algorithm 8 (RSA
> > > with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> > > SHA2-256).
> >
> > You are absolutely right and algorithm 13 is best suited.
> 
> And with the latest news about SHA-1 chosen-prefix attacks, algorithm 5 now
> really needs to be avoided.
> 
> > It was really not an example to pick an algorithm, but to demonstrate
> > how to verify a zone which the poster asked. No algorithm arguments were
> > passed.
> 
> Sure, but you were also advising against the SHA-1 DS digest type (still
> reasonably safe) in an example that used algorithm 5 with its now rather
> weakened RSASHA1 signature.  I think that warranted a comment, just in
> case anyway walked away with the wrong impression.

You're right of course that algorithm 13 ought to be used in preference.

> 
> - Algorithms 5 and 7 are now seriously wounded, though perhaps not
>   yet in all use-cases dead.
> 
> - DS algorithm 1 is tarnished and not recommended, but there are
>   no known attacks.
> 
> > Loop's toolchain has had the default algorithms so, which it inherited. 
> > There
> > is a branch that changes the defaults, but it won't be merged in the first
> > quarter of this year.
> 
> If there is a default, it should promptly change to 8 or 13.

I will prioritize it.


> > > Instead, the attacks are against SHA-1 based *signature* algorithms, where
> > > the key-holder (typically parent zone) signs data that is partly under the
> > > control of potentially hostile others.  So the important thing is avoiding
> > > algorithms 5 and 7, NOT avoiding digest type 1.
> > 
> > The mail only said SHA-1 is weakening in security day by day. A better 
> > choice
> > is available and widely supported which is digest 2, which was printed by 
> > the
> > default run of dnssec-dsfromkey in the example and explained as preferrable.
> 
> See above, yes SHA-1 is tarnished, but its is as a DS digest type is not the
> reason, there are no known attacks there, the real issue is DNSKEY algorithms
> 5 and 7.
> 
> > With the chosen-prefix collision attack, a rogue actor who is in charge of
> > creating KSKs may create 2 KSKs that generate the same DS SHA-1 digest 
> > field.
> 
> If you have a rogue actor controlling your KSKs, all bets are off.

> 
> > He may then submit and deploy the 1st key at his workplace and then sell the
> > 2nd key that would lead a different paper trail than the first
> 
> I don't see the point, why not just sell the real key, what difference does it
> make.  Indeed if the second key gets discovered, then it is clear the keys
> were cooked, and who the guilty party is.  But with a leak of the single
> legitimate key, it is far less clear a-priori who leaked the key.
> 
> > MD5 also doesn't have a practical second pre-image attack, but it was not
> > added as a DS digest.
> 
> Indeed, we avoid new uses of tarnished algorithms.
> 
> > Having read many of your posts, I greatly respect your opinion. It seems
> > unnatural to me that you would use SHA-1 as a DS digest type today, or not
> > advise a friend to switch from it if you saw it being used.
> 
> I would not introduce new uses of SHA-1 in DS RRs.  Below is my complete
> DS RRset:
> 
> dukhovni.org. IN DS 34314 13 2 
> 1efe87df8925417c29df1791b0ea495550acb2ff76515cc3005863497ef6b9d2
> 
> my point is that if you do have a SHA-1 DS RR, that's not an immediate
> problem, but algorithms 5 and 7, especially in zones that sign other
> people's data, are a much more immediate probem, and because it is
> difficult to explain which use-case of 5 and 7 are still safe, and which
> are not, the priority is to deprecate these DNSKEY algorithms.
> 
> We can also discourage SHA-1 as a DS digest type, but only out of an
> abundance of caution, we now have better algorithms in which we have
> more confidence.  There's no known practical threat, the algorithm still
> offers around 160 bits of 2nd pre-image resistance and is well out of
> reach of any known attacks.
> 
> -- 
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>

Mukund
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 08:07:22PM +, Paul Vixie wrote:
> On Wednesday, 8 January 2020 18:45:44 UTC Viktor Dukhovni wrote:
> 
> > > Loop's toolchain has had the default algorithms so, which it inherited.
> > > There is a branch that changes the defaults, but it won't be merged in
> > > the first quarter of this year.
> > 
> > If there is a default, it should promptly change to 8 or 13.
> 
> there should be a default, and it should move forward over time.

I will prioritize updating the default algorithms now.

  Mukund
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Viktor Dukhovni]

On Wed, Jan 08, 2020 at 02:53:42PM -0500, Warren Kumari wrote:

> Can someone please explain to me in baby words how the SHA-1 issue affects
> DNSSEC? [...] but SHA-1 is still 2nd-preimage resistant - given the hash
> a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find another
> message which hashes to this.

That's still true, but the attack leverages chosen-prefix collisions against
signatures, in which the tail of the data signed is controlled by an attacker.
Not 2nd pre-image attacks on a hash of a trusted message.

> So, I *could* see an attacker being able to make 2 records or keys
> which have the same hash -- but, meh, that's not actually useful to
> them.

Well, there's your mistake, because with "chosen-prefix" attacks, the second
RRset being signed need not have the same owner or type, thus a weird TXT
RRset for a benign owner may SHA-1 hash to the same value as an attacker
selected DNSKEY RRset for the zone (that includes a KSK matching the DS
RR, but also keys controlled by the attacker).

> eg: The DS for dns-oarc.net is: 20899 8 1
> 6714FF6879371C5DC19BB0389F9D497520448A2E - an attacker cannot make a
> new key which hashes to this.

Yes, that's why I decided to follow up on Mukun'd post.  Digest type
1 (SHA-1) in DS RRs is mostly harmless, though again not recommended.

> They could in theory make 2 DNSKEYs
> which have the same hash (although, because of the format of DNSKEYs I
> don't think they can do this in practice),

No, they could do much worse, they could make a TXT RRset, that
secretly matches a DNSKEY RRset (at least for a given signature
period, the collision will break once the RRset is resigned with
a different inception/expiration interval).

> I'm feeling like I'm missing something obvious here...

See above.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Paul Vixie]

On Wednesday, 8 January 2020 18:45:44 UTC Viktor Dukhovni wrote:

> > Loop's toolchain has had the default algorithms so, which it inherited.
> > There is a branch that changes the defaults, but it won't be merged in
> > the first quarter of this year.
> 
> If there is a default, it should promptly change to 8 or 13.

there should be a default, and it should move forward over time.

-- 
Paul


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Warren Kumari]

On Wed, Jan 8, 2020 at 1:54 PM Viktor Dukhovni  wrote:
>
> On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote:
>
> > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > > > example.org. IN DS 4222 5 2 
> > > > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> > >
> > > Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> > > deployments.  The current best-practice choices are algorithm 8 (RSA
> > > with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> > > SHA2-256).
> >
> > You are absolutely right and algorithm 13 is best suited.
>
> And with the latest news about SHA-1 chosen-prefix attacks, algorithm 5 now
> really needs to be avoided.
>

Can someone please explain to me in baby words how the SHA-1 issue
affects DNSSEC? Yes, I'm all for banging the "Move to a newer hash"
drum, but I'm still failing to see how this can be used against DNSSEC
-- from what I understand, an attacker can generate a hash collision
(2 inputs which hash to the same output), but SHA-1 is still
2nd-preimage resistant - given the hash
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find
another message which hashes to this.

So, I *could* see an attacker being able to make 2 records or keys
which have the same hash -- but, meh, that's not actually useful to
them.

eg: The DS for dns-oarc.net is: 20899 8 1
6714FF6879371C5DC19BB0389F9D497520448A2E - an attacker cannot make a
new key which hashes to this. They could in theory make 2 DNSKEYs
which have the same hash (although, because of the format of DNSKEYs I
don't think they can do this in practice), but that just allows them
to replace a zone *which they control* with another zone *which they
also control*.

I'm feeling like I'm missing something obvious here...

W


> > It was really not an example to pick an algorithm, but to demonstrate
> > how to verify a zone which the poster asked. No algorithm arguments were
> > passed.
>
> Sure, but you were also advising against the SHA-1 DS digest type (still
> reasonably safe) in an example that used algorithm 5 with its now rather
> weakened RSASHA1 signature.  I think that warranted a comment, just in
> case anyway walked away with the wrong impression.
>
> - Algorithms 5 and 7 are now seriously wounded, though perhaps not
>   yet in all use-cases dead.
>
> - DS algorithm 1 is tarnished and not recommended, but there are
>   no known attacks.
>
> > Loop's toolchain has had the default algorithms so, which it inherited. 
> > There
> > is a branch that changes the defaults, but it won't be merged in the first
> > quarter of this year.
>
> If there is a default, it should promptly change to 8 or 13.
>
> > > Instead, the attacks are against SHA-1 based *signature* algorithms, where
> > > the key-holder (typically parent zone) signs data that is partly under the
> > > control of potentially hostile others.  So the important thing is avoiding
> > > algorithms 5 and 7, NOT avoiding digest type 1.
> >
> > The mail only said SHA-1 is weakening in security day by day. A better 
> > choice
> > is available and widely supported which is digest 2, which was printed by 
> > the
> > default run of dnssec-dsfromkey in the example and explained as preferrable.
>
> See above, yes SHA-1 is tarnished, but its is as a DS digest type is not the
> reason, there are no known attacks there, the real issue is DNSKEY algorithms
> 5 and 7.
>
> > With the chosen-prefix collision attack, a rogue actor who is in charge of
> > creating KSKs may create 2 KSKs that generate the same DS SHA-1 digest 
> > field.
>
> If you have a rogue actor controlling your KSKs, all bets are off.
>
> > He may then submit and deploy the 1st key at his workplace and then sell the
> > 2nd key that would lead a different paper trail than the first
>
> I don't see the point, why not just sell the real key, what difference does it
> make.  Indeed if the second key gets discovered, then it is clear the keys
> were cooked, and who the guilty party is.  But with a leak of the single
> legitimate key, it is far less clear a-priori who leaked the key.
>
> > MD5 also doesn't have a practical second pre-image attack, but it was not
> > added as a DS digest.
>
> Indeed, we avoid new uses of tarnished algorithms.
>
> > Having read many of your posts, I greatly respect your opinion. It seems
> > unnatural to me that you would use SHA-1 as a DS digest type today, or not
> > advise a friend to switch from it if you saw it being used.
>
> I would not introduce new uses of SHA-1 in DS RRs.  Below is my complete
> DS RRset:
>
> dukhovni.org. IN DS 34314 13 2 
> 1efe87df8925417c29df1791b0ea495550acb2ff76515cc3005863497ef6b9d2
>
> my point is that if you do have a SHA-1 DS RR, that's not an immediate
> problem, but algorithms 5 and 7, especially in zones that sign other
> people's data, are a much more immediate 

Re: [dns-operations] help with a resolution

[Viktor Dukhovni]

On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote:

> > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > > example.org. IN DS 4222 5 2 
> > > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> > 
> > Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> > deployments.  The current best-practice choices are algorithm 8 (RSA
> > with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> > SHA2-256).
>
> You are absolutely right and algorithm 13 is best suited.

And with the latest news about SHA-1 chosen-prefix attacks, algorithm 5 now
really needs to be avoided.

> It was really not an example to pick an algorithm, but to demonstrate
> how to verify a zone which the poster asked. No algorithm arguments were
> passed.

Sure, but you were also advising against the SHA-1 DS digest type (still
reasonably safe) in an example that used algorithm 5 with its now rather
weakened RSASHA1 signature.  I think that warranted a comment, just in
case anyway walked away with the wrong impression.

- Algorithms 5 and 7 are now seriously wounded, though perhaps not
  yet in all use-cases dead.

- DS algorithm 1 is tarnished and not recommended, but there are
  no known attacks.

> Loop's toolchain has had the default algorithms so, which it inherited. There
> is a branch that changes the defaults, but it won't be merged in the first
> quarter of this year.

If there is a default, it should promptly change to 8 or 13.

> > Instead, the attacks are against SHA-1 based *signature* algorithms, where
> > the key-holder (typically parent zone) signs data that is partly under the
> > control of potentially hostile others.  So the important thing is avoiding
> > algorithms 5 and 7, NOT avoiding digest type 1.
> 
> The mail only said SHA-1 is weakening in security day by day. A better choice
> is available and widely supported which is digest 2, which was printed by the
> default run of dnssec-dsfromkey in the example and explained as preferrable.

See above, yes SHA-1 is tarnished, but its is as a DS digest type is not the
reason, there are no known attacks there, the real issue is DNSKEY algorithms
5 and 7.

> With the chosen-prefix collision attack, a rogue actor who is in charge of
> creating KSKs may create 2 KSKs that generate the same DS SHA-1 digest field.

If you have a rogue actor controlling your KSKs, all bets are off.

> He may then submit and deploy the 1st key at his workplace and then sell the
> 2nd key that would lead a different paper trail than the first

I don't see the point, why not just sell the real key, what difference does it
make.  Indeed if the second key gets discovered, then it is clear the keys
were cooked, and who the guilty party is.  But with a leak of the single
legitimate key, it is far less clear a-priori who leaked the key.

> MD5 also doesn't have a practical second pre-image attack, but it was not
> added as a DS digest.

Indeed, we avoid new uses of tarnished algorithms.

> Having read many of your posts, I greatly respect your opinion. It seems
> unnatural to me that you would use SHA-1 as a DS digest type today, or not
> advise a friend to switch from it if you saw it being used.

I would not introduce new uses of SHA-1 in DS RRs.  Below is my complete
DS RRset:

dukhovni.org. IN DS 34314 13 2 
1efe87df8925417c29df1791b0ea495550acb2ff76515cc3005863497ef6b9d2

my point is that if you do have a SHA-1 DS RR, that's not an immediate
problem, but algorithms 5 and 7, especially in zones that sign other
people's data, are a much more immediate probem, and because it is
difficult to explain which use-case of 5 and 7 are still safe, and which
are not, the priority is to deprecate these DNSKEY algorithms.

We can also discourage SHA-1 as a DS digest type, but only out of an
abundance of caution, we now have better algorithms in which we have
more confidence.  There's no known practical threat, the algorithm still
offers around 160 bits of 2nd pre-image resistance and is well out of
reach of any known attacks.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

Hi Viktor

On Wed, Jan 08, 2020 at 10:05:53AM -0500, Viktor Dukhovni wrote:
> On Wed, Jan 08, 2020 at 08:11:56PM +0530, Mukund Sivaraman wrote:
> 
> > [muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
> > Generating key pair..+ .+ 
> > Kexample.org.+005+04222
> >
> > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > example.org. IN DS 4222 5 2 
> > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> 
> Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> deployments.  The current best-practice choices are algorithm 8 (RSA
> with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> SHA2-256).
> 
> Of these two, I'd recommend algorithm 13, because it produces signatures
> that are more secure and substantially more compact.  Indeed algorithm
> 13 is now the most popular algorithm among signed domains, having
> recently surpassed 8:
> 
> https://stats.dnssec-tools.org/#parameter
> 
> Algorithm 5 is a very distant 4th.

You are absolutely right and algorithm 13 is best suited.

It was really not an example to pick an algorithm, but to demonstrate
how to verify a zone which the poster asked. No algorithm arguments were
passed.

Loop's toolchain has had the default algorithms so, which it
inherited. There is a branch that changes the defaults, but it won't be
merged in the first quarter of this year.

I think BIND's dnssec-keygen requires you to specify the algorithm now,
so the poster will likely need to provide it.

> > Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
> > for SHA-1 hash which is weakening in security day by day, so you would
> > probably want to add only the "5 2" RR from above, where 2 stands for
> > SHA-256. A complete list of these is here:
> > https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
> 
> This is wrong.  The attacks are not against the digest algorithm that's
> hashing the key.  With the DS RR digest types there are no collision
> issues, and only SHA-1 2nd-preimage resistance matters, which remains
> unbroken.
> 
> Instead, the attacks are against SHA-1 based *signature* algorithms,
> where the key-holder (typically parent zone) signs data that is partly
> under the control of potentially hostile others.  So the important
> thing is avoiding algorithms 5 and 7, NOT avoiding digest type 1.

The mail only said SHA-1 is weakening in security day by day. A better
choice is available and widely supported which is digest 2, which was
printed by the default run of dnssec-dsfromkey in the example and
explained as preferrable.



On the topic of the recent "SHA-1 is a Shambles" ePrint paper and the
dnsop thread about how it affects DNSSEC, perhaps I may have understood
what you have pictured by DS needing second pre-image resistance, but
there are different sorts of situations and once a digest's security has
weakened so much, it is basically to be avoided. With the chosen-prefix
collision attack, a rogue actor who is in charge of creating KSKs may
create 2 KSKs that generate the same DS SHA-1 digest field. He may then
submit and deploy the 1st key at his workplace and then sell the 2nd key
that would lead a different paper trail than the first - a leak of the
first KSK may not be possible by other safeguards, or be discovered from
observed rogue signatures, but the existence of the second KSK may not
be known or suspected. It may not matter to a particular use case or
line of thinking, but cryptography security is about preventing every
circumstance.

MD5 also doesn't have a practical second pre-image attack, but it was
not added as a DS digest.

Having read many of your posts, I greatly respect your opinion. It seems
unnatural to me that you would use SHA-1 as a DS digest type today, or
not advise a friend to switch from it if you saw it being used.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Stephane Bortzmeyer]

On Wed, Jan 08, 2020 at 07:05:04PM +0800,
 William C  wrote 
 a message of 15 lines which said:

> 1. how to check if a zone has a valid DNSSEC key?

If you are not a DNSSEC expert, DNSviz is a handy tool 

> 2. how to validate if the zone has been signed with correct key?

DNSviz again. Otherwise, regular DNS resolution, using a validating
resolver.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Viktor Dukhovni]

On Wed, Jan 08, 2020 at 08:11:56PM +0530, Mukund Sivaraman wrote:

> [muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
> Generating key pair..+ .+ 
> Kexample.org.+005+04222
>
> [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> example.org. IN DS 4222 5 2 
> 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831

Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
deployments.  The current best-practice choices are algorithm 8 (RSA
with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
SHA2-256).

Of these two, I'd recommend algorithm 13, because it produces signatures
that are more secure and substantially more compact.  Indeed algorithm
13 is now the most popular algorithm among signed domains, having
recently surpassed 8:

https://stats.dnssec-tools.org/#parameter

Algorithm 5 is a very distant 4th.

> Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
> for SHA-1 hash which is weakening in security day by day, so you would
> probably want to add only the "5 2" RR from above, where 2 stands for
> SHA-256. A complete list of these is here:
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

This is wrong.  The attacks are not against the digest algorithm that's
hashing the key.  With the DS RR digest types there are no collision
issues, and only SHA-1 2nd-preimage resistance matters, which remains
unbroken.

Instead, the attacks are against SHA-1 based *signature* algorithms,
where the key-holder (typically parent zone) signs data that is partly
under the control of potentially hostile others.  So the important
thing is avoiding algorithms 5 and 7, NOT avoiding digest type 1.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 07:05:04PM +0800, William C wrote:
> Thanks all for explains.
> I am new to DNSSEC, so I have questions:
> 
> 1. how to check if a zone has a valid DNSSEC key?

The hash in the DS record in the parent zone should correspond to the
DNSKEY at the apex of your (child) zone.

So, for example, if you have generated your DNSKEY using BIND's
dnssec-keygen utility, you can use the dnssec-dsfromkey to generate DS
records for such keys.

The following is an example that prints a DNSKEY's corresponding DS
records (I'm using Loop's utilities which are similar with some small
differences):

[muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
Generating key pair..+ .+ 
Kexample.org.+005+04222
[muks@jurassic ~/tmp-dnssec]$ ls
Kexample.org.+005+04222.key  Kexample.org.+005+04222.private
[muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
example.org. IN DS 4222 5 2 
06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
[muks@jurassic ~/tmp-dnssec]$ 

The DS records printed should be added to the parent zone (e.g., if your
zone's parent is a top-level zone such as com., you would typically add
these DS records using the registrar's interface).

Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
for SHA-1 hash which is weakening in security day by day, so you would
probably want to add only the "5 2" RR from above, where 2 stands for
SHA-256. A complete list of these is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

> 2. how to validate if the zone has been signed with correct key?

If you have a signed zone in master file format (such as generated by
BIND's dnssec-signzone utility), you may verify the signatures using
dnssec-verify. For example, let's create an example zone and sign it
using the KSK key above:

[muks@jurassic ~/tmp-dnssec]$ echo "example.org. 3600 IN SOA . . 1 3600 3600 
3600 3600" > example.org.zone
[muks@jurassic ~/tmp-dnssec]$ echo "example.org. NS ns1.example.com." >> 
example.org.zone
[muks@jurassic ~/tmp-dnssec]$ dnssec-signzone -z -S -o example.org 
example.org.zone 
dnssec-signzone: warning: example.org.zone:2: using RFC1035 TTL semantics
Fetching KSK/ZSK 4222/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 stand-by, 0 revoked
example.org.zone.signed
[muks@jurassic ~/tmp-dnssec]$ 

Let's verify the signed zone against the KSK:

[muks@jurassic ~/tmp-dnssec]$ dnssec-verify -x -o example.org 
example.org.zone.signed Kexample.org.+005+49357
Loading zone 'example.org' from file 'example.org.zone.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked
[muks@jurassic ~/tmp-dnssec]$ 

Please read the manpages of dnssec-keygen, dnssec-signzone, and
dnssec-verify on why the arguments above were used. Typically you would
use a second DNSKEY called a ZSK in your zones, and you wouldn't have to
use the arguments above.

Finally, delv and dig +trace are useful to check what your network sees
of the public DNS data.

  Mukund
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[William C]

Thanks all for explains.
I am new to DNSSEC, so I have questions:

1. how to check if a zone has a valid DNSSEC key?
2. how to validate if the zone has been signed with correct key?

Regards.



on 2020/1/8 19:00, Stephane Bortzmeyer wrote:

As explained by several experts, this domain is DNSSEC-broken. This
has nothing to to with the public resolvers (on my own local resolver,
it fails as well), any resolver which validates signatures (they
should all do it) will have the same problem.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Stephane Bortzmeyer]

On Wed, Jan 08, 2020 at 08:56:41AM +0800,
 William C  wrote 
 a message of 59 lines which said:

> Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9
> etc) can't resolve this domain?

As explained by several experts, this domain is DNSSEC-broken. This
has nothing to to with the public resolvers (on my own local resolver,
it fails as well), any resolver which validates signatures (they
should all do it) will have the same problem.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Viktor Dukhovni]

On Tue, Jan 07, 2020 at 08:37:45PM -0500, Viktor Dukhovni wrote:

> That's easy, the domain is delegated signed:
> 
> pike-aviation.com. IN DS 41388 7 1 
> fc9228e1b977dcd5c830a5c0101532e225e173cf

FWIW, the DS RRset and DNSKEYs have been in place since ~2018-01-10.

  domain   | alg | flags | inception  | bits 
 --+-+---++--
 pike-aviation.com |   7 |   256 | 2018-01-10 | 1024
 pike-aviation.com |   7 |   256 | 2018-01-10 | 1024
 pike-aviation.com |   7 |   257 | 2018-01-10 | 2048

DNSKEY lookups have been failing since ~2019-12-23:

  domain   | rtype |  failtime
 --+---+
 pike-aviation.com |48 | 2019-12-23

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Warren Kumari]

Your DNSSEC is broken - see https://dnsviz.net/d/pike-aviation.com/dnssec/

.com says that the domain is signed (with keyid 41388), but there is
no DNSKEY in the zone.
W

On Tue, Jan 7, 2020 at 8:33 PM William C  wrote:
>
> Hi
>
> Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9
> etc) can't resolve this domain?
>
> $ dig pike-aviation.com @8.8.8.8
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;pike-aviation.com. IN  A
>
> ;; Query time: 17 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Jan 08 08:53:56 CST 2020
> ;; MSG SIZE  rcvd: 46
>
>
> But the domain's auth servers did respond it.
>
> $ dig pike-aviation.com @ns70.domaincontrol.com
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @ns70.domaincontrol.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5923
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1472
> ;; QUESTION SECTION:
> ;pike-aviation.com. IN  A
>
> ;; ANSWER SECTION:
> pike-aviation.com.  3600IN  A   67.205.137.55
>
> ;; AUTHORITY SECTION:
> pike-aviation.com.  3600IN  NS  ns70.domaincontrol.com.
> pike-aviation.com.  3600IN  NS  ns69.domaincontrol.com.
>
> ;; Query time: 10 msec
> ;; SERVER: 173.201.72.45#53(173.201.72.45)
> ;; WHEN: Wed Jan 08 08:55:58 CST 2020
> ;; MSG SIZE  rcvd: 114
>
>
>
> Thank you.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Viktor Dukhovni]

On Wed, Jan 08, 2020 at 08:56:41AM +0800, William C wrote:

> Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9 
> etc) can't resolve this domain?
> 
> $ dig pike-aviation.com @8.8.8.8
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133

That's easy, the domain is delegated signed:

pike-aviation.com. IN DS 41388 7 1 fc9228e1b977dcd5c830a5c0101532e225e173cf

but a query for its zone apex DNSKEY RRset returns:

pike-aviation.com. IN SOA ns69.domaincontrol.com. d...@jomax.net. 
2020010702 28800 7200 604800 600

so the entire domain is "bogus":

https://dnsviz.net/d/pike-aviation.com/dnssec/

so either publish a DNSKEY RRset that includes and is signed by a
key that matches the DS RRset, and then sign the rest of the zone
with one of the keys in that RRset, OR else ask your registrar to
request a drop of the DS RRset from the .com zone.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] help with a resolution

[William C]

Hi

Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9 
etc) can't resolve this domain?


$ dig pike-aviation.com @8.8.8.8

; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pike-aviation.com. IN  A

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 08 08:53:56 CST 2020
;; MSG SIZE  rcvd: 46


But the domain's auth servers did respond it.

$ dig pike-aviation.com @ns70.domaincontrol.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @ns70.domaincontrol.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5923
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;pike-aviation.com. IN  A

;; ANSWER SECTION:
pike-aviation.com.  3600IN  A   67.205.137.55

;; AUTHORITY SECTION:
pike-aviation.com.  3600IN  NS  ns70.domaincontrol.com.
pike-aviation.com.  3600IN  NS  ns69.domaincontrol.com.

;; Query time: 10 msec
;; SERVER: 173.201.72.45#53(173.201.72.45)
;; WHEN: Wed Jan 08 08:55:58 CST 2020
;; MSG SIZE  rcvd: 114



Thank you.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations