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.
_______________________________________________
Ach mailing list
[email protected]
http://lists.cert.at/cgi-bin/mailman/listinfo/ach
