Re: [therightkey] [dane] DANE and CT

[Ben Laurie <[e-mail]>]

On 15 November 2012 20:10, Paul Wouters <[e-mail]> 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