On Thu, 15 Nov 2012, Paul Hoffman wrote:
On Nov 14, 2012, at 10:14 AM, Shumon Huque <[email protected]> wrote:
For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC
authentication chain, not the existence of a fraudulently issued
certificate on some attacker's server.
If the DNSSEC chain is intact, then presumably DANE aware clients
will properly authenticate the TLSA record before accepting the server
certificate. I admit that's a mighty presumption today, but we'll see ...
This is an excellent summary of the scenario.
However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA
issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the
hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS
records might not be detectable to the party with the leaf record.
For example, assume the domain name example.newtld. The owner of example has
put DS record A in the newtld zone. If the owner of newtld goes rogue and shows
DS record B to a limited number of requests (such as to a particular geographic
region or set of network addresses), the party with the private key associated
with B can spoof example, and the owner of example would not know unless he
could see B.
Interesting. I had not considered this because a big difference is that
such rogue DNS records would not be contained/targetted. The forged DS
created by the parent would quickly expose the parent, and I doubt the
parents would want that reputation damage. Unless they are totalitarian
governments, but unlike phb, I give up any kind of using the internet
against advisaries that are physically in the path - it just ends up
with you refusing to be lied to and not connecting, or going along with
their lies and getting eavesdropped.
But I'm not sure how CT would see the difference between me logging
in to my registrar interface and updating the DS record, someone else
using my credentials to do the same without my knowledge, or the registry
going rogue. The way PKIX-CT does this is via some financial transaction
pretending to convey trust and authority and a credit card audit trail.
It fails for the common user precisely because it costs money, and
today's criminals have more money to invest compared to the average
internet user.
I also don't see how TACK addresses this either, with their complicated
pinning schemes that are just many different ways of shooting yourself
in the foot, without adding anything to the DANE pinning method (apart
from relying on verisign to not forfeit their root zone contract to sign
custom data for anyone)
So I think CT could be used as DNSSEC/DANE history audit log, but IMHO
the main asset of something like CT based DANE is purely as a better transport
layer for DNSSEC - not as a replacement for DANE/DNSSEC.
DNSSEC points to the publisher, who is defined as always right (even if
they are wrong because they are sloppy or have a gun pointed at their
heads)
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
