Subject: Re: draft-ietf-dnsext-ecc-key-05.txt

From: Samuel Weiler <[email-masked]>
Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST)

On Tue, 12 Oct 2004 [email-masked] wrote:

> Please post any comments on these two drafts. I gave brief presentations
> on them at the last IETF and plan to do so again next month. If there are
> no substantial comments, I will ask that they be working group Last Called
> right after the upcoming meeting.

I've only read parts of draft-ietf-dnsext-ecc-key-05.  Here are some
comments on the bits I have read:

This document needs to take into account the type code roll (RFC3755).
Examples: Section 1 refers to SIG, which has been largely, but not
entirely, deprecated.  Section 2 says "key RRs", then cites
DNSSECbis-records.  See RFC3755 IANA considerations, section 4.2.  Be
much more explicit about which of DNSKEY and/or KEY you mean here.

Section 2, second paragraph: "with signatures..." is confusing.  Just
say RRSIGs.  Also: "key validity may not be in the RR with the
key...".  First, just say KEY or DNSKEY.  Also: I see no key validity
field in this RR -- why have the equivolcal phrasing with a "may"?

IANA section:

Should comment on whether any algorithm numbers need to be assigned
(and, if not, where they are assigned).  See 3755 section 4.2.

It looks like a new registry is being established.  This text is
likely insufficient for that task.  See
draft-narten-iana-considerations-rfc2434bis-01.txt

Nits:

Section 5 (Performance Considerations), second paragraph, third line:
s/ and and/, and/

Status of this memo: "This draft is intended to be become a Proposed
Standard RFC." is not allowed, per
http://www.ietf.org/ietf/1id-guidelines.txt

Boilerplate looks incomplete (Acceptance of section 3 of 3667 is
missing).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST)

On Thu, 4 Nov 2004, Samuel Weiler wrote:

> Be much more explicit about which of DNSKEY and/or KEY ...

Further comments after some more reflection.

First, I'd like to thank Donald for his efforts to put this document
(and the HMAC SHA TSIG doc) together.  There are very few people with
both the ability to follow the current crypto research and the
willingness to bring that knowledge back to the IETF in a useful form.
We should applaud Donald for his willingness to do that.

I'd also like to say that I'm not particularly averse to storing
random data in the DNS.

That said, it's not clear to me why we're trying to store ECC keys in
the DNS nor, given that uncertainty, what RR type we might want to use
to store them.  Of late, we've been choosing to separate data into new
type codes based on the use of the data, not the content or format of
the data.  For cryptographic keys, in particular, we've tried to reuse
key storage formats (we reused the 2536 and 3110 formats in DNSKEY and
IPSECKEY), but we've allocated new RR types for different data users.
See RFC3445 (restrict-key), RFC3755, and draft-ietf-ipseckey-rr-11.txt
section 2.6 (now at RFC-Editor).

Since we're not defining a SIG nor RRSIG format for ECC, it would
appear that ECC keys aren't currently useful for DNSSEC (DNSKEY/RRSIG)
nor SIG(0) (KEY/SIG), as we've (re-)defined those RRs in RFC3445 and
RFC3755.  Who are they useful for?  (Does anyone really want to store
ECC keys in the DNS?)  And what does that suggest about what RR
type(s) they should be stored in?  This all feeds into the IANA
section questions I posted earlier today.

Looking further ahead, I also wonder if this record format's
flexibility might be dangerous.  Can we imagine users of data that
can't effectively use all of the different types of eliptic curve keys
that can be stored in this RR?  If so, we may be creating another
subtyping problem.

-- Sam

---

From: [email-masked]
Date: Fri, 5 Nov 2004 09:31:54 -0500 (EST)

Sam,

Thanks for all your comments.  I'll review them more closely and respond 
at greater length but here are a couple of intial comments:

I believe that the format of DNS keys should be defined independently of 
RR codes. As long as it works technically, I don't see why you would want 
to prohibit using a particular key format in a particular RR type.

The original versions of this draft did include a signature format. Years 
ago, the DNSEXT chair made the removal of this a condition for accepting 
the draft as a WG draft. Although some have always had feelings against 
ECC due to the patent thicket that has surrounded much of it, I have 
always thought that the compact nature of ECC keys and signatures, at 
least in comparison with RSA, was a good fit for UDP DNS and there should 
be defined formats for interoperability for those who want to use it.

Thanks,
Donald
======================================================================
  Donald E. Eastlake 3rd                       [email-masked]
  155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
  Milford, MA 01757 USA                   [email-masked]

On Thu, 4 Nov 2004, Samuel Weiler wrote:

> Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST)
> From: Samuel Weiler <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Nov 2004 16:31:06 +0100

Samuel Weiler <[email-masked]> writes:

> ECC keys in the DNS?)

If I remember correctly, RFC 2538 uses the same IANA name space as the
rest of DNSSEC for the key algorithms.  Perhaps someone is using ECC
for X.509 or OpenPGP data.  So a specification for ECC, and an entry
in the IANA DNSKEY key algorithm registry, seem useful.

I believe it would be a too radical change to alter this now, if we
want RFC 2538bis to move forward as a DRAFT STANDARD.  Even if that
isn't a consideration, I'm not convinced there is a strong motivation
for changing this now.

Thanks,
Simon

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 5 Nov 2004 14:35:10 -0500 (EST)

> in the IANA DNSKEY key algorithm registry, seem useful.

I'm surprised that no one caught this when we were bickering over the
RFC3755 IANA registry format.  I don't have any problems with CERT
reusing the registry, but as you're working on 2538bis, you might want
to check the IANA considerations section in 3755 and the registry
itself to see if any changes are needed.  2538bis might want to cite
3755, too.  In any case, I think it would be good to add a note in the
registry mentioning that CERT uses these numbers, also:

http://www.iana.org/assignments/dns-sec-alg-numbers

-- Sam

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 05 Nov 2004 23:59:52 +0100

Samuel Weiler <[email-masked]> writes:

> itself to see if any changes are needed.

It seems one new column, to specify applicability for CERT records
would have to be added.  I can add this as a IANA consideration of
2538bis.

One could argue that this new IANA consideration in RFC 2538bis would
make it incompatible with RFC 2538, thus preventing it from
progressing to DRAFT STANDARD.

On the other hand, the incompatibility is due to the changes
introduced by RFC 3755, not the original specification nor the
original DNSSEC specification.

I would appreciate input on this issue, from people more familiar with
procedural issues.

> 2538bis might want to cite 3755, too.

Won't DNSSECbis obsolete 3755?  I'd rather reference DNSSECbis.

> In any case, I think it would be good to add a note in the registry
> mentioning that CERT uses these numbers, also:
>

I agree.  How can we make that happen?

Thanks,
Simon

---

From: [email-masked]
Date: Tue, 9 Nov 2004 17:53:44 -0500 (EST)

On Thu, 4 Nov 2004, Samuel Weiler wrote:

> Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST)

You are right. My only excuse, not very good, is that this draft has been 
around for many years in one form or another. It is meant to define 
algorithm code point 4 which has always been reserved for ECC.

As originally posted, it also defined a signature format usable in RRSIG 
and SIG.  There was lots of resistence due to fears of inability to handle 
a zone signed with more than one algorithm, and the like. So, quite some 
time ago, the draft was admitted as a WG draft only on condition that the 
signature date format be stripped out of it. I think that's silly and the 
signature format section should be reinserted.

> field in this RR -- why have the equivolcal phrasing with a "may"?

I'd be happy to work on modernizing the wording.

> (and, if not, where they are assigned).  See 3755 section 4.2.

As I say, it is intended to be 4.

> draft-narten-iana-considerations-rfc2434bis-01.txt

Another case where I can bring the document up to the more recent 
standards.

> http://www.ietf.org/ietf/1id-guidelines.txt

I would agree that it would be better to remove this and the guidelines 
specifically prohibit certainly words, that imply status, from being in 
the title of an ID.  But I don't actually see where the guidelines 
prohibit this sentence. Could you point it out to me?

> Boilerplate looks incomplete (Acceptance of section 3 of 3667 is

As above.

> I'd also like to say that I'm not particularly averse to storing

It certainly isn't particularly intended to be random data. It's original 
intent wass to provide ECC as another interoperable way to sign zones and 
store ECC keys for use by other protocols.

> section questions I posted earlier today.

I removed the signature format, which was present in earlier versions, 
because that was made a condition by the chairs for consideration by the 
WG.  I think it should be added back. The ECC / Algorithm 4 should, in my 
opinion, be allowed as widely as RSA, although of course it should only be 
a MAY for implementation.

The compactness of ECC keys and signatures is particularly attractive for 
DNS and a code point was reserved for ECC from the beginning.

> that can be stored in this RR?  If so, we may be creating another

This is a reasonable topic for discussion.

Thanks,
Donald

---

From: [email-masked]
Date: Tue, 9 Nov 2004 18:06:49 -0500 (EST)

On Fri, 5 Nov 2004, Simon Josefsson wrote:

> Date: Fri, 05 Nov 2004 23:59:52 +0100
> From: Simon Josefsson <[email-masked]>

It's almost the same. RFC 2538 specifically allows zero for unknown cases.

>> itself to see if any changes are needed.

I think it is a lot easier to have one registry.

> progressing to DRAFT STANDARD.

This sort of thing is one reason why algorithms and their implementation 
requirements are increasingly being split out into separate documents. 
That way, if a protocol is reasonably algorithm independent, it can 
continue to advance along the standards track even if advances in 
cryptography requires the corresponding "crypto suites" document to keep 
changing.

> Won't DNSSECbis obsolete 3755?  I'd rather reference DNSSECbis.

Yes, it does obsolete 3755.

Thanks,
Donald