[getdns-users] public key pinning and tls_authentication models

[Daniel Kahn Gillmor]

On Tue 2015-12-22 01:03:03 -0500, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> There are still a couple missing pieces, though.  In particular, the
> interaction between getdns_context_get_tls_authentication() and the
> dicts that comprise the list of upstreams seems complicated and
> confusing.

After some discussion with Sara, I've just pushed 3 more patches to the
feature/pubkey-pinning branch as a way to address this concern without
making any particularly dirty API changes.

What i've done is i've renamed GETDNS_TLS_AUTHENTICATION_HOSTNAME to
GETDNS_TLS_AUTHENTICATION_REQUIRED.  The semantics are the same as
before, but now the authentication will be based on either member of the
upstream dict: tls_auth_name or tls_pubkey_pinset (or both, if both are
present).

GETDNS_TLS_AUTHENTICATION_HOSTNAME is retained as an alias to
GETDNS_TLS_AUTHENTICATION_REQUIRED so that we don't break the API here,
and these changes now make it possible to do a strongly-authenticated
query using only a pinset.

Additionally, Sara and i had a really fruitful discussion about what we
would do if we were willing to make backward-incompatible API changes to
how we handle DNS privacy to align with the Yokohama discussion (with an
SONAME bump, of course); i'll start a new feature/privacy-api-overhaul
branch based on top of feature/pubkey-pinning to document that thinking,
so that it's available for consideration whenever an SONAME bump is
acceptable.

   --dkg