Re: [DNSOP] Incremental zone hash - XHASH

Warren Kumari <> Wed, 25 July 2018 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6268C130DD4 for <>; Wed, 25 Jul 2018 09:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 pGCoQhGhM4AR for <>; Wed, 25 Jul 2018 09:30:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF57E126BED for <>; Wed, 25 Jul 2018 09:30:40 -0700 (PDT)
Received: by with SMTP id q10-v6so7995878wrd.4 for <>; Wed, 25 Jul 2018 09:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1d1NsYUmAPDHWsIt760Tlnimy36y2pNtMqHXFqzitZ4=; b=2AQwU935y2MZh5vNDjcaiNzW3EkNneDpc19ajpIVJd6tprNM7Q98cOqvgM6z1juo50 VJU/vZVoEExE2HQy4eLcLwJsYDNO/uA4tzCQ4CwAgOZwKqfjllGbDBHuUXZr9hLrbfy6 DG+TMLSCS4BHjdHqZVtdMqB0a6mXfXKm4g2M8x1ozxas886LHS+bYy3Yf4b7Ms1wy+gk uTRR2LPC/I41VHAPFFaDMfQWdeJYTNHlh1yCcAAQXOUHTdxnVBRJcWTiW9UqBedtu1o0 0Xx71/hD8ln2bi6QDGa3Cu0FN4lsPmLNwIIjkURtFRDGqPSTIVBylqmF3hkmuhxmGBLC FUzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1d1NsYUmAPDHWsIt760Tlnimy36y2pNtMqHXFqzitZ4=; b=gE8Jf++8nOtc+EEt3IyKgqg+1FkpxLtG3wOnXtnfpSnfrQ4npii0z5OTO1cn2v7azX GBMH3UTyn5Jgz0y7rehui644d42R/FBPZ7DV6QhI8Wzc+6OApDEgVmlqbD1aIc4Vyt8E 6eqiNnfhGjw8iWQ1pPVs1tbtzn1j1UFVYNUeNPkqhAX5IYZQ7Pm0NdllhjG8M59DrcC0 q2xrH+DFyct/A961kvDP8zfZ1qZvUNkv2CAr2WrpfhyT+nWVbvX0XxNW+NGrD3x1I02E eQRsErb4WOvn3SW5TIaeybUqGRaSnHPtGZmLPFSJ4PqVA1EAgpzv7LwIP+NNVjWL59rt wYkQ==
X-Gm-Message-State: AOUpUlH5vwij7rqrUIjvB+1dpO6OwY8yK6UNSraPJIZXlsiAJWPRLbX2 oJ6JLucPmjRQ/w3M8oIFFI1YiZkfgOzXmAc4WxvXa1bzquQ=
X-Google-Smtp-Source: AAOMgpfqhA2sZ2cytHAHbLmIv4F9rdfMQFQ2T9e4yuZ5QJW5y1lBVacD0p/GrrJWVsEHZJDAQpSRmaju/E4S7HVd/c8=
X-Received: by 2002:adf:ad38:: with SMTP id p53-v6mr15609990wrc.10.1532536239259; Wed, 25 Jul 2018 09:30:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Wed, 25 Jul 2018 12:30:03 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Incremental zone hash - XHASH
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Jul 2018 16:30:43 -0000

On Sun, Jul 22, 2018 at 2:51 PM Paul Wouters <> wrote:
> On Fri, 20 Jul 2018, George Michaelson wrote:
> > The intent (to me at least) is to be able to use exterior fetch, *not*
> > DNS, to source this as a file. curl. wget. ncftp. rsync.
> So pull it over HTTPS/TLS and you are good? No bits will be allowed to
> be flipped without the transport security freaking out.
> If you are looking at additional trust on the data, we have DNSSEC. If
> you are concerned about glue/NS being unsigned and modified at the
> source, then you need some kind of signature over the data that the
> web server cannot modify.
> I see no reason why this should be an RRTYPE though. Especially one that
> can only work in weird automated ways of generating a signature over a
> file which you then modify to add the signature in.
> Especially since using an RRTYPE means you are fully relying on DNSSEC
> as the pubkey for signing the data. And if you use DNSSEC, why care
> about unsigned data?
> >> Verification of a AXFR ....
> Since you dont want to mandate the DNSSEC key on the server serving the
> data, it has to be some external key/checksum/transport security, which
> we already have for *XFR permissions? If *XFR doesn't use that for
> glue/NS, can we not just add a a checksum here based on the XFR keys?
> ZONEMD and XHASH seem to be the wrong hammers to use here, unless I
> misunderstood the problem?

One of the original promises of DNSSEC is that I'd be able to find a
zonefile written on a napkin on a bar floor, and trust it -- currently
I cannot do this.

As an example, let's say we'd like to distribute the rootzone over
BitTorrent to people who want to do LocalRoot - how do they know they
can trust the zone file before loading it? Or, in a less crazy
example, distribute it over some set of CDNs - being able to know that
you have the full, and correct zone without having to walk the NSECs
and hope that the glue is correct would (IMO) be nice.
Coordinating keys with just anyone who does an AXFR of a public zone
is not really viable.


> Paul
> _______________________________________________
> DNSOP mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.