Re: [dns-privacy] ADoT requirements for authentication?
Some miscellaneous thoughts vaguely related to the discussion ... ## nameserver hostnames in certificates It's not uncommon for zones to use in-bailiwick aliases for their nameservers, which avoids transitive configuration dependencies and speeds up resolution because the resolver gets glue with the referral rather than having to chase down server addresses. (see discussion of gluelessness on https://cr.yp.to/djbdns/notes.html) This is obviously problematic for using hostname authentication. I suppose a server could provide its IP address(es) and official hostnames in its cert to allow either for authentication... ## third-party secondary servers If the ADoT status is in the delegation (special DS records, special NS records) then that implies a nasty co-ordination cost to any changes. ## glueful bootstrapping If we rely on TLSA records at the nameserver's hostname then there's a fun bootstrapping problem for in-bailiwick delegations. If a resolver queries for the TLSA records in the clear then they'll leak the zone name; if it speculatively tries TLS then it might be really slow waiting for timeouts. ## reverse dns bootstrapping If the resolver looks for TLSA records in the reverse DNS there's a fun case where it has a referral for (say) example.com with glue for ns1.example.com in 192.0.2.1, but then it finds that ns1.example.com is also a server for 2.0.192.in-addr.arpa. The resolver needs to be able to re-use the forward DNS glue to get to the reverse DNS zone. Tony. -- f.anthony.n.finchhttp://dotat.at/ Great Orme Head to the Mull of Galloway: East or southeast 4 to 6. Smooth or slight, occasionally moderate in west. Fair. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] ADoT requirements for authentication?
Hi Paul, On Tue, Oct 29, 2019 at 7:50 AM Paul Hoffman wrote: > 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. > > 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 > --Paul Hoffman > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] ADoT requirements for authentication?
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. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
