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

[Paul Hoffman <[e-mail]>]

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

> 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.  

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
> 
>   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?

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.

> ===
> 
> 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?

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.

> ===
> 
> 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?

Yes.

> ===
> 
> 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.

Sure.

> 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.


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

--Paul Hoffman