On Tue, Oct 29, 2019 at 12:07 PM Ted Hardie <[email protected]> wrote:
> On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz <[email protected]> wrote: > >> FWIW, my expectation has been that ADoT would use TLSA-like >> authentication, with no trust anchors other than DNSSEC (and nothing >> resembling the WebPKI). >> >> Which certificate usage are you thinking of, in RFC 6698 terms? > > Generally, I think TLSA-like authentication rooted in DNSSEC validation is > fine. But I remain pretty much of the opinion that if you get a > certificate via that method that is "wrong" for values of wrong like > "presented the wrong IP address or name in the cert" or "fails DNSSEC > validation" then you should do more than log the error. > > I also would like to point out that there are cases where you might have > an authoritative server responding to recursive resolvers where there is a > root of trust between them but where DNSSEC may not be validated: split > DNS. Imagine for a moment that enterprise.example has a hierarchy that > includes FQDNs like hostname.campus..internal.enterprise.example . Each > campus has its own recursive resolver, but they all talk to nameservers > like ns.internal.enterprise.example. In cases like those, the desire of > the enterprise to not show its internal structures may mean that they do > not wish to use DNSSEC to secure anything in internal, but they likely have > a shared root of trust between the recursive resolvers and the > authoritative server. > > I think that is a very important use case, and also a good one to illustrate the differences between the PKI model and the DNSSEC model. PKI requires CRL/OCSP to handle any key problems or certificate revocation or anything... DNSSEC revocation can be done via DNS very quickly/scalably, although it does also mean temporary loss of service if the new keys aren't also available simultaneously. (That points to good BCP documents on managing stuff.) Distributing a localized DNS trust anchor is fairly straightforward, and I have used such trust anchors previously in those environments. They work exactly like you would expect. (At least for unbound, that is.) Scaling for campuses works very well when you delegate from the signed parental zone, and distribute the parental zone's trust anchor. Same model as root DNSSEC trust anchor, different starting point. Brian > Put another way, I think you may need to support authentication using PKI > trust anchors as well. > > regards, > > Ted > > On Tue, Oct 29, 2019 at 12:01 PM Ted Hardie <[email protected]> wrote: >> >>> Hi Paul, >>> >>> On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman <[email protected]> >>> wrote: >>> >>>> On 10/29/19 8:02 AM, Ted Hardie wrote: >>>> > To be sure I understand you correctly, in the second case, the >>>> connection would be made to some IP address (e.g. NASA's 198.116.4.181). >>>> The recursive resolver logs the details of the certificate, but it >>>> continues with the connection even if the CA NASA uses for the certificate >>>> is not known to the resolver? What does it do in the face of other >>>> certificate errors like expired certificates or certificates presenting a >>>> different name? >>>> >>>> It continues. This is exactly how opportunistic encryption is defined. >>>> >>>> >>> Just to be clear, it's my experience that accepting self-signed >>> certificates from peers does not equate to accepting certificate errors. >>> The situation in which you set up a connection to n.n.n.n and get a self >>> signed certificate saying "example.com" and when you set up a >>> connection to n.n.n.n expecting "example.com" and get a cert back for >>> "accident.example" are pretty distinguishable. I would expect some >>> configurations to accept the first without issue; I find accepting the >>> second deeply odd. >>> >>> >>>> > I have to say that I'm pretty surprised by the idea that TLS in this >>>> context should behave any differently than TLS in application layer >>>> contexts, and I'm a little concerned about having configuration options for >>>> this that amount to "ignore errors of types $FOO". >>>> >>>> TLS in application layers can specify that opportunistic encryption, >>>> yes? >>>> >>>> >>> I think you are using "opportunistic encryption" to mean something >>> different from what I mean by it. What I mean by it is "use it when you >>> can, even if you don't know in advance you can". Testing for DoT before >>> using a DNS resolver on UDP 53 and using it if you find it is >>> "opportunistic encryption", for example. >>> >>> >>>> > Accepting self-signed certificates is a known configuration, so I >>>> get that, but if someone has configured roots of trust, accepting other >>>> certificates outside the roots of trust in the configuration is pretty odd >>>> practice. >>>> >>>> Do you feel that there is a requirement that all recursive resolvers >>>> use the same set of trust anchors? >>> >>> >>> No. >>> >>> >>>> If not, and if you are against the use of opportunistic encryption in >>>> this case, >>> >>> >>> See above. I don't think I'm against opportunistic encryption. I think >>> I'm against starting to exchange traffic over a TLS connection with an >>> identifiable error. There are degrees there, obviously. Some folks would >>> say an expired but correct certificate should be logged but accepted, but a >>> flat out "wrong name presented" would likely get different treatment. >>> >>> who will decide what set of trust anchors all resolvers in all >>>> jurisdictions will use? >>>> >>>> >>> Everyone will decide who they accept? That's how the WebPKI works, for >>> all its shuffling glory, and with ACME/Let's Encrypt it has gotten very >>> easy to get a certificate that will often be accepted. >>> >>> Just my two cents, >>> >>> Ted >>> >>> --Paul Hoffman >>>> _______________________________________________ >>>> dns-privacy mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dns-privacy >>>> >>> _______________________________________________ >>> dns-privacy mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> >> _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
