> On 13 Jul 2020, at 23:35, Tony Finch <[email protected]> wrote: > > I've had a read through and here are a few, er, I mean several things that > caught my eye:
> > 7 authentication Belated responses on this topic! > > It seems weird to mix up channel auth and data auth, since they are quite > different things. As I understand it, ZONEMD isn't really authentication, > it's just an integrity check (unless it is used in a signed zone). And if > you are talking about data authentication it seems odd to leave out > RRSIGs. Well the goal was to compare and contrast the set of existing control methods - they do all have different properties and we wanted to explain where TLS fits in with these and be clear it can’t directly replace them… Perhaps authentication is too broad a term for this whole set of mechanisms. Maybe the split here should be transport independent verification mechanisms vs TLS…? > > TSIG doesn't provide data authentication. It provides mutual > authentication of the endpoints, and data integrity, but the server can > lie to the client about the zone contents. (The server is not necessarily > the ultimate authority for the zone.) We use a v. broad definition of ‘data auth’: “Authentication that the DNS message data is signed by the party with whom credentials were shared”, but given your comment I believe better term would be something like ‘data origin auth’ or ’transfer entity auth'. > > It would be useful to have terminology to distinguish between TLS where > the client software tries on its own initiative, with fallback to TCP > (which is what I think of when I read "opportunistic"); as opposed to TLS > configured by the admin without fallback to TCP and without any client or > server certificate auth. I'll call the latter "unauth”. So here we were following the definitions of Strict and Opportunistic TLS from RFC8310 (in addition to mTLS) although I think this needs clarification in the text: Strict is to use TLS _and_ the client authenticates the server or else hard fail Opportunistic is try TLS with authentication, if not fallback to unauthenticated TLS if not fallback to TCP. Only those two extremes were defined for stub to recursive… we could go for a finer grained model here if we think there are real uses cases for the intermediate state (your 'unauth’), I’m not convinced (see next point). > > I don't think strict TLS + TSIG adds any benefits beyond unauth TLS + > TSIG, because TSIG already provides mutual auth. Well, there's some risk > that the client may send requests to the wrong server, which goes back to > my section 4.3 question about whether it is part of the threat model to > worry about exposing which zones a client holds. TSIG gives entity authentication but not guaranteed confidentiality. The specific threat here is that in principle without authentication a MitM attack is possible on the TLS connection….. that attack can see not only the zone transfer requests but more importantly the responses, which is what we are trying to avoid. > > Mutual TLS is roughly comparable to unauth TLS + TSIG, but it has the > advantage that it's a bit easier to set up in a way that prevents clients > from being able to impersonate the server. If you want to do this with > TSIG then every client needs its own key, and the server config has to be > updated whenever a client is provisioned or decommissioned. With mutual > TLS the server only needs a relatively static CA cert that can > authenticate any client cert. Given the above I think it is reasonable to say it is roughly comparable to Strict TLS + TSIG if there are no proxies involved. Depends how easy you think setting up and distributing client certs is, which probably depends on if you run all the servers :-) > > I think there should be something in the spec about how certificate > subject names relate to how (in strict and mutual TLS) the client > authenticates the server, and how (in mutual TLS) the server decides that > the client's requests are authorized. I would like to be able to give my > client a server name (and optional address) and have it authenticate the > server using the system CA cert store and server certificate > subjectAltNames. I would like to be able to give my server an ACL > containing my private CA cert and a client cert subject name pattern. We do reference RFC8310 which specifies how the client authenticates the server but perhaps the draft needs to be clearer in that we are suggesting exactly the same mechanism for XoT. Mutual TLS (if it stays in the draft) does need some more specification though…. Thanks again! Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
