Re: [Trans] DNSSEC also needs CT

Paul Wouters <> Tue, 13 May 2014 16:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 25FB11A0102 for <>; Tue, 13 May 2014 09:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wLk13-XSge_P for <>; Tue, 13 May 2014 09:11:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 999561A011A for <>; Tue, 13 May 2014 09:10:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CDBA8813B3; Tue, 13 May 2014 11:57:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1399996624; bh=XO3xhpYH+scnjcW+5lA3IdEDH+02Vwnk/uJKcSwh8i0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aSQ+DehiKFcNjtP6ghyJdC8wsDqQfLksACkqLz7WqcBVwexA0x39aQkJOFSAgkyKr 9CcoE5mU1iq0mmLoKtcSlsfa8oy7DGBmLngk+5vslk2T9sPgC9/PLdg7zb+71FnIlx +SY37jDW33ure2fhtLyta0VNeANnHI53KlnsFjqI=
Received: from localhost (paul@localhost) by (8.14.7/8.14.7/Submit) with ESMTP id s4DFv4Pg007272; Tue, 13 May 2014 11:57:04 -0400
X-Authentication-Warning: paul owned process doing -bs
Date: Tue, 13 May 2014 11:57:04 -0400
From: Paul Wouters <>
To: Ben Laurie <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Cc: Trans <>
Subject: Re: [Trans] DNSSEC also needs CT
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 May 2014 16:11:52 -0000

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, and I am
>> just a visitor of, 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'm reminded of the 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?

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