Re: [dane] [Trans] CT for DNSSEC

Wei Chuang <weihaw@google.com> Wed, 12 April 2017 16:48 UTC

Return-Path: <weihaw@google.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881A112EAAC for <dane@ietfa.amsl.com>; Wed, 12 Apr 2017 09:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 HEjKMpEQ5fxp for <dane@ietfa.amsl.com>; Wed, 12 Apr 2017 09:48:57 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EE71314E3 for <dane@ietf.org>; Wed, 12 Apr 2017 09:48:57 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id j127so10204725vkh.0 for <dane@ietf.org>; Wed, 12 Apr 2017 09:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9QO/NlYLrrMjhdPS8vxWmnVsAawexflZTRzkpp53lb8=; b=fR2AUP0Cztdws1+jucFOw1JZvFm7Pyz9iE1hEhuzo9vlxaMYHfmYwf9A9TV3i4fnUx 0/XuZwghfxXBwaZdllfeRB+nor5HRPS/ChVGf4qn5IgZ7LJC7TiGOWAum18vQU0mKE0i g1fHrzv1w+9ActsYwFR/3EAP4BB7HN0+nSGGbqVptzribHU+tT6m/4Wht74/sX73vjmm NxZLl/HeoFia3qFtsnt7N6Ou7ZixevjMJnxOtON8Fmavl++bww2fbIe+mG+B2hdzoHpe aXy4hjOWZrwEYlMobgohXUpeQLxXZcees2g/u59PN6vfy4P3xamElcBc5prBfwMZM5qU A09Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9QO/NlYLrrMjhdPS8vxWmnVsAawexflZTRzkpp53lb8=; b=uYci/kMkftOR63N2rxTAwWSHinbB2uW7XaTaxM78kj7HSn5GUsD+TQepsIPMJIqUyP bNolE8lkoQxSFHO/GEpqk83P2dGFPGfIu6N4yB8gy97G3OS48Y+RoVzdSYOMFs70wLKM rFLEoCNhOOvTDACQ7P32iBr5rgwRpklH+djAmsd6s4lRuOIuPF++7OZfKTQ7uaf/PEcO Lx3Ay99QpBzksT7PBlz/LT8Yb2uyH7PLzKOD+1bXiibXmv44h+anuV0xh4UYTFANdLIF 3brqkTxhihQzQKAxb/e60P8VaNKbqxMirnobl4jlftyddPRgNOaY3NdFuu/zYQvK7mW9 977Q==
X-Gm-Message-State: AN3rC/7M2QUJ0D+fJxan1iohWk+3kwiK/MgKnJwoeGeL6RqULcvTBSXsIfgJ7+vovJ9D5QmbeL2cbxRUduIrkUKk
X-Received: by 10.31.222.132 with SMTP id v126mr1421648vkg.128.1492015736027; Wed, 12 Apr 2017 09:48:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.0.22 with HTTP; Wed, 12 Apr 2017 09:48:55 -0700 (PDT)
In-Reply-To: <A86DBCF1-A0E6-4E2F-B588-1DA510771D90@dukhovni.org>
References: <CAAFsWK0bCDZmg0csCfXAJ1=jqbOBc7sUUvSg-6ZKjxuAQKmQPA@mail.gmail.com> <455EC3FC-9140-40D3-88F8-77990B7C7DD0@vpnc.org> <CAAFsWK2z1AR6RZToQvw7s_t_u+333Jyk6pUQ5KznbsrQGxkvgQ@mail.gmail.com> <C54BF614-378D-4A0A-964F-AE372E064D42@vpnc.org> <1DA6DC8F-CA06-4453-96E6-D8D257555437@dukhovni.org> <CAAFsWK1Jeq18mLsKJpv3DJzhrHzX1Z=rQpyxX5TmF+AOLX8-3Q@mail.gmail.com> <9FC39E28-4285-40F8-8FE9-283FA83B1A0A@dukhovni.org> <CAAFsWK09KAsYSsDP0mMijYU7E6uw=JyL78kWGiwyJNrn_r3hSw@mail.gmail.com> <A86DBCF1-A0E6-4E2F-B588-1DA510771D90@dukhovni.org>
From: Wei Chuang <weihaw@google.com>
Date: Wed, 12 Apr 2017 09:48:55 -0700
Message-ID: <CAAFsWK3qXQGDT=0TqXb64_s0HdVOuntmVLzfWqacrHF0-uW+kg@mail.gmail.com>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Cc: trans@ietf.org, IETF DANE Mailinglist <dane@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07b1dcf825c7054cfafbb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/7r109tGVYrrNwljqMgDhmIH_NhQ>
Subject: Re: [dane] [Trans] CT for DNSSEC
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Apr 2017 16:48:59 -0000

On Wed, Mar 29, 2017 at 8:11 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>;
wrote:

>
> > On Mar 29, 2017, at 10:33 AM, Wei Chuang <weihaw@google.com>; wrote:
> >
> > Why not create an explicit Non-existence of DS (NDS) RR that gets logged
> along with DS and NS?
>
> This is not needed, the NSEC/NSEC3 RRs already serve that role.
>
> For NSEC records (RFC4034), an unsigned delegation looks like:
>
>         example.com. IN NS ns1.example.com.
>         example.com. IN NSEC examplf.com NS
>         example.com. IN RRSIG NSEC ...
>
> this proves that NS (or other depending on the content of the type
> bitmap of the NSEC record) records exist for example.com, but DS
> records do not.
>
> With NSEC3 (rfc5155), and the "opt-out" bit the situation can be
> more complex because the answer may not establish the existence of
> example.com.  Instead we may get an existence proof for the closest
> encloser (ancestor domain) and proof that "example.com" is not signed,
> but no proof of its existence.  This means that to avoid spam, a log
> might want to independently verify the existence of the insecure
> delegation by repeating the query, so as to avoid storing data for
> non-existent domains with the insecure NXDOMAIN modified to NOERROR
> with made up NS records.
>
>
Sorry this reply is coming late.  Your response helped a lot (thanks!) but
I had nagging concern that couldn't make concrete till now.

When a DOE lookup occurs on DNSSEC, the authoritative nameserver services
the request and determines to respond with what you describe above (the
NSEC and its RRSIG).  The complication occurs with CT.  While we may log
the NSEC or NSEC3 record and these records will be present for lookups in
CT of existing records, there isn't an online server to assist with lookups
in CT of non-existing records.  I suppose it may be possible to replicate
the state of the authoritative nameserver but consider that this likely
doesn't scale as CT servers are servicing a scope potentially much larger
than the authoritative nameservers.  The approach I describe earlier with
an explict Non-existence of DS (NDS) should allow for direct lookup of NDS
entry.

Also agreed with later comments suggesting that the entire key signing
chain needs to be CT logged with its proofs and non-existance records for
this to work.

-Wei


> --
>         Viktor.
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>