On Sun, Jun 12, 2016 at 2:32 AM, Hugo Maxwell Connery <[email protected]>
wrote:

> Hi,
>
> Please excuse my potentially uniformed comment, but
> I think that DANE and DNSSEC try to solve the autheniticity
> problem (i.e I am talking to a valid auth NS).
>
> The privacy discussion is about not allowing trivial mass surveillance.
> Thus, I would have thought that any reasonable encryption is
> good.  E.g opportunitistic, CA, OpenPG, ... to the widest
> possible extent.
>

This depends on what threats you are concerned about. I think many
folks will argue that defeating non-trivial forms of mass surveillance,
including active attacks is important, in which case you need strong
authenticated encryption mechanisms.


> The two need to be combined for AFXR / IFXR as the secondary
> server needs to be sure about the identity of the master (data source).
>

It's already fairly common practice today to authenticate zone
transfers, mostly using shared secret based transaction signatures.
To address the privacy issue, it might be simplest to consider using
pre-shared key TLS, re-using the shared secrets already in place
for TSIG. Although to get forward secrecy we'd have to use the DHE
form of TLS-PSK, which means more work in the form of generating
fresh DH params on each session.

[...]

To summarise: there are two issues, authenticity and privacy,
> and we should where possible allow for the greatest flexibility
> in the selection of mechanisms for either and their combination.
>
> Different client types (secondary servers, caching resolvers,
> end points) may have different priorities in what they care
> about and some combinations of authenticity and privacy
> may be easier than others for various parties and what is
> easier may vary.
>

Sure - the current DNS privacy mechanisms being developed offer
solutions for both opportunistic and strict security. See RFC 7858
and the TLS authentication profiles draft for examples. So I think
this is being addressed.

-- 
Shumon Huque
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to