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. > 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? > 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? If not, and if you are against the use of opportunistic encryption in this case, who will decide what set of trust anchors all resolvers in all jurisdictions will use? --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
