On 04/13/2017 05:27 AM, Ken O'Driscoll wrote:
On Wed, 2017-04-12 at 23:04 -0700, Alice Wonder wrote:
To compromise a zone protected by this second x.509 a bad actor would
need to both obtain a fraudulently signed x.509 from a trusted authority
*and* get fraudulent DS records into the zone's parent zone.
Or, an attacker could (as in the case we're discussing) just gain access to
the domain registry and re-assign NS records, disabling any DNSSEC type
security in the process. Resolvers have no expectation to be dealing with
DNSSEC signed zones so removing the protection would not be challenged.
Any mechanism that relies on anything that the registrant controls which
they (or an imposter with their credentials) can disable does not address
this risk.
As John already pointed out, organisations can mitigate against these
attacks by choosing registries (and registrars) who offer robust
authentication options along with employing monitoring solutions.
I'm not seeing how any type of protocol can do away with normal operational
level security.
What I am suggesting is that a CSR be produced from the KSK.
That CSR gets signed by a third party - either OV or EV (no point in DV)
The resulting x.509 cert is sent as part of the TLS handshake.
If it doesn't match the DS record in zone's parent the client refuses.
If it matches the DS record in zone's parent then the client shows the
pretty OV or EV information in the URL bar.
That won't stop someone who takes over a zone but it will prevent them
from doing so with the extra EV validation users like me always look for
when going to our bank or twitter or whatever.
So if Chase has their zone hijacked in the registry, the attacker could
make a DNSSEC validating phishing site, but it wouldn't have the other
visual indications of EV because the attacker wouldn't be able to send a
signed X.509 from the KSK that matches the fraudulent DS records they
created.
Wouldn't stop MITM from being attempted but it would give at least some
users a visual indication that things are not what they are suppose to be.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
