Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Petr Špaček <petr.spacek@nic.cz> Thu, 30 July 2020 13:58 UTC

Return-Path: <petr.spacek@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D033A0B8D for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 06:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 P9ZhzB5DvXwS for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 06:57:59 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612923A0AAC for <dnsop@ietf.org>; Thu, 30 Jul 2020 06:57:57 -0700 (PDT)
Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:1488:fffe:6:5c39:29ff:fe8a:696c]) by mail.nic.cz (Postfix) with ESMTPSA id 289C614099B for <dnsop@ietf.org>; Thu, 30 Jul 2020 15:57:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1596117476; bh=DEnsy0Wob2SwizaQpf03ka6Kw3aO97bv7r7pJ2pzpFQ=; h=To:From:Date; b=mIgGnOHLaoXhSKnGiMOnvF6Hh2oSWygtB9yAte4G/ZywOH3NF/2UX90Y9RDnLznpx gfOpD7Br9TpxfPB5Kf64BRWCPurfLoiZEcDEb+9l3TtUxyRQbLQoEgIw2v4CF3NzKv QY9+9t+/e/0wauDQJOLK9Jy5/RAATUhFVyW4FAqU=
To: dnsop@ietf.org
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ==
Organization: CZ.NIC
Message-ID: <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz>
Date: Thu, 30 Jul 2020 15:57:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jS-hp6DoEno0JvmoNYkfmJskxjo>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 13:58:03 -0000

Hello,

I'm going to generalize Ben's questions:

It is hard to see what benefits draft-ietf-dnsop-delegation-only brings without having description of "DNSSEC Trasparency" mechanism available.

Please describe intended usage of the proposed mechanism, at the moment it is hard to see all the details and interactions.

Petr Špaček  @  CZ.NIC


On 29. 07. 20 21:54, Ben Schwartz wrote:
> I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to make sure that the draft isn't overstating the achievable benefits.  To that end, I have some questions about the text of the -01 draft.
> 
> (I recognize that these are issues I've raised before, but I still haven't gotten answers that I understand.)
> 
> Assuming the claims are correct, I think they need some clarifications for naive readers like myself (and possibly deduplication, since some claims are repeated in different sections).
> 
>>   Exposing such targeted attacks requires a transparency audit
>>   infrastructure similar to what is deployed for PKIX ([RFC6962]).
>>   However, a DNSSEC version would need to log significantly more data,
>>   as all signed DNS data used by a DNSKEY must be recorded in order to
>>   prove that data signed by a parent zone's DNSKEY was out of expected
>>   policy.  The very distributed nature of the DNS combined with the
>>   typically frequent zone resigning rate makes such transparency logs
>>   prohibitively expensive and nearly impossible to operate.
> 
> How does this draft alter that cost?  For delegation-only zones that are in compliance, it seems like the cost is not changed.  Presumably violations will be rare, so they won't contribute significantly to the cost.
> 
>>   Additionally, it would require zone owners to expose all their zone
>>   data to any public log operators, thereby introducing privacy
>>   implications and exposing all relevant DNS data to a public archive.
> 
> I don't understand how this flag would alter that exposure.  If my zone is already delegation-only, how does adding this flag improve privacy?
> 
>>   At the time of this writing, the list of entries in the
>>   public suffix list contains over 8800 entries as well, with 73 wild-
>>   card entries (prefixed with a "*") indicating that all of their
>>   (unknown number of) children are public registration points.  In the
>>   absence of an interoperable mechanism (like this draft provides), it
>>   is infeasible that a validating resolver or auditing log could know
>>   which of these zones are delegation-only without individual policy
>>   statements from each of them.
> 
> Marking a zone delegation-only doesn't imply that it is suitable for logging, so wouldn't participation in any logging scheme require an individual policy statement anyway?
> 
>>   Finally, a DELEGATION_ONLY flagged DNSKEY for
>>   the root zone cannot be overridden easily, as it would require a
>>   trust anchor update in all validating resolvers.
> 
> The preceding sentences deal with the lingering "false child key" problem, which still applies here, so I don't understand the relevance of this sentence.
> 
> I also had some thoughts on the Security Considerations:
> 
>>   Care should be taken by resolvers to not
>>   unnecessarily empty their cache.  This is specifically important for
>>   roaming clients that re-connect frequently to different wireless or
>>   mobile data networks.
> 
> I believe this advice is counter to best practices for mobile clients for both performance and privacy reasons.  See e.g. http://dnscookie.com/.
> 
> Also, I think it's worth mentioning that "delegation-only" zones can still deny the existence of a DS for the child (if the child was signed to begin with), and then generate deep unsigned records for the child.  This limits the direct impact of this flag to cases where DNSSEC is mandatory.  (Logging might be able to deter this attack, assuming NSEC records are logged.)
> 
> Thanks,
> Ben Schwartz