[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: draft-ietf-dnsext-ecc-key-05.txt
From:       dee3 () pothole ! com
Date:       2004-11-09 22:53:44
Message-ID: Pine.LNX.4.60.0411091748500.21653 () localhost ! localdomain
[Download RAW message or body]

On Thu, 4 Nov 2004, Samuel Weiler wrote:

> Date: Thu, 4 Nov 2004 15:49:50 -0500 (EST)
> From: Samuel Weiler <weiler@tislabs.com>
> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt
> 
> On Tue, 12 Oct 2004 dee3@pothole.com 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.

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.

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

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

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

As I say, it is intended to be 4.

> 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

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

> 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

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

As above.

On Thu, 4 Nov 2004, Samuel Weiler wrote:

> Date: Thu, 4 Nov 2004 22:44:53 -0500 (EST)
> From: Samuel Weiler <weiler@tislabs.com>
> Subject: Re: draft-ietf-dnsext-ecc-key-05.txt
> 
> 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.

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.

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

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.

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

This is a reasonable topic for discussion.

> -- Sam

Thanks,
Donald
======================================================================
  Donald E. Eastlake 3rd                       dee3@torque.pothole.com
  155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
  Milford, MA 01757 USA                   Donald.Eastlake@motorola.com

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
[prev in list] [next in list] [prev in thread] [next in thread]