Re: [DNSOP] IETF meeting prep and what

Michael StJohns <> Wed, 30 June 2021 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA39F3A2E3C for <>; Wed, 30 Jun 2021 15:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 F7caUopdxDf2 for <>; Wed, 30 Jun 2021 15:43:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DFBF3A2E3A for <>; Wed, 30 Jun 2021 15:43:51 -0700 (PDT)
Received: by with SMTP id j13so4183460qka.8 for <>; Wed, 30 Jun 2021 15:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=l6PaFlDa4Re/YxswveZjRcDdzioflMeqh7rJRUseWeY=; b=qCuoj8mpr1zb1esAiQ7i3hfDNTn358xLrfdZ6wbAS3TQ7tv+4BjRxlw7T8aO9Nn7aq uB8NeqJopZw6RaFXoznTNncSZ9v+xG6wBqePTyknGziN7XOiZZmeoWeQLvIAhzl+H6YG a6vypHQe5xYlSk8i6O3CXjTo2Eni8F0Tb1XoPq/+iM6aucg9/AWtIr33DM98kfX41bU5 pr+6mOBLo90rU9XDNe2er8HLbqGMdSHkPFkkfciv3ygRn2GASO0fpJimbWnCtvLJbKXe nfZq7rChY76lO3BlasYXE4JThC2kRx7TaKnWC46bDIv94ME6VBeAcYo93KGS3xgibWft 95QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=l6PaFlDa4Re/YxswveZjRcDdzioflMeqh7rJRUseWeY=; b=ZIaSy/Q51XUg44yhJDj/cc9+DuVuRhBDt/S4AuXcCNfhZW7aS6EXz6b/FUQgmjyqSw nIJ00qkoxB6RewecTI6LYUfTgItM+T0k6s124se1XBVSxd8BCJU6u+sWz7RXt8GLSnET MyWjkUj9AI9eS5qDJi72F1Kxcqt5OzzSqkyCKEWNb7Rj2K7TOtcq+JHjZEEsDgqgtLNz e5Kgf76o3qAQgXiW/dNksBtEzoPNO3fYkZRrlGJWBEHjTuJoiiOwETizVOQN7mKE/UFM UzBbNgMkS9snU9PMY9QGVriSRWkFe+e4nNuQ51wHtPjvHJSJCuQeoa6ve+ugsjI9TCVL ORTA==
X-Gm-Message-State: AOAM530XzCtaddULC/Nn5OG2cyhALwvUgdWxbqU0OMiRzEKCHJ0jHMZx /sAZWUbVgpeyG0fjZhVx+O1ydEbwBi1Um/9TI/8=
X-Google-Smtp-Source: ABdhPJzZY2bxsF/7P49h5ba49RFVnenYZXn1qjx1/5uelAyE5sJ4J2+GXAYtnixvZO0jmq+T8zVN5w==
X-Received: by 2002:a05:620a:801:: with SMTP id s1mr10661324qks.432.1625093028239; Wed, 30 Jun 2021 15:43:48 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u13sm14327882qke.41.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Jun 2021 15:43:47 -0700 (PDT)
To: Mark Andrews <>
References: <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 30 Jun 2021 18:43:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] IETF meeting prep and what
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: Wed, 30 Jun 2021 22:43:57 -0000

On 6/30/2021 6:28 PM, Mark Andrews wrote:
> I’d argue that there are a magnitude more resolvers

Yes.   Be pedantic! :-)   I said "recursive resolver" and I really mean 
caching recursive resolver as opposed to stub resolver.   Fair?    I may 
be behind times, but few if any stub resolvers were actually doing their 
own DNSSEC validation (e.g. sending a CD bit to their recursive resolver 
and getting back all of the DNSSEC related records).

>   than browsers in the world.  There are lots of devices that have a resolver but don’t have a browser.  Think of all the smart light bulbs.  They all need to be able to update their trust anchors.  DNSSEC deployment is still in its infancy.

I get what you mean, but I don't actually think many of the tiniest of 
IOT devices will have anything more than an unsecure way of looking up 
their back office system - and then using TLS or something else to 
verify the connection.    Their only CA trust anchor will be to their 
vendor to start with and then to whatever local manager takes over 
ownership.   I could be wrong, but DNS has its greatest strength where 
you get passed a lot of different names that need to be looked up, and 
that mostly doesn't describe the IOT side of things.

Later, Mike

>> On 1 Jul 2021, at 05:26, Michael StJohns <> wrote:
>> Peter et al -
>> It might be useful to review RFC 4986 - - Requirements Related to DNS Security Trust Anchor Rollover - to understand what the problem requirements were/are before resurrecting this discussion again.   If the requirements have changed, then perhaps we need a new solution, but we should probably update 4986 before tossing 5011.
>> Peter -
>> WRT to your analogy to the CA system, I will note that browser clients (where the trust anchors are embedded for the CA) are not even close to being updated in the same manner as recursive resolvers (not simply "DNS clients") and many resolvers are used to provide services within various small and large organizations rather than being owned and updated by a single person.   For one thing, there are orders of magnitude more browers than there are resolvers.  For another,  resolvers are rarely updated automatically.   What would be interesting is to get some idea of the set of resolvers with no active management being performed on them - including software updates.
>> Mike
>> On 6/30/2021 2:59 PM, Peter van Dijk wrote:
>>> Hello DNSOP,
>>>> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough!
>>> I see this ruffled some feathers. Here's a more nuanced version.
>>> I feel that 5011, for the purpose of root key rollovers, is the wrong tool, -especially- combined with the trust anchor signaling that various resolver stacks sent to the root. Lack of clarity about where various signals came from, combined with some interesting bugs in implementations, has led to a lot of wild goose chases, and it would not surprise me (but I cannot prove) that bad data is what delayed the first roll for so long. Not actual problems predicted by the data; just bad data. (I have mentioned before that I think the trust anchor signalling was a mistake too, and any calls for 'more of this' are 'calls for more bad data' and we do not need more bad data.)
>>> I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSEC. Software distributors have solved this problem; they are very good at distributing things; I suggest we let them solve this for us.
>>> rfc5011-security-considerations is a good document, and I apologise for targeting it unfairly - my problem with 5011 is as above. Given my next two point, it probably makes sense to publish rfc5011-security-considerations.
>>> With heaps of 5011 'client' implementations out there, I am in no way proposing that root rolls happen in a way that that software could not follow along. I am only proposing that we write down that 5011 is not the best fit for the problem, and recommend against more client implementations of it *for the purpose of root key rolls*.
>>> I think (can't find it right now) that somebody mentioned that 5011 has its place outside of the root key system, inside enterprises. I'm inclined to disagree, but do not feel entirely capable of judging that. If (again, when there's WG bandwidth) we draft a document about why 5011 is a bad fit for the root, perhaps somebody can contribute text about the level-of-fit for other use cases.
>>> Kind regards,
>> _______________________________________________
>> DNSOP mailing list