Re: [DNSOP] Comments regarding the NSEC5

Jan Včelák <jan.vcelak@nic.cz> Wed, 11 March 2015 16:39 UTC

Return-Path: <jan.vcelak@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767F41A1A8E for <dnsop@ietfa.amsl.com>; Wed, 11 Mar 2015 09:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.239
X-Spam-Level:
X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_71=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 bwbzshhjD6Cr for <dnsop@ietfa.amsl.com>; Wed, 11 Mar 2015 09:39:39 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863031A1A90 for <dnsop@ietf.org>; Wed, 11 Mar 2015 09:39:39 -0700 (PDT)
Received: from [192.168.0.111] (ip-89-177-126-217.net.upcbroadband.cz [89.177.126.217]) by mail.nic.cz (Postfix) with ESMTPSA id C112813FA01; Wed, 11 Mar 2015 17:39:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1426091977; bh=GTCb88RqakAHDpIUbjt3B6Hjimv3k21WkzYco+JP2pQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Hmn7QIKEtkkpDCUnz3xiu14VJfObGhzrwFEG2k+4kdtbhrInVBAY+5MJMm83wm/x3 7ivC/uNChVConHgMrY92mGxM54u3l+det4xUMEGG2W7fTlbdvih5H42AU2z7rSuwWb y5IjokGwZxJp+cdRlkV1GWm5QE1RnQQ3MKMmHys4=
Message-ID: <55006FC7.1030206@nic.cz>
Date: Wed, 11 Mar 2015 17:39:35 +0100
From: Jan Včelák <jan.vcelak@nic.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Florian Weimer <fweimer@redhat.com>
References: <55002098.5060709@redhat.com> <55006AF8.4090500@nic.cz> <55006D98.7000300@redhat.com>
In-Reply-To: <55006D98.7000300@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.6 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/WSRiNnXKM7AKZcH0zRES-gEUXqc>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Comments regarding the NSEC5
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 11 Mar 2015 16:39:40 -0000

On 11.3.2015 17:30, Florian Weimer wrote:
> On 03/11/2015 05:19 PM, Jan Včelák wrote:
> 
>>> It's not clear if the security goals make sense.  What do zone operators
>>> gain if zone enumeration attacks are moved from offline to online, other
>>> than a need to provision additional server capacity?  It's not that they
>>> can block resolution requests from large resolvers if a part of their
>>> client population participates in aggressive enumeration.
>>
>> It dependes whether you see zone enumeration as a problem.
> 
> If I really want to enumerate a zone, I will just send my dictionary as
> queries, possibly through open resolvers.  People are reckless like
> that.  At least with NSEC3, polite attackers can do some of the
> processing off-line, without punishing authoritative servers or
> resolvers.  NSEC5 takes away that option.  Do the existing enumerators
> care?  Who knows.

I really can't tell. I don't know.

>>> Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in
>>> [RFC6234].”  Are you sure that's right?
>>
>> You mean the reference to the RFC? Yes, I think it's right. Or am I
>> missing something?
> 
> I'm guessing, but “NSEC5 hash” is probably what involves FDH.  Based on
> your comment,s it's clearly *not* SHA-256, contrary to what I quoted above.

NSEC5 proof is the FDH of domain name.
NSEC5 hash is SHA-256 of NSEC5 proof.

I will clarify that.

>> We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology
>> section). The NSEC5 proof is the FDH (can be comptuted only by the
>> holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of
>> the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof).
>>
>> So in your notation, an NSEC5 RR owner name should be:
>> Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey)))
> 
> And the inner part (without the Base32 encoding) is the NSEC5 hash?  Or
> is the SHA-256 hash skipped?

Yes, the SHA-256(...) is the NSEC5 hash. The input is NSEC5 proof.

Jan