Top-reply, which I think can potentially address all the underlying issues: Make DANE support a SHOULD, along with publishing corresponding TLSA records at the FQDN of the DNS server a SHOULD. Make the recommendation that the certificate served include the full chain including CA cert. This would enable all forms of certificate issuance (public CA or not) and validation type (cert chain or end entity) workable for doing certificate validation.
I think this means that if both parties follow the recommended practice, that even self-signed certs can be validated through the DNSSEC validation plus the TLSA validation mechanisms. The only reliance would be on the DNSSEC root trust anchor. That is mandated when DANE is used, so it can be relied upon for all implementations that follow the recommendations. (Root trust anchor algorithms will always be a long-term thing to be concerned about, but that is really a global issue for DNSSEC and validating resolvers, not specific to this particular use.) Brian On Tue, Oct 29, 2019 at 9:01 AM 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
