Re: [dane] CT for DNSSEC

Wei Chuang <> Fri, 17 March 2017 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28B441294EC for <>; Fri, 17 Mar 2017 09:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SZnZYRmq4eJQ for <>; Fri, 17 Mar 2017 09:31:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B2641294E9 for <>; Fri, 17 Mar 2017 09:31:46 -0700 (PDT)
Received: by with SMTP id i1so97176446ota.3 for <>; Fri, 17 Mar 2017 09:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pyPV9SrY1JzazSysydhDGqhwtbE9RPPpP0klwsUnTjc=; b=Bc2Vgs7kOLEE66ROjrAF3XAj1jegs8yBW+Kt+0waoyeiqs+qacdfQe21X9muVScup9 ijpHpOQAwmlXTvYDWEkkHjHKJ9/wFjv7zLcN6/8VDHGeCfESEbcS3EIcM0Sa8hWJc7mF Tg98KIZmiyEfsxdg8KalcTc/+48+cNlamZc5hLwClYQ8Iak7I1gPaIJ98Zn9PhU1BTZf W5+z21PFy+EG+BKmJFo+vBo03ZqmEm+f2CqigoEK3Og2Hii3ySFhcCXKsA4iAPS+cZ6G AKCai3CUz7zQQwaY+p/fE7iNhAwuFfFQoCenSMkxS3ahFzhS/pQ+dYSE7EjprYDPohzX egwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pyPV9SrY1JzazSysydhDGqhwtbE9RPPpP0klwsUnTjc=; b=ieFpeRhf1Vn5n5xtwXDEzegcDxaL9A1Xtc9Moa3VCVj/w6QflTGBdotKa4otloP9xt NR7AWE2g+DFYlLb5Ggb90xe+GN351wtlXHri5qDZXpS5a9BXA1v1l0e3x2PelR0l3QP5 p1x9NwTTXDFkh0gLQGmb22+mPs8JMqAL6GxJ/6T+KxDDFVjE7BwRMuBCKVPFX+1ft/1a vU4LW2sIP9GhGMLqqo2cBDgdQuv/tp8/d2aelCjdgdLCenpdpT/x00yO5TLuXWe9l6r4 L/EduaaR4kdy1OBNRKI5BFTn+Q2ysBuhwYl5Qk8Bhg1vAwwX63spHjiUU3rLIJ8t/LKk CVvA==
X-Gm-Message-State: AFeK/H1w9g+wBtmQGbQw3t70mQvr5PdFasoqguGS/6YQ+VQ33CzZB1TEp5zIT4oczYHiHXFksyeRXbhtKqGcaWZL
X-Received: by with SMTP id b132mr8568195oif.101.1489768305631; Fri, 17 Mar 2017 09:31:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Mar 2017 09:31:44 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Wei Chuang <>
Date: Fri, 17 Mar 2017 09:31:44 -0700
Message-ID: <>
To: Paul Hoffman <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113ce0b0acd609054aefb691"
Archived-At: <>
Subject: Re: [dane] CT for DNSSEC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Mar 2017 16:31:48 -0000

On Thu, Mar 16, 2017 at 10:25 AM, Paul Hoffman <>

> On 16 Mar 2017, at 10:09, Wei Chuang wrote:
> I saw there was significant interest
>> <> in exploring
>> CT for DNSSEC back in 2014 of which a draft draft-zhang-trans-ct-dnssec
>> <> was created.
>> It seems to have quieted down since.  I believe the motivation is still
>> there which is to prevent a parent zone from potentially misbehaving and
>> spoofing the child zone.  Is there still interest in this?  From the list
>> archives, I can't see what the issues were though I'm guessing one of them
>> was respecifying the DS resource record to use a SCT which might have
>> caused compatibility concerns.  (But please correct me if I'm wrong)
>> Other
>> than that, the draft seems pretty reasonable.  Were there other concerns?
> There were two separate issues that got conflated at the time:
> - Seeing evidence that a parent had spoofed DNSSEC keys for a child. A
> transcript of the DS records in the parent is sufficient as long as the
> child doesn't have relying parties create islands of trust (which is
> relatively rare these days).
> - Seeing evidence that a parent had spoofed any resource records for a
> child. A transcript of the NS records in the parents is a good start,
> although what is really needed is a transcript of everything that is seen
> for the child.

Is this because you're worried about the parent removing evidence of DNSSEC
for the child in the spoofing scenario?  If the parent tries to spoof with
DNSSEC for the child I would assume that seeing the DS SCT's in the log,
that is sufficient to find evidence of spoofing.  That said I think it
could be helpful to log NS as well for forensics.

One issue with logging all records seen is if webmail providers publish
SMIMEA there will be a potentially overwhelming number of records logged,
and a very large change rate.  Another issue is privacy of such records.

> In both cases, having transcripts from various DNS looking glasses around
> the Internet would give greater assurance of the integrity of the
> transcript.

I agree that would a good idea.


> --Paul Hoffman