> On 02 Dec 2016, at 10:18, Alice Wonder <[email protected]> wrote: > > DNSSEC locks the user into fingerprints signed by my private signing key. > This is not a signing key that the TLD has access to. > > You can argue that a nefarious actor could create their own signing key and > get the TLD to sign the DS records associated with that key, but that is a > very visible action that would be seen in the DNS responses from the TLD. > It's out in the open.
Yes, unless you selectively serve out the signed records. Quite honestly though, my main concern with DNSSEC as compared to HKPK is adoption-rate really. With HKPK, we’re already at about 60%, and for some cases you can boost that by stearing users towards browsers with support. That’s not something you can really do with DNSSEC, unless in a corporate setting or similar. > On 02 Dec 2016, at 10:23, Alice Wonder <[email protected]> wrote: > >> It can be a backup key that you have, but it can also be that of another CA. >> Or completely random. Bad idea, but the browsers would accept it. > > Oh and for what it is worth, if you don't trust the CAs (I don't) then it > seems counter-productive to add a fingerprint from a CA that would allow the > CA to easily issue certificates that would then validate. Originally I commented just for completeness, but having given it some more thought: For a high-security setup, with a competent sysadmin-team, I absolutely agree. Much better to pin your live key, then two more that are cared for by different teams for example. For a fresh sysadmin, dipping his toes into pinning for the first time, it can be a way to keep “get out of trouble”-card for a while. If you pin two CAs, you’ve still cut the number of CAs that can sign for your domain by about 98%, which isn’t a bad place to start. It can also be combined with a “report only” pin, that’s more strict. Without having given it a huge amount of though over time, I could see myself making a recommendation for on-boarding into pinning along these lines: 0. Plan everything well, including success-critera for moving forward. 1. Make a report-only pin for your current and backup-key, as well as 2-3 trusted CAs. 2. After results are in, move that to your primary pin. 3. Make a new stricter report only pin, covering only keys under your control. 4. After time has passed, you’ve done recovery drills, fixed your flaws etc, cycle in the tighter report-only pin as your “real” pin. One key thing to keep in mind before getting to #4, is that the CA-pins will allow *other* people to recover from a disaster, not just the companys keymaster(s). In some situations, that can be pretty significant. > That may be useful for a private corporate certificate authority used on a > corporate network, but whether DANE or HPKP it is a bad idea to do it with a > public certificate authority. Well, that really depends on what you’re comparing – what your alternatives are. If you’re comparing pinning with only keys you control, against pinning CA-keys, obviously the former is more secure. If you’re comparing with not pinning at all, I’d much rather have a PIN that drops the number of CAs that can sign for your domain by 98%. It’s not perfect, but it does drop the number of trusted parties quite dramatically. You’re not giving the 2% a new ability to sign for your domain, they already can, you’re taking it away from the other 98%. I’d certainly be interested in that. :-) Terje _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
