jlivingood
commented
4 years ago Per Ted, countering:
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?
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". 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.
Just my two cents,
Ted
Greetings again. I was surprised, but happy, to not see a requirement in the list for authentication of servers in the list. However, I suspect that this might have been an oversight, and the endless debate on authentication requirements will start as soon as there is a proposed protocol document.
My preference would be that the core requirement is that ADoT servers use either IP address or DNS name authentication in their certificates, but that the certificates can be issued by any CA, including being self-issued. The core requirement could also go on to say that resolvers be able to authenticate servers for logging purposes, but not be required to break TLS connections if the server's identity cannot be authenticated against the resolver's set of trust anchors.