On Tue, Oct 29, 2019 at 6:27 PM Ben Schwartz <[email protected]> wrote:
> > > On Tue, Oct 29, 2019 at 8:53 PM Eric Rescorla <[email protected]> wrote: > >> >> >> On Tue, Oct 29, 2019 at 5:44 PM Ben Schwartz <[email protected]> wrote: >> >>> >>> >>> On Tue, Oct 29, 2019 at 8:02 PM Eric Rescorla <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie <[email protected]> wrote: >>>> >>>>> Clipping away a bit where we appear to agree. >>>>> >>>>> On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz <[email protected]> >>>>>> wrote: >>>>>> >>>>> >>>>> This resembles the ongoing experiment >>>>> <https://engineering.fb.com/security/dns-over-tls/> between Facebook >>>>> and Cloudflare, where both parties have agreed to speak DoT by hardcoding >>>>> the relevant parameters and special-casing the relevant authoritative >>>>> servers. They didn't need an ADoT standard to make this possible, because >>>>> the connection is a "closed system" based on an agreement between the two >>>>> parties. >>>>> >>>>> In your corporate-internal scenario, the recursive and authoritative >>>>> servers are even more closely tied, being operated and controlled by the >>>>> same party, so a secure upgrade protocol is much less relevant than on the >>>>> open internet. The admins can hardcode whatever authentication procedure >>>>> they want. They can even use pre-shared keys! >>>>> >>>>> Agreed, they could also use pre-shared keys. But that means that we >>>>> should not require in the standard that they use a specific method, but >>>>> provide a method that works for the common case and allow for methods >>>>> where >>>>> other things are driven by specific deployment conditions. >>>>> >>>>> Leaving that aspect aside, if we suppose that enterprise.example is a >>>>> signed parent zone, and internal.enterprise.example is an unsigned child >>>>> zone, we can still potentially enable DNSSEC-rooted ADoT to >>>>> ns.internal.enterprise.example, if we can find a way to put its TLSA data >>>>> in the parent zone. I think this is worth attempting. >>>>> >>>>> I would really like to see a sketch of the design for that before it >>>>> gets to be a foundation of the approach. I can picture both large flat >>>>> zones and deep hierarchies where it could end up being a real tangle. But >>>>> since that tangle is based on my headcanon of the design, it's liable to >>>>> being very badly off. >>>>> >>>> >>> I was thinking of the proposals to encode the TLSA data (and probably >>> some other NS-related info) in a "creatively repurposed" DS record (e.g. >>> here >>> <https://mailarchive.ietf.org/arch/msg/dns-privacy/G2BwaCvc7_G-NLkf1S51G4DGb6Q>). >>> That would allow a signed parent zone to make verifiable claims about the >>> child zone's configuration, even if the child is unsigned (i.e. has no >>> other DS records). >>> >>> This is by no means a complete or solid proposal: even the people who've >>> proposed it seem to have some concerns. >>> >>> Put another way, I think you may need to support authentication using >>>>>> PKI trust anchors as well. >>>>>> >>>>> >>>>> Assuming PKI is used to validate the nameserver's name, I'm not sure >>>>> it's sufficient, because this name is potentially attacker-controlled. If >>>>> the parent zone is unsigned, I think opportunistic privacy is likely the >>>>> best we can offer. >>>>> >>>>> I'm not sure what you mean by control the name here. To save me >>>>> tilting at strawmen, would you mind elaborating? >>>>> >>>> >>>> Ben, >>>> >>>> Is what you're saying here that .com provides the NS record for >>>> example.com and that may not itself be example.com, but instead >>>> ns.server.invalid, and therefore if you can't trust .com then it doesn't >>>> matter if ns.server.invalid has a WebPKI cert? >>>> >>> >>> My understanding is that one has no choice but to trust the parent zone, >>> even with DNSSEC. I was more thinking of an on-path adversary who can >>> intercept the NS query and reply with any response of their choosing. >>> Thus, instead of "ns.example.com.", I get "ns.attacker.example.", which >>> (as you said) will happily prove that it is ns.attacker.example. >>> >>> To put it another way: a recursive resolver has no way to distinguish >>> between an unsigned parent and an on-path adversary. (I'm assuming that >>> communication with the parent zone authoritative is over cleartext DNS.) >>> >> >> Yes, I totally agree with this. My assumption had just been that we >> should assume that we were incrementally deploying but that your target was >> all TLS. ISTM that it's going to be very hard to reason about the security >> properties here if each step in the recursive resolution process isn't >> protected. >> > > Yes, it's hard, but I think it's worthwhile, because the prospect of > getting the root to offer ADoT seems very distant to me. > Why? Do we have estimates of the load level here as compared to (say) Quad9 or 1.1.1.1? Since the root is signed, DNSSEC seems like the clearest path to secure > ADoT bootstrap in the foreseeable future. > Perhaps. -Ekr > > >> >> -Ekr >> >> >>> >>>> -Ekr >>>> >>>> >>>>> thanks, >>>>> >>>>> Ted >>>>> >>>>> 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
