[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dnsext] RRTYPE request: template for proposed RKEY RRtype

See below why I have reservations about the technical quality of this proposal document. 


------------------------------------------------------------------------

#
#    $Id: rkey-template.txt,v 1.3 2008/11/06 09:41:48 jim Exp $
#
        DNS RRTYPE PARAMETER ALLOCATION TEMPLATE


   A.   Submission Date:

    6/11/08

   B.   Submission Type:
        [x] New RRTYPE
        [ ] Modification to existing RRTYPE

   C.   Contact Information for submitter:
               Name: Jim Reid
               Email Address: jim@telnic.org
               International telephone number: +44 20 7467 6474
               Other contact handles: none
        (Note: This information will be publicly posted)


   D.   Motivation for the new RRTYPE application?

       Storage of keying material in the DNS is currently limited to
       keys used for Secure DNS and transaction authentication. This
       is somewhat limiting. It is possible to store encrypted data
       in the DNS: for instance in the RDATA of TXT records and some
       other RRtypes. A scheme for encrypting NAPTR records is
       outlined in draft-timms-encrypt-naptr-01. Defining an RRtype
       which can be used to publish the keys relating to this
       encrypted DNS data would provide an obvious method for
       clients to retrieve those keys so that the encrypted data can
       be decoded.
If clients retrieve keys to *decode* encrypted data from the public DNS, then what prevents unauthorized parties from doing the same? 



   E.   Description of the proposed RR type.

       The format and structure of the proposed RRtype is almost
       identical to a KEY record. The only differences are the
       values of the record's flags and protocol fields. In the
       proposed RRtype, the flags field is set to zero and its
       protocol field set to 1. Further details about the record
       format and its potential applications is given in
       draft-reid-dnsext-rkey-00.txt.

   F.   What existing RRTYPE or RRTYPEs come closest to filling that
        need and why are they unsatisfactory?

    The KEY and DNSKEY records are identical in format and
    structure to the proposed RRtype. Their semantics are
    different however. These RRtypes cannot be used for
    publishing arbitrary application keys that could be used to
    encrypt DNS resource records. DNSKEY is restricted to
    signatures needed for Secure DNS, DNSSEC. The scope of the
    KEY record was limited by RFC3445 to eliminate sub-typing and
    prevent the RRtype being utilised for arbitrary application
    keys. A new RRtype is therefore needed to permit application
    keys specifically for encryption of DNS resource records to
    be stored and published in the DNS.

   G.   What mnemonic is requested for the new RRTYPE (optional)?
        Note: this can be left blank and the mnemonic decided after the
        template is accepted.

    RKEY

   H.   Does the requested RRTYPE make use of any existing IANA
        Registry or require the creation of a new IANA Sub-registry and
        in DNS Parameters?

    Yes. The proposed RRtype uses the IANA sub-registry of
    security algorithm numbers established by RFC2535 and updated
    by RFC4034. The proposed RRtype does not require any
    modifications to that sub-registry.
Public key encryption algorithms, if that's what this proposal is all about, are different from signature algorithms. Hence, the deployment of the proposal would require some additions to the IANA registry. 


   I.   Does the proposal require/expect any changes in DNS
        servers/resolvers that prevent the new type from being
        processed as an unknown RRTYPE (see [RFC3597])?

    No.

   J.   Comments:

       None.

_______________________________________________
dns-rrtype-applications mailing list
dns-rrtype-applications@ietf.org
https://www.ietf.org/mailman/listinfo/dns-rrtype-applications
Given the state of this proposal at its face value, I didn't check the referenced draft. Please provide a revised proposal that makes sense with respect to basic public key cryptography principles, if there is anything that makes sense. 

Should I apologize for harsh critiques?

Regards,


--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.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/>