Subject: [keyassure] IANA Registry for DNSSEC Digest types?

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 13:55:03 -0400

RFC 4034 defines several IANA registries for DNSSEC. Including a registry
for "DNSSEC Digest Types"

A.2.  DNSSEC Digest Types

  A "Digest Type" field in the DS resource record types identifies the
  cryptographic digest algorithm used by the resource record.  The
  following table lists the currently defined digest algorithm types.

             VALUE   Algorithm                 STATUS
               0      Reserved                   -
               1      SHA-1                   MANDATORY
             2-255    Unassigned                 -

Key Assurance is going to need to have digest algorithm identifiers. I was
just writing up the IANA considerations section when I discovered that this
registry is not included in the Domain Name System Security (DNSSEC)
Algorithm Numbers registry as I expected.

This appears to me to be an oversight. It appears that this has happened
since DNSSEC does not actually make use of the digest independent of a
public key algorithm. I want to use SHA256 obviously.

So this leaves the following options:

1) Get the DNSSEC registry created and add in SHA256
2) Use ASN.1 OIDS instead.

I am thinking of a one pager which only has the following IANA instruction:

VALUE   Algorithm   Size       Reference
 0      Reserved                   -
 1      SHA-1       160        [RFC4034]
 2      SHA-2       256        [This]
 3      SHA-2       512        [This]
 4      Reserved for 256 bit SHA3 outcome
 5      Reserved for 512 bit SHA3 outcome
6-255    Unassigned                 -

[U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-3,
October 2008.]

The reserved values for SHA3 would take effect on the announcement of the
corresponding FIPS publication in the US Federal Register. Since this is an
international paper of record this is a reasonable approach in my view.

Incidentally those applying for the SHA-3 competition might note the
following requirement:

A.3 The algorithm must support 224, 256, 384, and 512-bit message
digests, and must support a maximum message length of at least 264 bits.

I think they meant 2^64, it makes a difference.

-- 
Website: http://hallambaker.com/

---

From: Rickard Bellgrim <[email-masked]>
Date: Thu, 9 Sep 2010 20:05:27 +0200

RFC4509 adds support for SHA256.

// Rickard

9 sep 2010 kl. 19:55 skrev "Phillip Hallam-Baker" <[email-masked]<mailto:[email-masked]>>:

RFC 4034 defines several IANA registries for DNSSEC. Including a registry for "DNSSEC Digest Types"

A.2.  DNSSEC Digest Types

             VALUE   Algorithm                 STATUS
               0      Reserved                   -
               1      SHA-1                   MANDATORY
             2-255    Unassigned                 -

Key Assurance is going to need to have digest algorithm identifiers. I was just writing up the IANA considerations section when I discovered that this registry is not included in the Domain Name System Security (DNSSEC) Algorithm Numbers registry as I expected.

This appears to me to be an oversight. It appears that this has happened since DNSSEC does not actually make use of the digest independent of a public key algorithm. I want to use SHA256 obviously.

[U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-3, October 2008.]

The reserved values for SHA3 would take effect on the announcement of the corresponding FIPS publication in the US Federal Register. Since this is an international paper of record this is a reasonable approach in my view.

Incidentally those applying for the SHA-3 competition might note the following requirement:

--
Website: <http://hallambaker.com/> http://hallambaker.com/

_______________________________________________
keyassure mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/keyassure

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 14:12:19 -0400

Ah found it.

The registry name does not have DNS in it.

On Thu, Sep 9, 2010 at 2:05 PM, Rickard Bellgrim <[email-masked]>wrote:

> 9 sep 2010 kl. 19:55 skrev "Phillip Hallam-Baker" <[email-masked]>:
>
> Website: <http://hallambaker.com/>http://hallambaker.com/
>
>
> [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2010 19:26:55 +0100

On Thu, 9 Sep 2010, Phillip Hallam-Baker wrote:
>
> DNSSEC does not actually make use of the digest independent of a
> public key algorithm.

Yes it does, in DS records. The 4th octet of DS RDATA is the digest type,
which is independent of the DNSKEY algorithm in the 3rd octet.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 09 Sep 2010 15:39:47 -0400

> registry for "DNSSEC Digest Types"

This registry is for the DS record.
http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

As you can see SHA-256 and GOST have been added.
I'm not sure that we want to reuse this registry as
the admission criteria for digest algorithms is likely to be different,
DS has high admission standard i.e. standards action.

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 16:11:04 -0400

On Thu, Sep 09, 2010 at 01:55:03PM -0400, Phillip Hallam-Baker wrote:
> Key Assurance is going to need to have digest algorithm identifiers. 

Why?  These are digests of DNSKEY records.  That is, it's what's in
the DS record at the parent.  I don't think I understand what you have
in mind.

(I confess that I'm finding it incredibly hard to follow all this
working out of details on the list.  Why can't we have some I-Ds that
make a clear proposal?)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Sep 2010 17:08:40 -0400

I am working on an ID at the moment which is what is giving rise to the
questions.

We definitely need to specify digest algorithms. The reason that I do not
like creating a second registry is that this creates the possibility that
the two would get out of sync.

The specification of the CERT record already constrains us to the use of a
single byte for the algorithm unless we want to prepend it to the data
field. While a standards action might not be considered ideal for this, I
don't see any particular problem with it either since anyone who really
cares about the algorithm for use with DPKIX is going to care just as much
about their DNSSEC algorithms.

If we really wanted to escape from the fixed code length trap that DNSSEC
falls into I would suggest a short draft that defines a new digest code
point for 255 in which the digest value consists of the ASN.1 OID for the
digest algorithm followed by the digest value itself.  Defining such a value
would effectively close the need to maintain that registry for future
algorithms.

3.  Mechanism

3.1.  CERT Resource Record Parameters

   Two new CERT certificate types are defined:

      DPKIX

      DPTR

   The CERT resource record (RR) has the structure given below.  Its RR
   type code is 37.

Hallam-Baker             Expires March 13, 2011                 [Page 4]

Internet-Draft     DNS CERT Records for Key Assurance     September 2010

                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             type              |             key tag           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   algorithm   |                                               /
   +---------------+            certificate data                   /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

   The type field is the certificate type as defined below.

   The key tag field used for key selection as specified in RFC 4034
   [RFC4034] Section 5.1.1.

   The algorithm field is the algorithm code for the digest algorithm as
   specified in the IANA registry Delegation Signer (DS) Resource Record
   (RR) Type Digest Algorithms.

3.1.1.  DPKIX

   The DPKIX certificate type asserts a binding between the DNS domain
   in which it is published and the subject key specified in a PKIX
   certificate identified by means of a cryptographic digest function.

   The assertion made by means of the DPKIX certificate type is only as
   secure as the trust chain that authenticates it.  Trust chain
   processing rules are specified in Section XXX below.

   In particular the presence of a DPKIX record in a DNS domain that is
   not signed using DNSSEC or other security mechanism SHOULD NOT be
   considered to provide any additional assurance that would not be
   provided by the certificate on its own.

   In the case that a DPKIX record exists and contains a digest value
   that matches the digest value of the certificate and is signed by a
   verified signature, a relying party MAY infer an assertion on the
   part of the domain name holder that the specified key is bound to the
   specified certificate subject key.  No other properties of the
   certificate may be considered to have been assured excepting those
   that limit the use of the certificate which MUST be observed as with
   any other PKIX certificate.  Such properties include the notBefore
   and notAfter fields, the key Usage bits and all X.509v3 extensions
   for which the critical bit is set.

   The CERT record field values are defined as follows:

   Type  is set to the value (TBS IANA)

   Key tag  MUST be specified as 0

   Algorithm   contains the algorithm code for the digest algorithm

   Certificate data  contains the digest value of the certificate for
      which a binding between the subject key and the domain name is
      asserted