Return-Path: 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 6A85A128C65 for ; Thu, 1 Nov 2018 08:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 37FEf-YYyxUt for ; Thu, 1 Nov 2018 08:40:17 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 AD1C81252B7 for ; Thu, 1 Nov 2018 08:40:17 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id e74-v6so2601522ita.2 for ; Thu, 01 Nov 2018 08:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qC+vsXbamaEK11VLg8f/t5DTJErTbsnS1qZ8KI/A/qU=; b=FW45iLcYjVA/9P+J5VpH8jBMA5aiw4NOjz0zjZjKZjnGpXBMY92u7LL5jiHOkCEQof 4EpBP/vXr4hmHRvZZRqwcF7GqEPzZ4kTWW76jfxjjDNNYIGOYgcAvz3FayL2g4iYfLWn XCAs+VlgkBmwC2VSNa+Ql12hQm4ciX2rj9otU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qC+vsXbamaEK11VLg8f/t5DTJErTbsnS1qZ8KI/A/qU=; b=qB68mUqVyLfi1iYp/sMM+XQII75hPKP3vZmWJrxEECIFktyiYJ+C2ak05EZ+GP+U0B lH/cGQzVn7jAMvaPN0n0xWVQr0a7+r0psZ0Q3RGodKYZirwcjhvpQIW0S0PQ8ECjJ2Is fEn1dT+KUMvehfaG4QkvS6+S6fVXb/I35qJ7rwF/ajONFe/nuGGKLTc7ZYy84IID9c62 +rlI/7Ln7XL36aQjffPX8JnKjOCFCeAprzv03ikylxAuYdmvBizoOp0O4Kr0XgBuzeg+ USnrtQw0feF5mNhrGqjlVM2AK1FdmJZ0AJ+xxj/C1lQrzWdfBD5fTOHP67Q9Ts19oUlm E1bA== X-Gm-Message-State: AGRZ1gLVXspd7PQbKBZFQscnVdNWMnfn5GK1JNFusoLZeZJtUA1XhrCd PB3/jtgID6qx8Si/yvqGHlGzxeFD2g8= X-Google-Smtp-Source: AJdET5egrfA3ib0YKNIR3Stg0OC9nWNQsMqgL6re9FMrGx3R8IIV8ymQhKjIPLmEvak5cbwyfsOXag== X-Received: by 2002:a24:6c14:: with SMTP id w20-v6mr5694287itb.103.1541086816647; Thu, 01 Nov 2018 08:40:16 -0700 (PDT) Received: from [172.30.135.152] ([129.100.255.32]) by smtp.gmail.com with ESMTPSA id d8sm9613909itk.38.2018.11.01.08.40.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 08:40:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (16B92) In-Reply-To: Date: Thu, 1 Nov 2018 16:40:14 +0100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <7966734C-7229-4173-8CD8-BD57BEC33D1C@hopcount.ca> References: <154020795105.15126.7681204022160033203@ietfa.amsl.com> <509F5E08-5EDF-4A54-BB34-A76BA390F01D@verisign.com> <263f71ee-05ab-84e1-bb61-4139941b4346@andreasschulze.de> To: Paul Hoffman Archived-At: Subject: Re: [DNSOP] [Ext] review: draft-wessels-dns-zone-digest-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 15:40:20 -0000 On Nov 1, 2018, at 16:27, Paul Hoffman wrote: > The current ZONEMD draft fully supports algorithm agility. What it doesn't= support is multiple hashes *within a single message*. Having seen how easy i= t is to screw up OpenPGP and S/MIME message processing to handle multiple ha= shes, I think having one hash per zone is much more likely to work. Suppose everybody supports digest algorithm A (e.g. it's the digest type tha= t was mandatory to implement in the original specification). We use that in o= ur ZONEMD RR because we have high confidence that clients will support it. At some later time digest algorithm B emerges which has some advantages over= algorithm A. B is newer and not all software supports it. We would like to u= se B because its advantages are attractive to us, but we also want all of ou= r clients to be able to use the ZONEMD RRs we publish. Since B is new we have lower confidence that it is supported by our current c= lients. We cannot use both A and B simultaneously on the publication side, since the= specification requires us to choose just one. There is no signalling mechanism that will give us insight into our client p= opulation's support of algorithm B, even if we have non-empirical expectatio= ns that support will increase over time. Since we don't want to break things, we cannot use B. Joe=