Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 27 Mar 2006 00:42:42 -0500

Hi Mike,

See below at @@@ 
________________________________

From: Mike StJohns [mailto:[email-masked]] 
Sent: Saturday, March 25, 2006 8:55 PM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

At 08:29 PM 3/25/2006, Eastlake III Donald-LDE008 wrote:

	Hi Mike,
	
	I'd like to know exactly what you mean. What assumptions do you
have to
	make?
	
	Let's just talk about DNSKEY to be specific. Seems to me that
RFC 4034
	does a reasonable job of defining the wire encoding of DNSKEY
except for
	the interior of the part of the RDATA which it calls "Public
Key" in
	Section 2.1 of RFC 4034. Do you think the problem is that draft
2536bis
	is ambiguous in defining the wire encoding of DSA keys? I can
see how it
	could be improved to be a little clearer in that regard. Or is
that you
	alternatively or additionally think that, even in the face of a
	hypothetical perfect description in 2536bis of the octet wire
encoding
	sequence for a DSA key in the DNS, that RFC 4034 isn't clear
enough
	about where to stuff the data? Or what?

How does "

the structure of the
   relevant part of the RDATA part of the RR being used is the
fields
   listed below in the order given." map to "put this
in the PublicKey field of the DNSKEY RR"?  E.g. why (without
going back and reading 2536) should I assume that "relevant part of
the RDATA part" maps to the PublicKey field?

@@@ Those words clearly don't map as you state, but so what?

@@@ There are currently two kinds of documents relevant to storing
keys/signatures in DNS RRs: what might be called "algorithm RFCs" and
what might be called "RR RFCs". This draft is for an algorithm RFC. If
you are only interested in the standard DNS format for DSA keys and
signature without reference to any particular RR, this is the document
for you. I make the assumption, which seems reasonable to me, that if
you care about some particular RR, you would also read the relevant RR
RFC. That RR RFC would normally be the place you would find out how, for
that RR, to indicate which algorithm is in use and where to put the DNS
encoding of the key/signature inside that RR.

@@@ Someone worried about using DSA keys with DNSKEY should be familiar
with RFC 4034, which is the most recent documentation for DNSKEY. RFC
4034 is the RR RFC which tells you how to indicate that you are using
the DSA algorithm in a DNSKEY RR and where in the DNSKEY RR to put the
DNS encoded DSA key. Similarly, someone worried about using DSA keys
with IPSECKEY should be familiar with RFC 4025 which is the most recent
documentation for the IPSECKEY RR. RFC 4025 is the RR RFC which tells
you how to indicate that you are using the DSA algorithm in an IPSECKEY
RR and where in the IPSECKEY RR to put the DNS encoded DSA key. Etc.

@@@ It seems clear to me that this division between algorithm RFCs and
RR RFCs should be described in both the 2536bis and 2539bis drafts, so
I'd be happy to add text doing. And I'm not completely doctrinaire about
this. It actually wouldn't hurt that much to redundantly put some stuff
in this draft about how to indicate the DSA algorithm and where to
insert the DNS encoding of the DSA key or signature in the RDATA for
DNSKEY, or other existing RRs that can use DSA. The main disadvantage
would be that, should this information change in the future, you would
have to remember to indicate that the hypothetical future change RFC
should be listed as changing both all applicable algorithm RFCs as well
as changing its RR RFC.

@@@ I think that, slowly over the years, DNS encoding for additional
algorithms will be specified and additional application specific RRs,
like IPSECKEY, will be specified. The situation your really, really want
to avoid would be any *requirement* that algorithm RFCs include such RR
algorithm indication information (e.g., "algorithm numbers") and RDATA
placement information. The reason is that, if there was such a
requirement, then the next time someone specifies a new application
specific RR, they would have to spin new versions of every applicable
algorithm RFC just to put this information in them.

@@@ Sorry to be so long winded but, to summarize, people interested in
using algorithm X with RR Y can reasonably be expected to read the
algorithm RFC on algorithm X and the RR RFC on RR Y. Certainly, they
need to know how, in RR Y, to indicate the use of algorithm X, and where
in the RDATA of RR Y to put the encoded key/signature for algorithm X.
As long as they can find that information in either the algorithm RFC or
the RR RFC, things should be fine. But, given a choice, the RR RFC is a
better place for this information for two reasons: this way the
algorithm RFCs doesn't get gooped up with different information about a
slowly growing number of different RRs and, more important, every time a
new application specific RR is defined, you don't have to spin new
versions of all applicable algorithms RFCs.

Also, "which algorithm ID do you use for this in the DNSKEY?  2536
explicitly said it was ID 3 - but that's for 'DSA/SHA1' and that's
obviously a signature algorithm not a key representation so WTF?"  E.g.
if the DNSKEY is now used for DSA/SHA256 does the algorithm ID change?
Can I use the same DNSKEY for both DSA/SHA1 and DSA/SHA256?  (Ditto for
RSA....)

@@@ If you want to know algorithm ID to use for DSA in DNSKEY, you
should look at the RR RFC for DNSKEY, RFC 4034. Just as if you want to
know the algorithm ID for DSA in IPSECKEY, which is different, you
should look at the RR RFC for IPSECKEY, RFC 4025. 

@@@ At the time RFC 2536 was published, it was thought that there would
probably only ever be one RR that would contain DSA keys so there was no
harm in giving information like algorithm numbers redundantly in both
the RR RFC and the algorithm RFC. At the time RFC 4034 were published,
DSA always used SHA-1 for its signatures and the string "DSA/SHA1" was
just a redundant way of writing "DSA". By the way, the string "DSA/SHA1"
you are complaining about appears, as far as I can see, no where in this
draft or RFC 2536.

@@@ As to the recently approved extensions of DSA for longer hashes,
etc., those are not covered by the draft under review and whether they
should be the same algorithm or not has not, as far as I can tell, been
decided yet by the working group. I have no idea what you mean by "Can I
use the same DNSKEY for both DSA/SHA1 and DSA/SHA256?". You can only
include one key and only specify one algorithm id in any particular
instance of the DNSKEY RR. And what does RSA have to do with this draft?

A document which obsoletes another document should be able to be read on
its own and have a complete meaning. This one can't be. This document
needs to specify:

@@@ I don't really understand what "read on its own and have a complete
meaning" connotes to you but I certainly think this draft completely
specified the DNS encoding of FIS 186-2 style DSA keys and signatures
into precise octet sequences. And that's all it needs to do.

@@@ Perhaps you meant to say that a document which obsoletes another
document has to cover exactly the same information as the document it
obsoletes. But I don't agree with that either. That would imply that the
IETF could never, when revising a set of RFCs, change the boundaries as
to what information is in which RFC or RFCs. It probably shouldn't do so
without a reason but in this case there is a reason. As explained above,
it is cleaner if the normal place for RR specific algorithm identifiers
and RR specific algorithm data placement is with that RR RFC rather than
having such data for all relevant RRs in all relevant algorithm RFCs.

1) The algorithm ids specific to this representation both for DNSKEY and
for RRSIG.

@@@ While it wouldn't hurt that much to include that data in this draft,
there is absolutely no need to do so and some minor negative effects
form doing so, as explained at length above.

2) The actual and specific placement of the fields described here within
the DNSKEY and RRSIG. 

@@@ While it wouldn't hurt that much to include that data in this draft,
there is absolutely no need to do so and some minor negative effects
form doing so, as explained at length above.

Enjoy.  Mike

@@@ Donald

	2536bis specifies the order of the subfields within the "Public
Key"
	data for a DSA key and explicitly says the octets within a
subfield are
	stored in 'stored in "big-endian" network order'...
	
	Thanks,
	Donald
	
	-----Original Message-----
	From: Mike StJohns [ mailto:[email-masked]
<mailto:[email-masked]> ] 
	Sent: Saturday, March 25, 2006 8:01 PM
	To: Eastlake III Donald-LDE008; [email-masked]
	Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review
	
	At 06:46 PM 3/25/2006, Eastlake III Donald-LDE008 wrote:
	>@@@ RFC 4034 describes all of the bits in the DNSKEY and RRSIG
RRs (if 
	>that's what you mean by "connective tissue") but not the
algorithm 
	>dependent data format. At this point, the DNS DSA key format is
usable 
	>in DNSKEY, KEY (to support TKEY), and IPSECKEY (to support
IPSEC). The 
	>DNS DSA signature format is usable in RRSIG and SIG (to support
	SIG(0)).
	>Things like the "algorithm number" are different in DNSKEY and
	IPSECKEY.
	>I believe it is contemplated that there might be additional
application
	
	>specific key RRs, like IPSECKEY, defined in the future.

	The problem is that you'd actually have to specify the actual
way you
	fit this into DNSKEY and RRSIG to be useable.  This document is
not
	sufficient to do that without making some possibly ambiguous
	assumptions.  Which means you'd need yet another document to
fulfill
	that requirement.  And that makes this document somewhat useless
and
	pointless.
	
	Mike

--
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: Mike StJohns <[email-masked]>
Date: Mon, 27 Mar 2006 11:53:06 -0500

>See below at @@@

Trimmed all of the text - readers can see previous emails in this 
thread if they want more detail.

Don -

If I asked you a question of "how do I form a valid DNSKEY record 
containing a DSA key" I believe you would claim that this ID taken 
with 4034 provides sufficient detail to do so.  I disagree.  What I 
get from 4034 is the general format of a DNSKEY RR.  What I get from 
this ID is the ordering of bits within a key blob of some form.  What 
I am missing is what format identifier (e.g. Algorithm identifier) 
applies to this ID and where this key blob explicitly fits within the 
DNSKEY RR.  If you're saying this isn't the job of this ID, then my 
question is "where is the ID that maps this ID into the DNSKEY RR"?

I refer to the Algorithm Identifier field as a format id because 
that's really what it is.  It describes the format of the PublicKey 
field and needs to reference a specific document to do so rather than 
the more generic algorithm name.  To understand what I mean, let's 
consider the RSA algorithm.  The RSA public key has two common 
representations - the Public/Exponent representation and the Chinese 
Remainder Theorem representation.    Neither of the two RSA related 
Algorithm IDs in appendix a.1 of 4034 provide such representation.  I 
would need to define a third (or more) RFC with this format and the 
assigned algorithm ID would refer specifically to that RFC.

You're proposing obsoleting 2546 and 4034 points at 2546 as being the 
specific document which defines the format for Algorithm ID 3.  You 
need a replacement document which links that algorithm ID (3) to a 
specific format.  Its just a simple as that. This ID does not do that.

Also, the more I think about it, the less I like the current system 
of assigning a single number for both the public key representation 
and an associated signature representation.  We're about to re-do RSA 
with SHA1 into RSA with SHA256 and possibly other SHAs.  I would 
expect similar actions for DSA.  I suggest we split the algorithm 
assignments for key and signature as follows:

Algorithm IDs for Key representations:

0 - Reserved
1 - RSA (modulus/exponent form)
2 - DH
3 - DSA (Fips 182-6)
4 - ECC - not yet defined
5 - RSA (modulus/exponent form - same as 1)

Algorithm IDs for Signature representations
1 - RSA/MD5 - not recommended
2 - none (was DH)
3 - DSA with SHA1
4 - Reserved
5 - RSA/SHA1
6-127 reserved
127-255 - new signature algorithms.