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
