Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 07:31:04PM -0700, Phillip Hallam-Baker wrote:

> Looks like the 'downgrade attack' is actually a consequence of the fact
> that support for multiple algorithms means that you end up with the
> security of the weakest. So not really an 'attack' but a consequence of the
> design approach not considering the downgrade issue worth addressing
> because people should not be signing under multiple algorithms for very
> long.

No, the downgrade in question is not from a stronger algoritm to a
weaker (generally accepted, because multi-algorithm signed zones are a
short-term affair), rather, it is a downgrade from "signed" to
"unsigned", which is a serious implementation error.  The paper's
authors did not break any crypto, they just sent replies that some
implementers failed to anticipate (for plausible lack of clear explicit,
however obvious it should have been, advice in RFC 4035).

> But given that, I think we are long past the time when anyone is doing
> anything of the slightest value signing with SHA-1. There is no reason to
> pick SHA-1 over SHA-2. You are not going to improve interop, you are much
> more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to
> go.

Again, SHA-1 has nothing to do with this.  It is already NOT RECOMMENDED
(i.e. SHOULD NOT) for signing:

https://stats.dnssec-tools.org/explore/?ietf.org
https://www.rfc-editor.org/rfc/rfc8624#section-3

but still a MUST for validation.  The numbers have improved a lot since
the RFC was published, see the algorithm counts under "DNSSEC parameter
frequency analysis" at:

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

but we're not quite there yet:

https://stats.dnssec-tools.org/explore/?nsa.gov
https://stats.dnssec-tools.org/explore/?icann.org
...

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

Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Phillip Hallam-Baker]

Looks like the 'downgrade attack' is actually a consequence of the fact
that support for multiple algorithms means that you end up with the
security of the weakest. So not really an 'attack' but a consequence of the
design approach not considering the downgrade issue worth addressing
because people should not be signing under multiple algorithms for very
long.

But given that, I think we are long past the time when anyone is doing
anything of the slightest value signing with SHA-1. There is no reason to
pick SHA-1 over SHA-2. You are not going to improve interop, you are much
more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to
go.




On Thu, Aug 11, 2022 at 7:23 PM Viktor Dukhovni 
wrote:

> On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote:
>
> > So say a zone is signed by the zone owner with both BK and a strong
> > algorithm denoted STRONG. As long as a resolver only trusts STRONG
> > signatures I don't see how the status of what NSECs say is signed can
> cause
> > forged data to be trusted.
>
> The issue is arguable lack of clarity in the validator requirements of
> 4035 when the server returns only RRSIGs with algorithms none of which
> are supported by the validator.
>
> When only unsupported algorithms appear in DS, the zone is "insecure"
> and all's well.  But otherwise, when only unsupported algorithms (or
> none at all) appear in an authoritative RRset's set of RRSIGs, the
> response is "bogus" not "insecure".
>
> The question of which algorithm is stronger or weaker does not arise
> here, MiTM can in fact "downgrade" a multi-signed zone to its weakest
> signing algorithm, by stripping the other RRSIGs.  Don't use broken
> algorithms, by switching away from deprecated algorithms in a timely
> fashion.  This has largely been accomplished for algorithms 5 and 7,
> which are down to ~7% of their peak deployment counts.
>
> DNSSEC algorithm agility is serving its intended purpose just fine.
> Resolver implementations had an apparently somewhat common bug, which
> most should have addressed by now (that the issue is public).
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote:

> So say a zone is signed by the zone owner with both BK and a strong
> algorithm denoted STRONG. As long as a resolver only trusts STRONG
> signatures I don't see how the status of what NSECs say is signed can cause
> forged data to be trusted.

The issue is arguable lack of clarity in the validator requirements of
4035 when the server returns only RRSIGs with algorithms none of which
are supported by the validator.

When only unsupported algorithms appear in DS, the zone is "insecure"
and all's well.  But otherwise, when only unsupported algorithms (or
none at all) appear in an authoritative RRset's set of RRSIGs, the
response is "bogus" not "insecure".

The question of which algorithm is stronger or weaker does not arise
here, MiTM can in fact "downgrade" a multi-signed zone to its weakest
signing algorithm, by stripping the other RRSIGs.  Don't use broken
algorithms, by switching away from deprecated algorithms in a timely
fashion.  This has largely been accomplished for algorithms 5 and 7,
which are down to ~7% of their peak deployment counts.

DNSSEC algorithm agility is serving its intended purpose just fine.
Resolver implementations had an apparently somewhat common bug, which
most should have addressed by now (that the issue is public).

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

Re: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

[Donald Eastlake]

Maybe I'm confused but I don't see that there is any problem with NSEC. If
a resolver believes in a broken algorithm, of course you are screwed. Say
BK is such a broken algorithm. Assume you go to the work of specifying an
using NSECbis that specifies the signing algorithm(s). If BK is broken, the
attacker can just forge new NSECbis RRs signed by BK that specify BK as the
signing algorithm. It is the resolver's believe in BK that is the problem.

So say a zone is signed by the zone owner with both BK and a strong
algorithm denoted STRONG. As long as a resolver only trusts STRONG
signatures I don't see how the status of what NSECs say is signed can cause
forged data to be trusted.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Thu, Aug 11, 2022 at 5:56 PM Phillip Hallam-Baker 
wrote:

> Looks to me like there is a serious problem here.
>
> NSEC record specifies what is signed but not the algorithm used to sign.
> DNSSEC allows multiple signature and digest algorithms on the same zone. If
> a zone does this, validators are prohibited from rejecting records only
> signed using one of the algorithms rather than both.
>
> Won’t go into extreme detail here as researcher’s slides will be available
> tomorrow.
>
> This definitely needs fixing.
>
> One near term fix is to make SHA-1 a MUST NOT. It is long past its sell-by
> date now.
>
>
>
> Get Outlook for iOS 
> ___
> dnsext mailing list
> dns...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations