[Ach] bettercrypto.org cert blocked in chrome 56

[Alice Wonder]

On 11/29/2016 12:41 PM, sivmu wrote:
>
>
> Am 29.11.2016 um 11:46 schrieb Alice Wonder:
>
>>> ...
>>> DANE has its onw drawbacks, and also provides only an alternative cert
>>> autority system (the DNS root) which has the same or at least simular
>>> problems the the existing one. It provides additional security yes, but
>>> it is not nearlz as resistant to elaborated attacks then HPKP.
>>> Expeciallz government level adversaries only need very little effort to
>>> break the common ssl cert system and the DNS cert system, while they
>>> won't be able to break HPKP because it lacks the central autorieties.
>>
>> With DNSSEC you don't have to rely upon the ICANN root. You can have
>> your DS records signed by alternate, and for the few TLDs that don't yet
>> support DNSSEC an alternate root is the only way.
>>
>> At some point I will be encouraging the EFF to provide such a service,
>> so that people who use DNSSEC can submit their DS records both to their
>> TLD and to EFF so that DNSSEC clients can check both.
>>
>> That way to compromise a TLSA record, the attacker would have to access
>> to both the signing key from the TLD and from the EFF.
>>
>> The EFF could use the existing let's encrypt infrastructure to validate
>> a domain owner before signing DS records submitted to them.
>>
>>>
>>> A simular solution will be available for smtp soon as well.
>>
>> It already exists with DANE and is in use on several large e-mail
>> services (e.g. Comcast here in the United States) - though I think other
>> than custom code, Postfix is the only MTA that supports it.
>
> HPKP and its equivalent for smtp is not the same as DANE.
>
> DANE requires a lage set of dependencies, a gigantic infrastructure and
> a still largely central administration of root keys.
> HPKP on the other hand is simple and small.

DANE doesn't require a gigantic infrastructure. Your domain has a KSK 
(key signing key) that YOU have access to, and that key is where the DS 
record comes from that gets signed by an upstream (typically the Top 
Level Domain but it doesn't have to be)

Your DNS is then only vulnerable if a hacker either gets your private 
signing key, or creates a new signing key for your domain and tricks the 
TLD (or alternate signing root if you are using one) to sign the DS 
record for their signing key.

Creating a new signing key for your domain and getting it signed by the 
upstream is a very visible action and can be mitigated by using a second 
infrastructure in addition to ICANN such as the hypothetical EFF 
infrastructure I mentioned. That would require the fraudulent DS record 
be signed by two hierarchies.

>
> The difference in attack surface of these two technoogies is like
> comparing the complexity of a nail to that of a plane.

Your analogy fails.

HPKP and TLSA do the exact same thing. They provide a mechanism by which 
the client the validate the fingerprint of the certificate.

HPKP does so in a very insecure way that can leave your site bricked for 
many users for a long period of time and makes it difficult to respond 
to situations where you must change both your primary and backup keys in 
a short period of time (such as firing a system admin who had access to 
both).

TLSA doesn't have those design flaws and is Validate On Every Use 
opposed to Blind Trust On First Use.

Blind Trust On First Use doesn't work well with server to server 
communication because now all your scripts that fetch resources from 
other resources have to create their own cache of keypins they trusted 
or else they are just Blind Trust On Every Use.

With Validate On Every Use your server to server communication scripts 
can validate on every use and the blind trust issue doesn't exist.

HPKP is just conceptually broken, it was not very well thought out.