On 15 November 2012 20:10, Paul Wouters <[email protected]> wrote: > On Wed, 14 Nov 2012, Ben Laurie wrote: > >>> I think CT is a bandaid for PKIX that does not apply to DANE. >>> >>> I think the problem with DANE/DNSSEC right now is the additional latency >>> and dns transport issues (hotspots, VPN, etc) but I don't think CT is >>> very well suited to address those. >> >> >> a) Why would an attacker use your validity times? > > > Because there are DNSSEC keys to back the time slots used, and > without it, the data can and should be rejected.
This argument is circular: clearly if no-one ever gets control of keys for your domain, you don't have a problem. Validity times are irrelevant. If someone does get control, they control validity times, no? >> b) Weren't you amongst those asking for CT to support DANE during the BoF? > > I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS > certificate market where I have to pay $10-$150 a year to be "accepted" > in browsers via CT. What I understood was that browser vendors that > were looking at CT and DANE would specifically not be supoprted. The > first thought was to have a DANE backed CT that could be configured, > purely to get the DANE information (valid key + TTL/RRSIG info) into > the browsers that don't support or want to support DNSSEC (chains). > > But the DANE/DNSSEC information does not need an publicly shared audit > log. Its current up to date validity is available in the DNS at all > times, cached and distributed. You have a lot of faith in a mechanism that is not designed to provide a globally consistent view. How does DNS prevent bad actors from showing local views of the DNS? (Hint: it doesn't). This is precisely what CT does, and is exactly the value it adds to this kind of system. As for CT vs DANE, it is precisely because DNS does not provide a robust infrastructure that DANE cannot be allowed to override CT. This can be fixed by making DANE use some kind of equivalently strong transparency. I agree with others that this is probably better applied to DS records than to TLSA records. > > Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
