Re: [DNSOP] Multi Provider DNSSEC Models

Tony Finch <dot@dotat.at> Wed, 21 March 2018 00:38 UTC

Return-Path: <dot@dotat.at>
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 B1B7D12D7E2 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 17:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 Svvs7d-HXjBn for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 17:38:29 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7596A12D77B for <dnsop@ietf.org>; Tue, 20 Mar 2018 17:38:29 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D073320DA9; Tue, 20 Mar 2018 20:38:28 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 20 Mar 2018 20:38:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6MGJGU dpLBrP4mV4ph71hzfBFQzugfDLpGfyTB2xoBA=; b=IKOwkztpO7thHcotcsKEWW UuTgL+daa6wASGa6qhiXC8dJ6fZot/j6qzO3VfY8qgqiCxAXLSdbTDkB3mZ0FaO2 LimsElsNqegTcX7h8s67FhS3ukJxHt+YJDlJnAZU3XZHV24di5H+6wKhBObsCLZn OjUcsiRD0c8hy6o/tXOl6odwebd/7wbXZbiskHSQzXam6i8t9mzJaMvGz+tnbU2m ja3hYd8EBgJ/bVti2yCPDAyldQQwYEX8p0qZw3CLE72o60JSdVa3KAn+B8YbzmLn 9crJ+5rjq8EBnU0siekWk63zZSpQYxfxYWPgPTZJ2R7HD9zgw2vRr3qZ7GBA2SFg ==
X-ME-Sender: <xms:hKmxWg_bRucwGw8R2CxOTLThT4iChhaIoge5JQYKW89gXbNns_3nDQ>
Received: from [10.48.243.38] (188.29.165.97.threembb.co.uk [188.29.165.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 5AE947E16A; Tue, 20 Mar 2018 20:38:28 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-88D15397-39A4-455A-8AA8-AE4E409CDA7F
Mime-Version: 1.0 (1.0)
From: Tony Finch <dot@dotat.at>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <CAHPuVdVi5C3nyVuG2aiLefN7eFPOx+GnOCxU40iio_Gn0oQ8qA@mail.gmail.com>
Date: Wed, 21 Mar 2018 00:38:25 +0000
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <DFCE50F5-2385-4512-BF9F-1266C0DA4D6E@dotat.at>
References: <CAHPuVdVi5C3nyVuG2aiLefN7eFPOx+GnOCxU40iio_Gn0oQ8qA@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mw03El1CcP7EThLeVNntcdpCR2M>
Subject: Re: [DNSOP] Multi Provider DNSSEC Models
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: Wed, 21 Mar 2018 00:38:32 -0000

> On 20 Mar 2018, at 11:50, Shumon Huque <shuque@gmail.com>; wrote:
> 
> We've posted a new draft on Multi Provider DNSSEC models,
> which we're planning to discuss at Thursday's DNSOP session.
> 
> https://tools.ietf.org/html/draft-huque-dnsop-multi-provider-dnssec-02

I have read through it, and it looks pretty good, though I think you are burying the lede.

The first time I looked through I missed the clever parts, and thought to myself that half of the models described in section 2 would make people very sad. But section 4 on resolver behaviour explains the cleverness that avoids making people sad (sharing public keys), so I looked through the model descriptions more carefully and saw that they do in fact mention the trick.

To fix this misunderstanding, the introductory paragraphs in section 2.2 need to explain your cleverness a lot more explicitly. eg this sentence: 

A key requirement here is to manage the contents of the DNSKEY and DS RRset in such a way that validating resolvers always have a viable path to authenticate the DNSSEC signature chain no matter which provider they query and obtain responses from.

Yeah, validation has to work, I know, now tell me the clever trick up front otherwise I might not realise there is one!

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at