Subject: [DNSOP] FYI - Added note about ECDSA resolver issue in Sweden - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt

From: Dan York <[email-masked]>
Date: Mon, 31 Oct 2016 03:49:57 +0000

FYI, I submitted a new version of this draft that added some text in the section about "Resolvers" that mentions the case Mikael Abrahamsson brought to us about how they had to disable DNSSEC validation in the CPE they deployed to their customers because the resolver software was not following RFC 4035 and was not ignoring signatures with unknown algorithms.

Comments are of course welcome.

For those who are interested in writing I-D's with markdown, I also transitioned the source of this version of the document to the flavor of markdown that works with Miek Gieben's 'mmark' processor. Paul Jones nicely packaged mmark and xml2rfc into a Docker container that works extremely well. This document and other links can be found in my Github repo at: https://github.com/danyork/draft-deploying-dnssec-crypto-algs

Dan

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
Date: October 30, 2016 at 11:37:13 PM EDT
To: Ondrej Sury <[email-masked]<mailto:[email-masked]>>, Olafur Gudmundsson <[email-masked]<mailto:[email-masked]>>, Dan York <[email-masked]<mailto:[email-masked]>>, " [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Wouters <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
has been successfully submitted by Dan York and posted to the
IETF repository.

Name: draft-york-dnsop-deploying-dnssec-crypto-algs
Revision: 02
Title: Observations on Deploying New DNSSEC Cryptographic Algorithms
Document date: 2016-10-31
Group: Individual Submission
Pages: 9
URL:            https://www.ietf.org/internet-drafts/draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
Status:         https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
Htmlized:       https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-york-dnsop-deploying-dnssec-crypto-algs-02

Abstract:
  As new cryptographic algorithms are developed for use in DNSSEC
  signing and validation, this document captures the steps needed for
  new algorithms to be deployed and enter general usage.  The intent is
  to ensure a common understanding of the typical deployment process
  and potentially identify opportunities for improvement of operations.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: George Michaelson <[email-masked]>
Date: Mon, 31 Oct 2016 14:22:43 +1000

It is only my personal opinion, but I believe registrars are incorrect
in performing crypto alg checks on proffered DS, and this is an
entirely unwarranted, and incorrect understanding of their role. It
conflates one public good (checking) with another public good
(registry of data into the DNS) and assumes one out-ranks the other:
It doesn't, and the inability to track crypto alg change, makes the
checking wrong. Its the lesser of two evils to stop checking, and
permit unknown algorithms through.

I think this needs to be flagged up. Either they should be told to
stop, or the requirements for algorithm agility which their role
places on them should be made explicit.

-George

On Mon, Oct 31, 2016 at 1:49 PM, Dan York <[email-masked]> wrote:
> FYI, I submitted a new version of this draft that added some text in the
> section about "Resolvers" that mentions the case Mikael Abrahamsson brought
> to us about how they had to disable DNSSEC validation in the CPE they
> deployed to their customers because the resolver software was not following
> RFC 4035 and was not ignoring signatures with unknown algorithms.
>
> For those who are interested in writing I-D's with markdown, I also
> transitioned the source of this version of the document to the flavor of
> markdown that works with Miek Gieben's 'mmark' processor. Paul Jones nicely
> packaged mmark and xml2rfc into a Docker container that works extremely
> well. This document and other links can be found in my Github repo at:
> https://github.com/danyork/draft-deploying-dnssec-crypto-algs
>
> Dan
>
> Begin forwarded message:
>
> From: <[email-masked]>
> Subject: New Version Notification for
> draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
> To: Ondrej Sury <[email-masked]>, Olafur Gudmundsson
> <[email-masked]>, Dan York <[email-masked]>, " [email-masked]"
> <[email-masked]>, Paul Wouters <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
> Htmlized:
> https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-york-dnsop-deploying-dnssec-crypto-algs-02
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> --
> Dan York
> [email-masked]   +1-802-735-1624
> Jabber: [email-masked]
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 31 Oct 2016 12:37:44 -0400

> places on them should be made explicit.

I know of a couple of cases where registries perform similar checking.
Depending on the implementation, the registrar may need to perform the
checks themselves in order to prevent future upstream calls from generating
errors.

I think the way I'd implement this is to perform "best effort" checking.
If I know the algorithm, then make sure that the DS/DNSKEY supplied is
correct for that algorithm.  If I don't know the algorithm, pass it through
as-is (and log it so that I can have my developers investigate and add that
algo to the check library).

---

From: Geoff Huston <[email-masked]>
Date: Tue, 1 Nov 2016 11:15:13 +1100

> On 1 Nov. 2016, at 3:37 am, Matthew Pounsett <[email-masked]> wrote:
> 
> 
> 
> I know of a couple of cases where registries perform similar checking.   Depending on the implementation, the registrar may need to perform the checks themselves in order to prevent future upstream calls from generating errors.  
> 
> I think the way I'd implement this is to perform "best effort" checking.  If I know the algorithm, then make sure that the DS/DNSKEY supplied is correct for that algorithm.  If I don't know the algorithm, pass it through as-is (and log it so that I can have my developers investigate and add that algo to the check library).  

I pretty much agree with Matt here. I believe that this falls into a similar area as checking the NS records, and the justification is approximately along the lines of “if it lives in the zone file I should check that resolvers won’t encounter errors - to the extent I can”

---

From: George Michaelson <[email-masked]>
Date: Tue, 1 Nov 2016 10:22:24 +1000

The net effect is the same in respect of new algorithms. I'm fine with
checking conformance if the algorithm is known, it feels like a low
bar.

Rejecting sigs because you don't know how to check feels like a huge
impediment to technology: The use of the new algorithm is now gated by
the ability of registrars to adopt it, rather than the rate of
deployment by the actual zone holders.

-G

---

From: Geoff Huston <[email-masked]>
Date: Tue, 1 Nov 2016 12:47:15 +1100

> On 1 Nov. 2016, at 11:22 am, George Michaelson <[email-masked]> wrote:
> 

—— back to bottom posting

I’m not necessarily disagreeing with you here - in saying that a “best effort” checking is a responsible position to take, that does not mean that unknown algs are not accepted. Neither Matt nor I have argued here in favour of "rejecting sigs” that are generated using unrecognised algs  - it means that they are not checked before zone inclusion was the intention.