Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

Vladimír Čunát <vladimir.cunat@nic.cz> Mon, 19 March 2018 16:26 UTC

Return-Path: <vladimir.cunat@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 41AB812D7FC for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 09:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 uQsFtlGZ1-Yj for <dnsop@ietfa.amsl.com>; Mon, 19 Mar 2018 09:26:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 E36C412D7E5 for <dnsop@ietf.org>; Mon, 19 Mar 2018 09:26:49 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:586f:b5ff:fe77:f7c0] (unknown [IPv6:2001:1488:fffe:6:586f:b5ff:fe77:f7c0]) by mail.nic.cz (Postfix) with ESMTPSA id 9DE4C61146 for <dnsop@ietf.org>; Mon, 19 Mar 2018 17:26:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1521476808; bh=eGcfyNXicBW+0X9VHt1Fpr3Jhy/EwNJ5yGHrB5SdZBU=; h=To:From:Date; b=Q5Ism5nJ8PnlFbMLFUEj+kXKePVzad4oWPs+zKD8uAUFqmLdNMdS2uSUM2uWp0kuk dbjgxMMG8mWH8UjzVPp044CvfW0+MAGv2O8cRAYPQab0X0dQM68d8nIcdNCCzI8t8N cUQAfnK06T25dTZQSpm8dAvJFUhyHaIzkREbB4Go=
To: dnsop@ietf.org
References: <151984683961.5212.6854317117587193083@ietfa.amsl.com> <39567D9A-312D-42A8-A108-C8F7EE249668@verisign.com> <99AB422F-C607-412B-BC5C-A1DE17CD2393@apnic.net> <2C0BDA4D-E1E4-48A1-AB54-EFF31F55EB7E@verisign.com> <DE4E39D1-DD65-44C7-9120-3C155D460BDC@apnic.net> <72A1494B-E266-41AF-B215-07153FC70FCF@verisign.com>
From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat@nic.cz>
Message-ID: <c4be8cf8-1da5-b4c7-12e9-ec6653061ca8@nic.cz>
Date: Mon, 19 Mar 2018 17:26:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <72A1494B-E266-41AF-B215-07153FC70FCF@verisign.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H2XH2MyR5Mv9uR_JNY-PCDN7_GI>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 19 Mar 2018 16:26:51 -0000

On 03/06/2018 01:30 AM, Wessels, Duane wrote:
> I think its different.  The above can tell you whether certain names were resolvable (maybe even validatable?) but kskroll sentinel tells you that specific key tags are or are not present in the TA store even if those keys don't have "active" chains of trust.

Yes, the point of this RFC is to disclose information that we don't know
how to obtain without the RFC.  The question is whether the positive or
negative potential of this disclosure is larger (possibly in each
deployed instance separately).

TL;DR: altogether the risks known so far seem acceptable to me.  The
"leaked" information is noted in the "Security Considerations" section
(incl. third parties).  Of course, implementations might like to provide
a way to disable compliance to this RFC.

If a root key is compromised, this information does seem misusable to
simplify choosing targets for attacks.  Here it might be good that the
RFC is written to disclose only the root trust.  The RFC might
theoretically be amended to handle revoked keys in a special way - to
hide some parts of information that we don't need now, but such attempts
don't seem worth it (to me).  One reason is complexity, and the more
important one is that it will also be *useful* that people have a way to
test that their resolver correctly distrusts revoked root keys.  Note
that the good testability effects of this RFC apply even in regular
rollovers (without key compromise), so we can detect bad instances more
easily, and the negative effects only apply in the (unlikely) case of
root key compromise.  (It seems similar to usual
security-through-obscurity arguments.)

I suppose cases like Freedonians will need some extra patches or
configuration knobs, in case they want to hide their non-compliance
while appearing to follow the RFC.  That is, assuming the non-compliance
can't be found out in some other easy way (already).

--Vladimir