Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-04.txt

From: [email-masked]
Date: Mon, 11 Mar 2013 08:20:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
	Author(s)       : Scott Rose
	Filename        : draft-ietf-dnsext-dnssec-algo-imp-status-04.txt
	Pages           : 7
	Date            : 2013-03-11

Abstract:
   The DNS Security Extensions (DNSSEC) requires the use of
   cryptographic algorithm suites for generating digital signatures over
   DNS data.  There is currently an IANA registry for these algorithms
   but there is no record of the recommended implementation status of
   each algorithm.  This document provides an applicability statement on
   algorithm implementation status for DNSSEC component software.  This
   document lists each algorithm's status based on the current
   reference.  In the case that an algorithm is specified without an
   implementation status, this document assigns one.  This document
   updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-imp-status-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsext-dnssec-algo-imp-status-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 15:16:07 -0400

Dear colleagues,

This update from Scott is an attempt to solve the objections raised in
an IESG DISCUSS without violating the WG's consensus that this
document was about implementation and not deployment.  I think it
walks that line, and I am comfortable going ahead.

If, however, you object, you need to squawk in the next 24 hours.
Otherwise, our AD is going to sign off.  This is a tight deadline
because (1) as shepherd, I am convinced this actually solves the
problem and (2) the document hung fire long enough that we are up
against the change of the IESG.  Please be aware that, if the current
changes do not solve the problem, I have no idea how to proceed; we
will probably have to abandon this document in that case.

Thanks to Scott for incorporating these changes and for being so
patient.  

Best regards,

A

On Mon, Mar 11, 2013 at 08:20:35AM -0700, [email-masked] wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 15:24:06 -0400

Dear colleagues,

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Mar 2013 15:28:14 -0400

> will probably have to abandon this document in that case.

I think this document is useful, and solves a problem.

One possible nit: the IANA Considerations Section specifies that this document (when published) act as The reference for the named IANA registry. It's not clear to me whether this adequately anticipates the addition of new algorithms in the future. I think it's reasonable for this document to provide a reference for all algorithms currently listed in that registry, but presumably future algorithms would be listed with different references, and the important thing is to specify that those references exist (i.e. that the documents by which future algorithms are added specify clearly what the implementation status of those new algorithms is).

Hence, I suggest in:

3.  IANA Considerations

   This document lists the implementation status of cryptographic
   algorithms used with DNSSEC.  These algorithms are maintained in an
   IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers.
   Because this document establishes the implementation status of every
   algorithm, it should be listed as a reference for the entire
   registry.

REMOVE:

   Because this document establishes the implementation status of every
   algorithm, it should be listed as a reference for the entire
   registry.

ADD:

   Because this document establishes the implementation status of every
   algorithm listed in this registry at the time of writing, it should be
   listed as the reference for all those algorithms. Future entries to
   this registry should include an implementation status with corresponding
   pertinent registries.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 15:43:18 -0400

>    this registry should include an implementation status with corresponding

Thanks.  This does suggest an ambiguity, but probably not the one you
read (which does mean there's a problem).  What we envisioned was a
reference on the registry itself (and not on the entries) pointing to
this document.  The individual entries should doubtless still have
entries to the documents that specify the algorithm.  (This change to
the way it was stated since the previous draft was an attempt to deal
with a comment from the IESG.)

What about "Because this document establishes the implementation
status of every algorithm, it should be listed as a reference for the
registry itself (leaving in place the individual entries for the
algorithms referring to the documents that specify them)." ?

Note that the last part of your "ADD" is explicitly disallowed.  Any
future entry is either Optional (in which case no new entry is
needed), or else this entire document needs to be made obsolete and
replaced.  

Best,

A (as shepherd -- I failed to mention that last time.  Sorry.)

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Mar 2013 16:01:04 -0400

> algorithms referring to the documents that specify them)." ?

That seems like it would have eliminated my confusion. Perhaps also explicitly state that this document aims to classify existing and all future algorithms that might be standardised, until replaced. This could be done by adding to the table earlier in the document make it clear explicitly that "Optional" includes all future algorithms.

    +------------+------------+-------------------+-------------------+
    |    Must    |  Must Not  |    Recommended    |      Optional     |
    |  Implement | Implement  |   to Implement    |                   |
    +------------+------------+-------------------+-------------------+
    |            |            |                   |                   |
    |   RSASHA1  |   RSAMD5   |   RSASHA256       |   Any             |
    |            |            |   RSASHA1-NSEC3   |   registered      |
    |            |            |    -SHA1          |   algorithm       |
    |            |            |   RSASHA512       |   not listed in   |
    |            |            |   ECDSAP256SHA256 |   this table      |
    |            |            |   ECDSAP384SHA384 |                   |
    +------------+------------+-------------------+-------------------+

REMOVE:

  Any registered algorithm not listed in this table

ADD:

  Any registered algorithm not listed in this table, including any algorithm registered in the future.

One further comment, the document justifies as "recommended" ECDSA on the grounds that they might be popular in the future because they feature small key sizes.

   Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and
   ECDSAP384SHA384) are algorithms that may see widespread use due to
   the perceived similar level of security offered with smaller key size
   compared to the key sizes of algorithms such as RSA.  Therefore,
   ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement.

ECC-GOST are not recommended, although I believe they have the same advantages. Arguably ECC-GOST has been around for longer, and hence has an advantage over ECDSA. Both have stable references, in English, in the RFC series. What is the reason for appearing to promote one over the other?

> needed), or else this entire document needs to be made obsolete and

That's clear, now, and seems like a reasonable approach.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 16:12:01 -0400

On Mon, Mar 11, 2013 at 04:01:04PM -0400, Joe Abley wrote:
> 
> That seems like it would have eliminated my confusion. Perhaps also
> explicitly state that this document aims to classify existing and
> all future algorithms that might be standardised, until replaced. 

This paragraph in 2.4 doesn't do:

   [RFC6014] establishes a parallel procedure for adding a registry
   entry for a new algorithm other than a standards track document.
   Because any algorithm not listed in the foregoing table is Optional,
   algorithms entered into the registry using the [RFC6014] procedure
   are automatically Optional.

?
 
> ECC-GOST are not recommended, although I believe they have the same
> advantages. Arguably ECC-GOST has been around for longer, and hence
> has an advantage over ECDSA. Both have stable references, in
> English, in the RFC series. What is the reason for appearing to
> promote one over the other?

I don't know; that's what the WG said before.  This is the first time
this question came up.  I think that would be a substantive change to
the intent of the document, and would require a new WGLC, but I think
yours is a fair question.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 11 Mar 2013 16:13:17 -0400 (EDT)

The substance is fine, but there's a preexisting ambiguity that the 
-04 changes arguably make worse:

Quoting from section 2.2:
"...RSASHA1-NSEC3-SHA1 is set to Recommended..."
"...RSA/SHA-256 and RSA/SHA-512 are also set to Recommended..."
"ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement."...
"All other algorithms used in DNSSEC specified without an
implementation status are currently set to Optional."

The last sentence is the troubling one.  I think you mean "where no 
other document has set an implementation status", but that's somewhat 
vague, and it would be reasonable to interpret the doc as saying "and 
everything else is Optional", which is not what we intend.

There's a sentence in the introduction that argues for the second 
interpretation: "This document defines the current implementation 
status for _all_ registered algorithms." (emphasis added)

This version (-04) has a new sentence in section 4 saying: "...this 
document establishes the implementation status of every algorithm, 
...", which makes that alternate reading even more tempting.

I think something needs to change.  Most likely, we just need to 
restate in the text (not just the table) the status of RSASHA1 and 
RSAMD5.

Also, shouldn't the indirect, private, and privateoid text replace "up 
to the implementer's discretion" with "Optional"?  It's good to call 
out that these numbers could refer to multiple algoriths, as is done.

-- Sam

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Mar 2013 16:34:15 -0400

Hi Sam,

On Mon, Mar 11, 2013 at 04:13:17PM -0400, Samuel Weiler wrote:
> other document has set an implementation status", but that's
> somewhat vague, and it would be reasonable to interpret the doc as
> saying "and everything else is Optional", which is not what we
> intend.

It absolutely is too what we intend.  The very point of this document
is that there be exactly one current official list of the status
values of every algorithm.  Every algorithm not explicitly called out
in that table has the status value Optional.  That was exactly what I
understood previous consensus calls on this document to be saying, and
if people think that's not what we said then we have a problem.

> restate in the text (not just the table) the status of RSASHA1 and

Why not just in the table?

> Also, shouldn't the indirect, private, and privateoid text replace
> "up to the implementer's discretion" with "Optional"?  It's good to
> call out that these numbers could refer to multiple algoriths, as is
> done.

I don't think I can tell the difference between Optional and "up to
the implementer's discretion".  Also, since the document explicitly
says that anything not listed elsewhere in the table is therefore
Optional, the indirect, private, and privateoid algorithms just are
Optional.  No?

I should note that the WG pretty much ran out of steam on this
document quite some time ago, and there is every reason to suppose
that the document will never get published if we start making
substantive changes right now, so I urge participants to be careful
about the changes they ask for.  This is not an attempt to tell people
not to raise substantive issues, but it is a plea to consider whether
this or that part needs to be polished to a higher gloss, or whether
the document is comprehensible as it stands and clearly expresses the
meaning of the WG.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 09:27:06 -0400

Dear colleagues,

> I don't know; that's what the WG said before. 

The reasoning in the draft behind recommending ECDSAP256SHA256 and
ECDSAP384SHA384 and not GOST-ECC is that the former two "may see
widespread use".  Does anyone have an argument that ECC-GOST also
falls into that category?  If so, Joe is quite correct.  If not, then
it seems the current recommendations are ok.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 09:38:30 -0400

Sam,

Thanks for your conversation in the hall.  More below.

> restate in the text (not just the table) the status of RSASHA1 and

It appears that we now agree that the table covers everything, and
that the text in section 2.2 is just rationale for some algorithms'
state.  If I understand your concern, you'd prefer to see the table in
section 2.2 to be expressed instead as running text.

Note that, if we do this, we pass through the IESG changeover, so this
document will need to be processed by a new IESG (with the additional
snags that might imply).  

Given that the definitions in previous drafts were _also_ in the
table, I'm a little concerned that this is now being offered as a
substantive reason to override prior consensus.  Would it be
sufficient to extend the sentence in section 1 to make clearer that
the table is the official line here?  That is

OLD, sec 1 para 3:

   This document defines the current implementation status for all
   registered algorithms.

NEW, sec 1 para 3:

   This document defines the current implementation status for all
   registered algorithms; the definitions are found in the table in
   Section 2.3.

Will that do?  

Best,

A (as shepherd)

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Mar 2013 09:47:58 -0400

On 2013-03-12, at 09:27, Andrew Sullivan <[email-masked]> wrote:

> widespread use".

To give the quote more context, the draft says that the former two "may see widespread use due to the perceived similar level of security offered with smaller key size compared to the key sizes of algorithms such as RSA." The prediction of widespread use is based on a presumed advantage that smaller key sizes are good.

There's no citation for the cryptographic strength (perceived or otherwise) of ECDSAP256SHA256 or ECDSAP384SHA384 relative to the other "recommended" algorithms, i.e. RSASHA256, RSASHA1-NSEC3-SHA1 or RSASHA512.

RFC 6605 has this to say:

   Current estimates are that ECDSA with curve P-256 has an approximate
   equivalent strength to RSA with 3072-bit keys.  Using ECDSA with
   curve P-256 in DNSSEC has some advantages and disadvantages relative
   to using RSA with SHA-256 and with 3072-bit keys.  ECDSA keys are
   much shorter than RSA keys; at this size, the difference is 256
   versus 3072 bits.  Similarly, ECDSA signatures are much shorter than
   RSA signatures.  This is relevant because DNSSEC stores and transmits
   both keys and signatures.

which adds more detail, but also omits citations (beyond "current estimates"). I didn't look very hard, but I couldn't find a comparison between GOST R.34.10-2001 and RSA/SHA256.

In both ECDSA and GOST-ECC a public key Q = (x, y) is represented in DNSSEC as the concatenation x | y. 

In GOST R.34.10-2001 and ECDSA/P-256, the wire encoding is specified as 32 bytes for each of x and y, giving an encoded public key size of 512 bytes.

In ECDSA/P-384, the wire encoding is specified as 48 bytes for each of x and y, giving an encoded public key size of 768 bits.

Based purely on the motivation to reduce the key size (given that no citations are given for either ECDSA or GOST-ECC with respect to cryptographic strength relative to other algorithms) it seems that GOST-ECC has the same advantages as ECDSA/P-256 and is better than ECDSA/P-384.

> Does anyone have an argument that ECC-GOST also
> falls into that category?

Arguments about possible future widespread use are difficult to justify. Counter-examples (alg A is more likely to see use than alg B because A is encumbered, or is computationally expensive, or something) seem slightly easier to come up with. But since ECDSA and GOST-ECC are fundamentally so similar, it seems odd to me to treat them differently.

The only practical difference between ECDSA and GOST-ECC is where they were developed and standardised, and (once again) I think it'd be unfortunate if there was the perception that the GOST-specified algorithm was being under-promoted purely for geopolitical reasons.

Joe

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 12 Mar 2013 10:16:46 -0400 (EDT)

On Tue, 12 Mar 2013, Andrew Sullivan wrote:

> state.  If I understand your concern, you'd prefer to see the table 
> in section 2.2 to be expressed instead as running text.

Not quite.  I think the table in 2.3 is complete.  HOWEVER, the text 
in 2.2 sounds like it intends to be complete, and it differs from the 
table.

> Will that do?

That is clunky.

My suggestion:  add two sentences to 2.2 explaining the additional 
non-Optional entires in the table in 2.3: RSASHA1 and RSAMD5.

"RSASHA1 has an implementation status of Must Implement, consistent 
with [RFC4034].  RSAMD5 has an implementation status of Must Not 
Implement because of known weaknesses in MD5."

Or something like that.

-- Sam

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 10:20:44 -0400

> The only practical difference between ECDSA and GOST-ECC is where they were developed and standardised, and (once again) I think it'd be unfortunate if there was the perception that the GOST-specif…

I'm not sure that's the reason.  I actually have no idea what the
reason was, but the WG previously had already reached consensus on
this issue, so I'm trying to figure out whether the problem is merely
the description of why the ECDSA algorithms might find more pick-up,
or whether the document has a fundamental mistake in it.

I also cannot help but observe that this issue has cropped up now
after multiple WGLC events on this basic issue, and nobody ever
mentioned it before.  The only reason the document is back before the
WG is to ensure that the changes in response to the AD's DISCUSS have
not changed the substance of the document.  

This is not to discourage late observations, but to ask about the
quality of review that we did in the past, and also to ask whether, if
we reopen this, whether we'll get adequate review in the next round of
discussion.  There is no question that moving ECC-GOST from Optional
to some other status is a substantive change to the document, and
would need another WGLC and, IMO, IETF LC.  I would not be even
remotely surprised if that LC failed for want of responses.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 10:55:39 -0400

> Implement because of known weaknesses in MD5."

These are good.  Thanks!  I see no reason this can't be added.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 12 Mar 2013 14:58:58 +0000

> These are good.  Thanks!  I see no reason this can't be added.

I can make this change with an RFC Editor note.

- Ralph

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Mar 2013 12:38:22 -0400

> remotely surprised if that LC failed for want of responses.

I seem to think that there's ample evidence that people think this document is worth publishing. I think that's established, regardless of the amount of feedback received for any future last call (low volumes or absence of response could be attribute to LG-fatigue.)

With respect to this change, if nobody has sufficient interest to comment perhaps the answer is that it's not actually substantive.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Mar 2013 14:26:22 -0400

On Tue, Mar 12, 2013 at 12:38:22PM -0400, Joe Abley wrote:
> 
> I seem to think that there's ample evidence that people think this
> document is worth publishing. I think that's established, regardless
> of the amount of feedback received for any future last call (low
> volumes or absence of response could be attribute to LG-fatigue.)

Ok.  For that reason, then, I'm going to ask Ralph to go ahead, with
the two notes we determined are going to be needed.  If there is a
later need to move ECC-GOST to Recommended to Implement, it ought to
be a fairly trivial matter to produce a new document for this, and
send it through an area or up the AD Sponsored track.

Thanks very much for your comments & review!

A 

-- 
Andrew Sullivan
[email-masked]

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 12 Mar 2013 18:51:43 +0000

On Mar 12, 2013, at 2:26 PM 3/12/13, Andrew Sullivan <[email-masked]> wrote:

> the two notes we determined are going to be needed.

Please send the exact text for the two notes.

>  If there is a

Thanks to all for your participation in the discussion and prompt responses so we can get this document resolved before I step down.

- Ralph