[Ach] bettercrypto.org cert blocked in chrome 56

[Terje Elde]

> On 02 Dec 2016, at 10:18, Alice Wonder <alice at librelamp.com> 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 <alice at librelamp.com> 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