> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote: >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote: >>> decision needs to then be made by the system. I believe that's been >>> mostly due to lack of time for the various parties to sit down and >>> plan and then program this further. >> >> We should try to make that happen. Okay, let's start once again from scratch. All of this was already discussed and we even had a huge meeting around DevConf and FLOCK 2014 about this, so following text will be just a short refresher: The ultimate goal ================= Make various man-in-the-middle attacks *automatically* detectable - without any user interaction. Especially we want to get rid of dialogs like "Site www.gmail.com is using certificate issued for xxx.porn and certificate's validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]". Tools ===== To achieve this goal we need to do DNSSEC validation on every client machine (ignoring Docker for a moment, see below) and allow applications to use DNS as trusted source of sensitive data (certificate fingerprints, SSH fingerprints, etc.). DNSSEC allows all parties to publish their fingerprints in DNS and gives us a secure way to get the data and to detect that someone prevents us from getting the data. Longer description ================== http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/ First step: DNSSEC validation ============================= Contemporary networks are full of broken DNS proxies so we need to jump through various hoops to get non-faked DNSSEC data for DNSSEC validation. The goal of this step is to get *cryptographical* proof that the data we received are the same as DNS zone owner published. This includes two sub-problems: a) Hot-spots: Captive portal detection needs to allow user to disable all the security so he can log-in but this needs to be done in a secure and reliable way so an attacker cannot misuse this. b) Broken networks: Some networks are so broken that even without captive portal they are not able to deliver DNSSEC data to the clients. In that case will try tunnel to other DNS servers on the Internet (Fedora Infra or public DNS root) and use them. Naturally, local/internal domains need to be available. All these sub-problems (including VPN handling an so on) are solved by dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda. HERE we need to coordinate with other parties who might want to write into the /etc/resolv.conf file. These include (but might not be limited to): NetworkManager initscripts dhclient libreswan ? resolved connman Option is either to implement all the checks and workarounds in all the projects over and over or to implement all the logic in one place - dnssec-trigger might be such place. Anyone who is going to write to resolv.conf needs to check for captive portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS servers and domains. *Questions:* Guys, what are your plans for handling the situations mentioned above? Can we integrate on one place (e.g. by calling into dnssec-trigger) instead overwriting /etc/resolv.conf independently? Second problem: API for applications ==================================== (this second step is not part of the F23 feature but it is worth discussing) Applications and crypto libraries need "an" interface to get DNS data which are either 100 % correct or declared as not trusted. False positive (trusted) answers are simply unacceptable because that would allow serious attacks. Imagine that OpenSSH client is verifying server's fingerprint against the value obtained from DNS *instead of asking the user*. If the client accepted a fake response with faked server's fingerprint then everything is doomed. The proposal https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html on glibc mailing list is to extend getaddr API with flag which says 'secure answers only'. This will return an answer only if DNSSEC validation for given answer was successful and the answer was properly signed. The assumption here is that something like dnssec-trigger properly configures local resolver (using the information from DHCP + applying all the necessary workarounds) to do DNSSEC validation locally so we are 100 % sure that the fake answer can be detected. The open question is how to pass the information about security status to all the parties. The mechanism needs to be simple so other resolver libraries like e.g. python-dns can follow the same rules and use the same logic as Glibc. Possible states: a) We are in hot-spot sign-on mode or validating resolver is unavailable for some reason (early boot, resource constraints, Docker container [finally!], and so on): In this case *nothing* can be trusted. Resolver might return faked answers and we have no means to check if declared trustworthiness is correct or not. Again, we need to be 100 % sure from the cryptographical point of view. => Application MUST NOT receive any answer marked as "secure"/"trusted" if we are in this mode. b) Validating resolver is up, running, properly configured, and the path to the resolver is trusted - it might be running on localhost or we are in Docker container and we trust the host and so on. In this case we trust to the result of validation indicated by AD bit. Application will receive the answer marked as trusted if the resolver tells us to do so by AD bit in the DNS reply. Please read the post on Glibc mailing list for more details. Any suggestions how to do that are more than welcome! -- Petr Spacek @ Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
