Re: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection

[abang]

Hi,

> Responses that fail to preserve the case of
> the query name may be dropped as
>potential cache poisoning attacks

Why not fallback to TCP in such cases?

Winfried___
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 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] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 09:56:31PM +, Phillip Hallam-Baker wrote:

> Looks to me like there is a serious problem here.

There is not a problem with the specification.  DNSSEC algorithm agility
works when implemented correctly.  Now that DNSSEC adoption is finally
becoming noticeable (though at ~5% of global domains, still far from the
norm), the DNS community is addressing operational issues and ferreting
out the latent implementation bugs.

> 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.

This is misleading.  If any of the algorithms present in the zone's DS
RRset published in the parent zone are supported by the validating
resolver, then the zone is *signed*, and all authoritative response
RRsets from the zone must be accompanied by a valid RRSIG that chains
back to a valid SEP and is mutually supported by the resolver and zone
signer.  If only unsupported RRSIGs are returned, the response is BOGUS.
Implementations that fail to make that conclusion are in error.

Apparently, bugs in some implementations until recently tolerated
responses that carried only unsupported RRSIGs, erroneously treating
these as "insecure", by failing to require the presence of a shared
supported ZSK algorithm chaining up to a valid SEP.

This was an implementation bug, that can at most charitably be treated
as missing explicit guidance in the specification to do the "obvious
right thing(TM)".  Such explicit guidance can be added in a new
clarification RFC, if deemed appropriate, though my personal view is
that it should not have been necessary.  That said, on the evidence of
the recent implementation bugs, perhaps being needlessly explicit is at
times the prudent thing to do.

> 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.

SHA-1 is not the problem here.  The downgrade issue is equally a problem
with NSEC (which does not use SHA-1) and NSEC3 (where use of SHA-1 for
light obfuscation to discourage zone-walking is just fine), and even for
cases that are not denial of existence at all.  And the problem exists
also for zones signed with only SHA-256 (e.g. algorithms 8 and 13 if
some now rare resolver supports only one and not the other).

The abstract makes no mention of NSEC records or denial of existence:

In this talk, we show that the cryptographic agility in DNSSEC,
although critical for making DNS secure with strong cryptography,
also introduces a severe vulnerability. We demonstrate that
adversaries, by manipulating the cryptographic material in signed
DNS responses, can reduce the security level provided by DNSSEC, or,
even worse, prevent resolvers from validating DNSSEC at all. We
experimentally and ethically evaluate our attacks against popular
DNS resolver implementations, public DNS providers, and DNS services
worldwide. We validate the success of DNSSEC-downgrade attacks by
poisoning the resolvers: we inject fake records, from our own signed
domains, into the caches of validating resolvers. Our findings show
that major DNS providers, popular resolver implementations, and many
other DNS services are vulnerable to our attacks.

The abstract is IMNSHO misleading.  Agility is not the problem,
incorrect implementation is the problem, though perhaps the requirements
for correctly handling multiple algorithms could have been more clearly
spelled out in RFC 4035, which covers signer responsibility in full
detail, but omits some of the (I claim obvious as a matter of logic, but
it seems still perhaps worth stating explicitly) corresponding
requirements on validators.

-- 
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

Re: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 04:58:46PM -0600, Paul wrote:

> Should we revive the 0x20 draft?

Seems reasonable to me.

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

Re: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection

[Paul via dns-operations]

--- Begin Message ---
 
 

 Should we revive the 0x20 draft?
 
 
 
 
 
 
 

 
 
>  
> On Aug 11, 2022 at 2:55 PM,   (mailto:dns-operati...@dns-oarc.net)>  wrote:
>  
>  
>  
>  ___ dns-operations mailing list 
> dns-operations@lists.dns-oarc.net 
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations 
>
>  
 
 
 --- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Phillip Hallam-Baker]

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
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection

[Ondřej Surý]

What would really help here is (continuous) sharing the list of problematic 
domains. That would really help the DNS community, we could talk to the people 
running these services, and prepare the configuration with exception for 
popular open-source implementations.

Ondřej
--
Ondřej Surý  (He/Him)

> On 11. 8. 2022, at 23:35, Tianhao Chi  wrote:
> 
> As part of this, we’ve identified a small set of nameservers (< 1000 distinct 
> IPs) that do not handle case randomization correctly and have exempted these 
> from case randomization.


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

[dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection

[Tianhao Chi via dns-operations]

--- Begin Message ---
Dear users and nameserver operators,

As part of our efforts to increase DNS cache poisoning protection for UDP
queries, we are planning to enable case randomization of DNS query names
sent to most authoritative nameservers (see our *security page description*

of
the feature and
https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00). We
have been performing case randomization of query names since 2009 to a
small set of chosen nameservers. This set of servers handled a minority of
our query volume, so a year ago we started work on enabling case
randomization by default. As part of this, we’ve identified a small set of
nameservers (< 1000 distinct IPs) that do not handle case randomization
correctly and have exempted these from case randomization. We are confident
that case randomization will work without introducing significant increases
in DNS query volume or resolution failures.

The case-randomized query name in the request will be expected to exactly
match the name in the question section of the DNS server’s reply, including
the case of each ASCII letter (A–Z and a–z). For example, if “ExaMplE.CoM”
is the name sent in the request, the name in the question section of the
response must also be “ExaMplE.CoM” rather than, e.g., “example.com.”
Responses that fail to preserve the case of the query name may be dropped
as potential cache poisoning attacks. Thus, nameservers that fail to
preserve the query name in their response, or whose response to
case-randomized requests is an unexpected error (SERVFAIL, NOTIMP, FORMERR,
etc.) or a failure to respond, will negatively impact users' ability to
resolve names in the domains they serve.

Generally, when nameservers mishandle case-randomized queries, we recommend
asking the nameserver operator to correct their behavior. While our
exception list will work around the problem for now, it may not get
immediate updates for newly broken name servers.

We’ll have case randomization enabled in one or two regions starting on
August 29th and enabled globally by the end of October. Meanwhile, we’ve
already turned off case randomization to nameservers that we’ve identified
as not handling it correctly.

If you believe you have discovered name resolution failures with Google
Public DNS due to case randomization, please file a bug in our *issue
tracker*

referencing
this announcement.
Let us know if there's any question via
https://developers.google.com/speed/public-dns/groups. We've also posted
this in our discussion group:
https://groups.google.com/g/public-dns-discuss/c/aHSyiIlBfjo.
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations