Subject: [dnsext] Possible changes to draft-ietf-dnsext-dnssec-algo-imp-status

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Jul 2012 14:06:01 -0400

Hi,

Pete Resnick has a DISCUSS on this document.  Addressing his comments
requires significant text, so I wanted to confirm with the WG.  I
believe all of these are completely in line with what we intend, but
with so many changes I thought it unwise to proceed without
confirming.  I've marked the items off with === delimiters

===

First, the paragraph

   This implementation status indication is only to be considered for
   implementation, not deployment or operations.  Operators are free to
   deploy any digital signature algorithm available in implementations
   or algorithms chosen by local security policies.  This status is to
   measure compliance to this document only.

in section 1 would be removed completely.  Pete is not the only AD who
has objected to this.  Any objection?

===

Pete's suggestion is to change the column headers in section 2.2 to
titlecase, and add these definitions to the document (in 1.1):

   - "Must Implement" means that the algorithm MUST be used in order
     to interoperate with other implementations on the Internet.

   - "Must Not Implement" means that the algorithm MUST NOT be used so
     as to prevent the compromise of the DNS data; the algorithm has
     known weaknesses and is not considered safe to use anymore.

   - "Recommended To Implement" means that the algorithm SHOULD be
     used in order to interoperate with other implementations on the
     Internet, though there may be exist valid reasons in particular
     circumstances not to do so. An implementer must understand and
     weigh the full implications of choosing not to implement this
     particular algorithm.

   - "Optional" means that the algorithm MAY be implemented, but that
     all implementations MUST be prepared to interoperate with
     implementations that do or do not implement this algorithm.

This seems reasonable to me, and solves the problem that the words
otherwise looked like slightly unusual 2119 keywords.  Any objection?

===

The paragraph

   This table does not list the Reserved values in the IANA registry
   table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID
   (254).  These values may relate to more than one algorithm and are
   therefore up to the implementer's discretion.  Their implementation
   (or lack thereof) therefore cannot be included when judging
   compliance to this document.

would be rewritten to say

   This table does not list the Reserved values in the IANA registry
   table or the values for INDIRECT (252), PRIVATE (253) and PRIVATEOID
   (254).  These values may relate to more than one algorithm and are
   therefore up to the implementer's discretion. In that sense, they
   might be considered optional, but their implementation (or lack
   thereof) has no bearing on interoperability and therefore they do not
   appear here.

Ok?

===

Finally, because this says "Applicability statement" on it, and it
appears in fact to be one, Pete wants to say it goes on the standards
track as PS.  Any objection?  Otherwise, we need a new title.  This
decision is nominally supposed to be up to the chairs anyway, but I
recall some discussion about this before so I thought I'd ask whether
anyone has strong feelings.

I believe that covers every planned change.  Comments would be
appreciated as soon as possible, and in any case not later than one
week from now.  If nobody objects, these changes will all be made.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jul 2012 15:57:34 -0700

On Jul 18, 2012, at 11:06 AM, Andrew Sullivan wrote:

> confirming.  

Let me be clear here: What Pete wants is a fundamental change from what the WG and the IETF consensus was. The consensus was on "need to implement, not deploy"; what Pete is asking for is "deploy".

This fundamental change makes absolutely no sense for this document. If Pete insists that we can only say what is mandatory to deploy, we need to start over again.

> I've marked the items off with === delimiters
> 
> ===
> 
> First, the paragraph
> 

Yes. Without this paragraph, someone who runs a zone and sees this RFC, but does not know the sketchy IETF lore of "mandatory to implement does not mean mandatory to deploy" will get a very wrong impression.

Pete's stated objection at <https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ballot/> is:

+++
I think the above paragraph is either wrong or meaningless. I don't know what it means to say that the implementation status is for implementation but not deployment. The reason that one "MUST IMPLEMENT" RSASHA1 is that an implementation will not interoperate with other DNSSEC deployments if it doesn't allow the use of RSASHA1. Similarly, the reason it is "RECOMMENDED TO IMPLEMENT" RSASHA1-NSEC3-SHA1 is that you won't interoperate in DNSSEC if you don't do it, but there are circumstances under which you might not use it. The reason you "MUST NOT IMPLEMENT" RSAMD5 is because it is a broken algorithm and use of it will cause damage. These are not about implementation; they are absolutely about interoperation. Operators *are* free to deploy anything they like, but that's because there are no protocol police and you are free to ignore the considered consensus of the IETF. But the considered consensus of the IETF is that these are protocol requirements to allow for interoperation. The IETF is *not* supposed to be writing compliance documents. Please strike the paragraph in it's entirety. See next bit on 2119 keywords for more on this.
+++

I disagree that "Operators are free to deploy..." is a "compliance document". In fact, it is the opposite. If there was an IETF doc that this doc could point to that says "here is what an implementation requirement means", that would be grand, but we don't have one, so we need to say it here.

Further, "The reason that one "MUST IMPLEMENT" RSASHA1 is that an implementation will not interoperate with other DNSSEC deployments if it doesn't allow the use of RSASHA1" is factually wrong. If someone doesn't follow the "MUST IMPLEMENT" there, they can still interoperate with other deployments as long as the two deployments use the same less-than-mandatory signing algorithm. The "MUST IMPLEMENT" is there so that every implementation is know to be able to interoperate with other implementations *if they all pick a common algorithm*.

Further, "The reason you "MUST NOT IMPLEMENT" RSAMD5 is because it is a broken algorithm and use of it will cause damage" is also incorrect. No one has shown a single plausible attack on RSAMD5 in the DNSSEC environment (which is completely different than the PKIX-with-sub-CAs environment where it has proven to be disastrous). The reason it is there is because of voodoo that is harmless.

Seriously: I believe Pete is dead wrong on this.

> otherwise looked like slightly unusual 2119 keywords.  Any objection?

Very strong objections. The first and third are clearly at odds with each other. If I only validate RSASHA1 and you sign with RSASHA256, we will not interoperate. Pete may not understand that "be used" means very different things for signers and validators. And, again, the "Must Not Implement" description is false. There are no known weaknesses with signing RSA with MD5 for DNSSEC; there are vague concerns, and we know we have better algorithms that everyone uses, so we might as well just get rid of it.

>   thereof) has no bearing on interoperability and therefore they do not

Yes.

> anyone has strong feelings.

Sure.

> week from now.  If nobody objects, these changes will all be made.

Again: very strong objections to the first two. They go against the consensus of the WG and IETF.

--Paul Hoffman

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 19 Jul 2012 12:14:13 +0200

> This fundamental change makes absolutely no sense for this document. If Pete insists that we can only say what is mandatory to deploy, we need to start over again.

I agree with this. I.e. that what Pete asks for is different from WG consensus.

   Patrik

---

From: Scott Rose <[email-masked]>
Date: Thu, 19 Jul 2012 09:26:59 -0400

> I agree with this. I.e. that what Pete asks for is different from WG consensus.

And different from the initial intent of the document.  This changes the document significantly, but if there is WG consensus on the change I can edit the doc.  

Scott

>   Patrik
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext