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

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 2 Apr 2006 22:37:35 -0400

Hi Mike,

See below at @@@

-----Original Message-----
From: Mike StJohns [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 11:53 AM
To: Eastlake III Donald-LDE008; [email-masked]
Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review

At 12:42 AM 3/27/2006, Eastlake III Donald-LDE008 wrote:
>Hi Mike,
>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"?

@@@ Of course RFC 4034 and this draft provide all of the information you
need to form a valid DNSKEY. RFC 4034 says clearly "where this key blob
explicitly fits within the DNSKEY RR". This information is in section
2.1.4 on page 5 of RFC 4034. It is the same place all key blobs for all
algorithms usable with DNSKEY fit into DNSKEY. This information is a
characteristic of the RR, not of the algorithm. And RFC 4034 says
exactly what algorithm ID to use. This information is in section A.1 on
page 24. The exact linkage is not particularly due to the string
"DSA/SHA-1 [DSA]" but rather due to the exact pointer to RFC 2536 which
this draft obsoletes. If you don't like the fact that, assuming this
draft was published as RFC RRRR, the text is RFC 4034 wouldn't be
magically updated so that DNSKEY Algorithm ID 3 referenced RFC RRRR,
it's just the way RFCs are, being immutable ASCII documents rather than
having some sort of dynamically updated links in them. Whenever you see
in one RFC a reference to a second RFC, it is always the case that the
second RFC may have been updated or obsoleted and to be sure you always
have to check the RFC index or some similar up-to-date source of this
information. So no other "ID that maps this ID  into the DNSKEY RR" is
necessary.

@@@ I can understand if, in your judgment, it is better to be redundant
and in every crypto algorithm key/signature DNS encoding RFC, as it
comes out, to include within it a snapshot of pointers to all of the
latest DNS RR defining RFCs that can use that algorithm encoding along
with how, for that RR RFC, to identify the algorithm. This redundancy
might be convenient some of the time. But with the gradually growing set
of algorithm and RR RFCs, they are not going to be all updated at the
same time. So in the long run, more redundancy results in more out of
date RFC numbers.

@@@ If I were adding such redundancy to this draft, I would probably do
it via an Appendix which would say something like the text below. (I
still can't really see any reason to list the RR field the crypt goop
goes in. Anyone seriously trying to use algorithm X with RR Y just has
to read the latest algorithm X RFC and the latest RR Y RFC and every RR
RFC of this sort that I'm aware of makes it perfectly clear what field
the crypt goop goes in for all algorithms.)

   Appendix

   The encodings for DSA keys and signatures specified in this document
   are usable in a number of different resource records. The table below
   provides information on such usage at the time of publication of this
   RFC. Note that, since that time, any of the RFCs referenced below may
   have been updated or obsoleted and the RFC Index should be checked
   for this. Also, additional resource records may have been defined
that
   make use of the DSA encodings specified above:

         Use of DSA Keys
         ---------------
   RR        RFC    Algorithm ID  Note
   --        ---    ------------  ----
   KEY       3755   3             Used to support TKEY [RFC 2930].
   IPSECKEY  4025   1
   DNSKEY    4034   3

       Use of DSA Signatures
       ---------------------
   RR        RFC		Algorithm ID  Note
   --        ---        ------------  ----
   SIG       3755		3             Used in SIG(0) [RFC 2931].
   RRSIG     4034       3

@@@ Would such an appendix with redundant information make you happy?

@@@ Actually, there is an argument for having a third regular document
type in this area besides algorithm RFCs and RR RFCs, which is somewhat
like the 'linkage' document you are talking about. The idea would be
that the basic characteristics and format of an RR, like DNSKEY, changes
rarely in comparison with changes in the list of algorithms usable with
that RR and their implementation requirement (MANDATORY, OPTIONAL,
etc.). So, for each type of key/signature encoding usable in the DNS you
should have an algorithm RFC. For each RR (or set of related RRs like
DNSKEY and RRSIG) that can include such encoding, you would have an
largish RFC that described how that RR or those RRs worked and gives
information for them that was algorithm invariant, such as where the
encoding was inserted in the RR and how algorithms are identified for
that RR (i.e., the location and size of an "algorithm id" field). Then
this new third type of short document, which might be called an "RR
algorithms" document, would, for that RR (or set of related RRs) list
the algorithms that can be used with a snapshot of pointers to their
most recent algorithm RFCs and give the algorithm IDs and any particular
limitations, such as on RSA prime size. (We already have the case where
that limit is different for DNSKEY and IPSECKEY so it was probably not
such a good idea to associate the limit with the algorithm. The limit
should be associated with the 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 are correct when you say that the "format id" need to reference
a specific document. However you seem to imply that the format ids for
RSA related keys/signatures don't reference specific document when they
obviously do. Thus far, the idea has been that it is desirable to have
one standard encoding in the DNS for a particular kind of public key. If
you  wanted to provide a second encoding for RSA based on the Chinese
Remainder Theorem or whatever, you would need another algorithm ID and
mnemonic to specify that encoding and they would need to refer to an RFC
specifying the format.

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.

@@@ Of course this document does that. (By the way, you have a typo, its
2536, not 2546.) This document obsoletes 2536 and so should be used in
conjunction with 4034. The linkage is provided by the "obsoletes"
information in the RFC Index.

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:

@@@ Here I agree with you completely. For most public key systems, there
are many more signature algorithms, differing in hash function, padding,
or whatever, than there are key formats.

@@@ But while we should remove the linkage between key and signature
algorithm numbers, I think we should also, in most cases, add a
signature format sub-type. (The usual anti-sub-typing arguments don't
really apply since you are already sub-typing your RR with the algorithm
ID or whatever.) Otherwise, you have the situation where a relatively
small set of values might, in the long run, be getting used up an order
of magnitude faster for signature formats than an equal sized population
is being used up for key formats.

@@@ Thanks,
@@@ Donald

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.

--
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, 03 Apr 2006 06:25:06 -0400

>See below at @@@

Rather than continue this, here's what I think the document needs to 
be.  I've trimmed the boilerplate at both ends - but I have a xml2rfc 
file which generates the full document.  I don't believe there's a 
need to obsolete the old document - and doing so would actually void 
the KEY and SIG mappings.

Network Working Group                                         M. StJohns
Internet-Draft                                             Nominum, Inc.
Updates: 2536 (if approved)                                April 3, 2006
Expires: October 5, 2006

       Use of the Digital Signature Algorithm with DNSKEY and RRSIG
                     draft-ietf-dnsext-dsa-update-00

Abstract

    This document updates [RFC2536] by providing a mapping of Digital
    Signature Algorithm (DSA) [FIPS1862] keys and signatures for the
    DNSKEY and RRSIG DNS resources records respectively.

StJohns                  Expires October 5, 2006                [Page 1]

Internet-Draft                 dsa-update                     April 2006

Table of Contents

    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.  RFC2536 Updates . . . . . . . . . . . . . . . . . . . . . . . . 3
    3.  DSA Mapping for DNSKEY  . . . . . . . . . . . . . . . . . . . . 3
    4.  DSA/SHA1 Mapping for RRSIG  . . . . . . . . . . . . . . . . . . 3
    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
      7.2.  Informative References  . . . . . . . . . . . . . . . . . . 4
    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
    Intellectual Property and Copyright Statements  . . . . . . . . . . 6

StJohns                  Expires October 5, 2006                [Page 2]

Internet-Draft                 dsa-update                     April 2006

1.  Introduction

    The DNSKEY and RRSIG records were defined in [RFC4034] as part of the
    most recent revisions to the DNS Security protocols.  DNSKEY replaced
    the KEY record in functionality and RRSIG replaced the SIG record.
    This document provides mappings for the DSA for use with the new
    records.

2.  RFC2536 Updates

    [FIPS1862] has replaced "FIPS 186".  None of the changes to FIPS 186
    affect processing described by [RFC2536] or, by derivation, this
    document.

3.  DSA Mapping for DNSKEY

    A DSA public key may be placed in the Public Key field of the DNSKEY
    record.  The format of such a DSA key is identical to the format
    defined in [RFC2536] section 2.  All constraints on DSA keys as
    defined in that document apply to DSA keys in DNSKEY records.  The
    algorithm ID (e.g. the DNSKEY Algorithm field) for a DSA public key
    in a DNSKEY record is 3.

4.  DSA/SHA1 Mapping for RRSIG

    A DSA/SHA1 signature may be placed in the Signature field of an RRSIG
    record.  The format of such a signature is identical to the format of
    a DSA/SHA1 signature as defined in [RFC2536] section 3.  The
    determination of the data to be signed and the formation of the
    signature is accomplished using the process defined in that section
    and according to [FIPS1862].  The algorithm ID (i.e. the RRSIG
    Algorithm field) for a DSA/SHA1 signature in an RRSIG record is 3.

    Use of DSA with other hashing algorithms for RRSIG is currently not
    defined.  The algorithm ID 3 may only be used with DSA/SHA1
    signatures.

5.  Security Considerations

    The security considerations described in [RFC2536] continue to apply.
    Note that [RFC4086] has updated the randomness requirements.  This
    document has no other or additional security concerns.

StJohns                  Expires October 5, 2006                [Page 3]

Internet-Draft                 dsa-update                     April 2006

6.  IANA Considerations

    The IANA considerations described in [RFC2536] continue to apply.
    This document creates no additional IANA actions.

7.  References

7.1.  Normative References

    [FIPS1862]
               National Institute of Standards and Technology, "U.S.
               Federal Information Processing Standard: Digital Signature
               Standard", January 2000.

    [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
               (DNS)", RFC 2536, March 1999.

    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Resource Records for the DNS Security Extensions",
               RFC 4034, March 2005.

7.2.  Informative References

    [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
               Requirements for Security", BCP 106, RFC 4086, June 2005.