Re: [Trans] DNSSEC also needs CT

[Ben Laurie <[e-mail]>]

On 13 May 2014 16:57, Paul Wouters <[e-mail]> wrote:
> On Tue, 13 May 2014, Ben Laurie wrote:
>
>>>> The legitimate owner can tell - that's the point, right?
>>>
>>>
>>> How does that help protect a non-owner user of someone's site being
>>> attacked with a targetted attack? If I don't run victim.com, and I am
>>> just a visitor of victim.com, but only I am given rogue DNSSEC records,
>>> how can I tell something is wrong? I would go to the public log and see
>>> the DS I received is not in there?
>>
>>
>> Right, exactly.
>
>
> So how does the owner authorize a new DS in such a way that the parent
> could not override?

I don't know: this is not a question transparency addresses.
Transparency allows the owner to detect that the parent has
overridden. What happens then depends on how it is all supposed to
work, which I presume varies by registry/registrar.

> I'm reminded of the dlv.isc.org setup, where the zone owner had to prove
> control of the private key by publishing something in the zone. In a way
> this is also similar to the DS update problem in general. A rogue/hacked
> registry could also perform a DS update.
>
> I'm still not sure how to prevent a rogue update in the CT. And once you
> fix the rogue update problem, you face the reverse problem. A zone
> legitimately changes ownership and the old owner is malicious. How do
> you deal with that?

It seems to me that this is a contractual/legal/infrastructural
question. CT allows everyone to verify that everyone has done what
they're supposed to (modulo their own knowledge of what "supposed to"
is). Once you discover they haven't, then you have to invoke
mechanisms that are nothing to do with CT.

> Adding transition time into the equation could address some of this,
> but that will re-add the pinning problems.
>
> And adding another kind of authentication key would be adding similar
> problems as with TACK.
>
> Maybe some of these attacks are just out of scope and unfixable. After
> all, most domains are not "owned" but wrapped in legalese to really only
> give me a limited lease on it.
>
> In that case, we could do things like "warn if a DS is present in the DS
> RRset that has not been logged into the CT with a known signature by a
> current KSK" and "zone cut changed KSK". I'm just not sure how many
> false positives that would give with people rolling keys too fast for
> the CT log (and slow enough to indeed give that added protection).
>
> The last thing we need is another "cert patrol" style avalanche of
> popups.

Agreed. And one thing you may have to accept is that CT leaves open a
window during which attacks are feasible, but guarantees that they can
eventually be discovered. This is certainly the case for the PKI
version of CT.

I think you can reduce the size of the window in various ways - for
example, preventing key roll until logs have caught up, or until logs
and monitors have caught up.

-- 
Certificate Transparency is hiring! Let me know if you're interested.