Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update

Michael StJohns <> Mon, 20 March 2017 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F7651287A7 for <>; Mon, 20 Mar 2017 08:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 HqU3S0Uwx_4z for <>; Mon, 20 Mar 2017 08:52:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F1F81294CF for <>; Mon, 20 Mar 2017 08:51:56 -0700 (PDT)
Received: by with SMTP id x35so110096784qtc.2 for <>; Mon, 20 Mar 2017 08:51:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=iLFN8F4qfl+ILyCW1PoD7anxXwNKXkJ2lvHvmwJo3fM=; b=yttuobMSPO10TjBkrnRQz1I0WMBkx3QJPIZmCNMfzlhoK/Z6UBi0NeYgRB1nepI2EX q4BJSurYjrd/puUp4HqKQZdWDwmD3feU2W9xSLeMlevZ/xzp1GcGH7ovbuT3A6m8HuEQ YaPgYZfBTv4XZ6IrNH0WSEfPMsnMkI8DgRBX66VZxVOghi49SIws5NhqMErD0WSfOl89 7DgvlyT0nAg1kIgeFSwv9HiOvDyJv2lyopjdGfq6mpoFRqNP8frkZ8Z+8GhJpwq5NlTW g2ZDiNpfLwWpk0EsjXCo2kshsLzLU2tqp2PewD6xQm+lRBIZSPMj4pQhvjeaq6gISa8+ yLiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=iLFN8F4qfl+ILyCW1PoD7anxXwNKXkJ2lvHvmwJo3fM=; b=NF/mgCv74pnrjP9R33QG0l5ywz3UNbuDaRNpJH8BMr0xptYzYLZEUjNpR03jRHiJdC a+/Xk/vce//PAy3EWRNEhwlyY5ymwzy6O2rzeIfvRBpPUvnm3Hzs+CPvzvlSmWjb7KJi QmPhqh1ASggi6wI0cnoSJkjuxRFR2Ub/+Pz0S/6nEWClbKcyZgbhx247z8Qihrg+dXtb efs4c1cr6N4Zm/B3drFnMaiSTyH6R50vgpfJdgZl3jSzfPDTj5DEDSp2kOFGOAvVn2+D qKtQu8LZM5hy36q45a+hpFpk91wV27hlV0mIRPLt7mZ6dmczInWkEsm552aVUEZMOEF2 PXPA==
X-Gm-Message-State: AFeK/H3uMxLCL5EePMQzsGC0cH8jL9WXCmNJgnwQt47QQg7Xm6QASks7CHHvyE6TiZDB6w==
X-Received: by with SMTP id w17mr30404283qta.179.1490025114808; Mon, 20 Mar 2017 08:51:54 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:513c:7598:48a0:ae76:31c9? ([2601:152:4400:513c:7598:48a0:ae76:31c9]) by with ESMTPSA id a18sm12604355qkb.10.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 08:51:53 -0700 (PDT)
References: <> <> <> <> <> <> <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Mon, 20 Mar 2017 11:51:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------EE34BFB7AFC39BE3BF8CAA01"
Archived-At: <>
Subject: Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 15:52:10 -0000

On 3/16/2017 12:38 AM, Doug Barton wrote:
> I can't help finding this discussion funny, as I proposed prior to the 
> -bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for 
> the simple reason that it was overwhelmingly likely that the root 
> would be signed with the former, making it as close to mandatory to 
> implement as possible without documenting it as such; and the latter 
> as interesting as day-old bread.
> Now here we are 13 years later, still having the same discussion, 7 
> years after the root was signed with (you guessed it) RSA-SHA256. :)

Hi Doug -

I don't disagree.  But part of the problem is that there are probably 
zones that are only signed with SHA1.   There ought to be a second 
document that says "Signing with SHA1 ends on this date", but that can't 
be done as a registry update AFAICT.    What can be done is sort of give 
the hint to the implementers that there's a transition in progress and 
that the MTI will be changing, and that the current MTI is going away.

In any event, this (my note) was a procedural suggestion that *_we 
generally don't do operationally critical changes to code without some 
warnings to the community_*.  While most folk knew this was coming - 
until its a "standard", many will not care. Once it's a standard, not 
doing the change becomes costly in terms of liability.

We're (the community/ICANN) in the process of doing a root key change 
for the first time ever - the notices and planning on that took years.  
Giving some notice that the MTI for signing is changing before actually 
changing the implementation guidance seems useful.

> DNS has a long tail indeed.
> On 03/15/2017 10:22 AM, Michael StJohns wrote:
>> On 3/15/2017 6:26 AM, Roy Arends wrote:
>>> In the spirit of being constructive, we (Jakob Schlyter, Matt Larson
>>> and I) have written a small draft
>>> (draft-arends-dnsop-dnssec-algorithm-update) that does two things:
>>> it changes RSASHA1 from “Must Implement” to “Recommended to
>>> Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
>>> it changes RSASHA256 from “Recommended to Implement” to “Must 
>>> Implement”.
>>> The main motivator for this is that implementors have an incentive to
>>> move their implementations “default use” away from RSASHA1 (for
>>> instance, when a user generates a DNSKEY without specifying an
>>> algorithm, or when choosing an algorithm for signing in the presence
>>> of more than one algorithm.
> FWIW I agree with Roy that we should make 256 a must-implement ASAP 
> (since for all practical purposes it is already), and encourage 
> implementors in the strongest possible terms to make it the default.
>> Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))
> Michael, this is pointless, unless you can demonstrate how an existing 
> implementation works without being able to use the root key.

Fair enough.  But again, this isn't completely about the implementation, 
it's about the operation even though this document will only directly 
affect the implementation.

>> Must Not Implement:  RSASHA1 (After 1/1/2021)
>> Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until
>> 5/31/2018)
> Mostly pointless, although there was an interesting point raised about 
> the difference between producing signatures with SHA1, and being able 
> to validate them. Telling people that we're creating a long tail by 
> letting them continue to use SHA1 for N years will result in a tail of 
> minimum N + 10 years. So telling people to stop using it NOW is the 
> right answer.

This guidance applies both to the server side and client side.  The idea 
here is that as of 6/1/2018 no one should be able to count on a client 
being able to validate SHA1 (and zones shouldn't be signed with it, but 
could be for legacy reasons), and that after 1/1/2021 the chances of a 
zone signed with SHA1 being able to be validated go down quickly and 
that zones must not be signed with it.

Sorry - I look at this the same way I looked at building 5011.   The 
servers and clients are very loosely coupled - so loosely coupled that 
the servers are sending data to the clients fairly blindly without any 
real knowledge of what they can understand in terms of the data 
content.  (EDNS gives you information on  DNS transport, not DNS data).  
So providing implementation guidance has to understand that split, has 
to understand that when you move Required to Recommended and Recommend 
to Required some implementers will only implement the new required, and 
that the implementers of the clients may not be in sync with the 
implementers of the servers leading to disconnects.

If you want to add SHA256 as a Required immediately, I have no issues 
with that (and you are correct in that that should have been done years 
ago), but I would object to removing SHA1 as a required without a 
deprecation phase for the reasons above.   I'd also *really* like to 
have a final phase out date for SHA1 as well.

If DNSOP instead issues an operational guidance document to be released 
in conjunction with this algorithm update explaining when the zones 
should stop signing with SHA1, I think *that* would be the best of both 


> I'm torn on how to deal with validation though. "Compliant 
> implementations MUST generate a warning when validating signatures 
> with algorithms weaker than RSA-SHA56. Compliant implementations MUST 
> generate an error for such algorithms starting 4 years from the 
> publication of this document as a draft standard, and unless the 
> records are signed with a compliant algorithm they should be 
> considered unsigned."
> Something like that, although obviously it needs polishing.
> Doug
> _______________________________________________
> DNSOP mailing list