Re: [Trans] DNSSEC also needs CT

Ben Laurie <benl@google.com> Tue, 13 May 2014 16:17 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23D1A00DD for <trans@ietfa.amsl.com>; Tue, 13 May 2014 09:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level:
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMtprOS_V-tH for <trans@ietfa.amsl.com>; Tue, 13 May 2014 09:17:20 -0700 (PDT)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A98F11A00B2 for <trans@ietf.org>; Tue, 13 May 2014 09:17:20 -0700 (PDT)
Received: by mail-ve0-f179.google.com with SMTP id oy12so733301veb.38 for <trans@ietf.org>; Tue, 13 May 2014 09:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zTv/dbYC9jx3EWZYZKXqMbakV2zd71Pw27yAgkGJ0T8=; b=Plt3TVyaD1CV9PlswIP2UOPKaGVppsHKrNrL7xwM/wu5Tk2a4gBVfNFNorPWHrTglB qM0SQ9HytAZZxLKEnR/aeVmZLXYmqVaBipzkqlzUdqF65bn3Fn3vZnPEjobCT8Ivp+p5 0Q/uPahhRvzENhd+l2564IobgaZ+bTd+D2MPj2Q5hD9BFZEchsh4BL/74S7QAOUq40XX SVne75Y/EdJMJKihsUtD5vqtHMcQBeaApHG1+87O4HDjh6sEVz7cXqllK4KhQ6tWQBZx yYxzdatQ8dRBcLvkBwImd7+bSE1DLhlJZQnjsdTNMpW0IDtIfU542/k8wwoJRAiaNXm3 F+GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zTv/dbYC9jx3EWZYZKXqMbakV2zd71Pw27yAgkGJ0T8=; b=XCLNo7mT3wOh0YuG76CKQu67UnkLy2h3RRQaaMeJXaV0x5nxLHhVDN6k05JJkA+00Q rR2UNNDGq3xXYoajov5Df49Zpc2fUKtXS80KHiEVi952ceca9Lj1FKmwPSLgbHePn5W1 sdKa3uxxxELig/D6Q9Y29DKww0eXyNIQ8jm9b/9UxnBmKz3CEQ6QimXJqxwrYoUln4t2 83KXj12x+8dzpMRUj7XVwK/0h4oIYsxvX2acYiWgJzAg6BR+CeCEX/uv4OnA/MTV+4Oo IT8XfgQnVBucYMMKJHXMjStL47kPnL0fPu3JBOAHcPD4APyrB/sWwVz0PMSYERzQRphI Temw==
X-Gm-Message-State: ALoCoQl6svufBLmEQaO0QauVt2ZFna0cWelWMVEfnwAM1s/Lbl7VOdVIj9ctYSDNRTg9IeFe2LjZ
MIME-Version: 1.0
X-Received: by 10.221.36.73 with SMTP id sz9mr1001286vcb.62.1399997834160; Tue, 13 May 2014 09:17:14 -0700 (PDT)
Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 09:17:14 -0700 (PDT)
In-Reply-To: <alpine.LFD.2.10.1405131146070.25023@bofh.nohats.ca>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAOe4Ui=nqmCfjBYNE2CJtEs1jnbavpY4Dv-T3FRDdAwAA2dScg@mail.gmail.com> <CAK3OfOiYMJkXVR+QsCzEV0ir6u53coJz0b-JdGGD5bTTz5YcMg@mail.gmail.com> <CAOe4Ui=u0fkm9_nuXx_6gpH6jHM5pBvzjzru9O8y3bpLkA0qmw@mail.gmail.com> <CAK3OfOi6y=QAMXe_2axiavxwR5nS2Uv8SM4JxQHsvEKbUyNGCA@mail.gmail.com> <CAOe4Uimvc6e6u=fJjM1-iaOTepA33Sx5CBjMV9dB8sSLqtZoWA@mail.gmail.com> <CAK3OfOhdhWdGvvhuaGyE_p5kLy0ZX-V5sAXfoLGP_8d8vPJDgg@mail.gmail.com> <CAOe4Uik+fjM4wTVBiFxphVZAwVYBPgd1a9xUyUBMSFy30SWNLg@mail.gmail.com> <CAK3OfOiC+5+s2UtSEP788W23tHq6VQSQfMsUboUp16L-27zsvQ@mail.gmail.com> <CABrd9STYxmK6gg7a5wDtejdc_Y0aD9hwQkHpFu3HbxVbMZDQHQ@mail.gmail.com> <alpine.LFD.2.10.1405130948160.25023@bofh.nohats.ca> <CABrd9SSiHfyvPxgYrDZ_idE+UGcUXVFx3BGcc2qp+t+nmuJwLw@mail.gmail.com> <alpine.LFD.2.10.1405131128150.25023@bofh.nohats.ca> <CABrd9SStajEd9vDB8MrcosFiTYhAtnRMCY8CnOeuhPF16PAAPg@mail.gmail.com> <alpine.LFD.2.10.1405131146070.25023@bofh.nohats.ca>
Date: Tue, 13 May 2014 17:17:14 +0100
Message-ID: <CABrd9ST+NjdDh=nJk=aKhiOZg7c77esSz6tTTXUgNotwwfmiKA@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4hbnbyX1g5T08QyfNCNbJzn9iMM
Cc: Trans <trans@ietf.org>
Subject: Re: [Trans] DNSSEC also needs CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 16:17:22 -0000

On 13 May 2014 16:57, Paul Wouters <paul@nohats.ca> 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.