On Mon, Mar 21, 2022 at 5:28 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
