On 15 November 2012 20:32, Paul Wouters <[email protected]> wrote: > 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.
Incorrect: CT provides a globally verifiable audit trail - the exchange of money is irrelevant. CT does not see the difference between you logging in to your registrar interface and updating the DS record, someone else using your credentials to do the same without your knowledge, or the registry going rogue. What it does it make all of these visible to you. Then it is up to you (or anyone else) to spot the abuse and do something about it. > 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. CT does not replace DNSSEC (or PKIX), it does as you say: provides an audit log. > 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
