Re: [DNSOP] DNSSEC as a Best Current Practice

[Brian Dickson <[e-mail]>]

On Mon, Mar 21, 2022 at 5:28 AM Masataka Ohta <
[e-mail]> wrote:

> Paul Wouters wrote:
>
> >> If a resolver correctly knows an IP address of a nameserver of a
> >> parent zone
> >
> > This statement seems a recursion of the original problem statement?]
>
> What?
>
> The statement is not more demanding for resolvers to be configured
> with correct certificates.
>

I'm presuming you mean "DNSSEC ICANN/IANA Root Trust Anchor", which is a
public key, not a certificate per se.

I presume you're comparing two models, one using DNSSEC, and one where no
DNSSEC validation is done ever (replaced with TLS, either DNS over TLS to
Authority, or DNS over HTTPS to Authority, including root, TLD and all
authority servers for all zones).

I'll use that assumption in the remainder of this message...


>
> > This would not help for on-path attackers (without DoT, DoH)
>
> See below.
>
> > How would this be safe against the current BGP attacks we are seeing?
>
> Are you saying connecting to an IP address secured by DNSSEC
> is safe even under BGP attacks?
>

The complete model of using DNSSEC involves also using TLSA records (DANE).
In the DNSSEC-protected TLSA record model, BGP attacks have no direct
impact on DNSSEC-protected zones, including BOTH the address records
(A/AAAA) AND the TLS information (complete certificate, or public key, or
hash of either of those), and consequently no impact on the TLS connections
subsequent to the DNS lookups (i.e. no possible cert-level MITM or web site
spoofing).

The exclusive capability of a MITM would be to DOS the DNS lookups, or to
block the TLS set-up (if the attacker were on the data path to the
endpoint).

So, yes, a web site properly protected using all of the DNSSEC-based
capabilities, where the client software was doing the validation using the
corresponding methods, would be safe against any and all MITM attacks,
including BGP.

Note that this is already the case for SMTP (using SMTPS via TLSA records).
Those SMTP connections between parties publishing and validating TLSA
records are not subject to downgrade attacks, and only properly validated
endpoints can communicate (securely).


>
> >> As for MitM attacks, PKI, in general, is insecure against
> >> them as was demonstrated by diginotar. So, don't bother.
> >
> > DNSSEC is more hierarchical than the "bag of CAs", so a failure
> > like this would be more contained. Regardless, I do not understand
> > how PKI failures relate to DNS?
>
> Are you saying you don't understand DNSSEC is a form of PKI?
>

I'm reasonably sure that Paul W meant "WebPKI" when he said PKI.

WebPKI is effectively a "flat namespace" sort of PKI, meaning a bunch of
CAs all have the right to issue certificates, with no exclusivity (which is
part of what lead to the diginotar thing).

By comparison, DNSSEC is an exclusively hierarchical, singular control
point PKI system. At each level of the hierarchy, the public keys are under
the exclusive control of the zone owner/administrator/operator, and signed
by the parent zone.
(Any concerns on the out-of-band update aspects are potentially worthy of
work, but that is also the case for the OOB update aspects for WebPKI.)


>
> >> IETF can do nothing if some government legally force
> >> people to install some government provided certificates
> >> to some PKI, including DNSSEC, which is as easy as
> >> MitM attacks on ISP chain may be by government order.
> >
> > With DNSSEC, a government in country X cannot spoof data of
> > country Y, they can only block it.
>
> Country X legally forcing people to install government provided
> root certificates can freely spoof PKI, including DNSSEC, data
> of country Y.
>

This is another place where the "flat" WebPKI vs the "hierarchical" DNSSEC
models are not exactly the same.

In addition to resolvers, end hosts have the ability to do DNSSEC
validation (on data received from resolvers).

Any host (resolver or end host) is capable of installing trust anchors for
any level of the DNS hierarchy, which would preempt any spoofed delegation
information (DS records) and reduce unsigned delegation spoofery to the
aforementioned DOS level of interference. End hosts would never see the
spoofed answers.

End hosts may also have some ability to make use of other resolvers (very
much dependent on local conditions, of course).

The scope of what country X can do with respect to country Y, is limited by
any number of orthogonal elements.
Those include

   - geographical limits (e.g. the physical boundary of country X)
   - topological considerations (all the paths from every host/user to the
   outside world)
   - resolvers reachable by any/all hosts/users
   - host/application configuration on all of the resolvers and hosts
   - necessity of altering responses at every level of the DNS hierarchy by
   on-path changes for all of the above elements

Additionally, outside of the physical geographical boundary of country X,
nothing country X can do can accomplish the spoofing of data of country Y.
And within country X, the necessity of asserting configuration control of
resolvers and hosts, would seem to be an extremely high bar for a state
actor.


>
> > Again, I think perhaps you should write this up in a draft, so
> > we can see how your proposal would cover everything that DNSSEC
> > covers.
>
> Before diginotar, maybe. After that, I don't think it necessary
> any more.
>

Honestly, rather than spending any effort in that area, any concern about
protecting TLS connections would best be done by convincing web browser
software vendors to implement DANE (TLSA) validation.

Brian