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

From: Andrew Sullivan <[email-masked]>
Date: Fri, 21 Nov 2008 13:07:14 -0600

Dear colleagues,

Attached is a completed template requesting RRTYPE assignment under
the procedures defined in draft-ietf-dnsext-2929bis.  This message
initiates a thee-week comment period on this request.  Note that this
is one of two different open requests; the comment periods run
concurrently.

As with the other open request, we will process this request by the
entire panel of experts.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
#
#	$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: [email-masked]
                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.

    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.

    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
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-rrtype-applications

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Nov 2008 20:51:16 +0100

Can I get in the F section a comparison with CERT RR (RFC 4398)?

Thanks

[email-masked]

--
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: Jim Reid <[email-masked]>
Date: Fri, 21 Nov 2008 20:28:50 +0000

> Can I get in the F section a comparison with CERT RR (RFC 4398)?

Why? The proposed RRtype defines a public key, not a certificate.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Nov 2008 21:48:55 +0100

=> a (public-key) certificate embeds a public key.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 24 Nov 2008 10:31:02 +0100

On Fri, Nov 21, 2008 at 08:28:50PM +0000,
 Jim Reid <[email-masked]> wrote 

> Why? The proposed RRtype defines a public key, not a certificate.

Then a comparison with RFC 5205?

---

From: Peter Koch <[email-masked]>
Date: Mon, 24 Nov 2008 22:31:28 +0100

Hi,

>    	is somewhat limiting. It is possible to store encrypted data

well, in conjunction with RFC3445 mentioned further below, this is rather
straightforward. We've learned about "subtyping" and it was clear that
any application in need of a key would have to define its own RR type,
likely based upon KEY.

>    	outlined in draft-timms-encrypt-naptr-01. Defining an RRtype

What worries me here is the actual application, that tries to introduce
confidentiality into the DNS.  The basic problem statement has been
regularily reappearing on namedroppers and might be worth pursuing,
but I'd consider taht a DNS architectural matter.  Doing this en passant
with an RR type definition appears a bit like introducing the death
sentence by standardizing the blades of the Guillotine.

>    	draft-reid-dnsext-rkey-00.txt.

The draft indicates it is seeking "Standards Track" publication.  If that
is intentional, why is an Expert Review necessary aat this stage?
Independent of this question, 2929bis does not require a stable
reference and a draft mentioned here might just expire.  I'm not sure
this is a good idea.

-Peter

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 25 Nov 2008 14:23:01 -0500

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

> ------------------------------------------------------------------------
> 
> #

If clients retrieve keys to *decode* encrypted data from the public DNS, 
then what prevents unauthorized parties from doing the same?

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

>         processed as an unknown RRTYPE (see [RFC3597])?

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: [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Wed, 26 Nov 2008 14:55:46 +0000

> If clients retrieve keys to *decode* encrypted data from the public  
> DNS, then what prevents unauthorized parties from doing the same?

Because only authorised clients will have the corresponding private  
key(s). Since there may be many keys in use an RKEY RRtype tells the  
client which (if any) of the private keys it holds can be used to do  
the decoding. It also allows for new keys to be introduced: either by  
rollover to a new one, or a change of algorithm or key size. It's  
pretty much the same principle as DNSKEY for DNSSEC signatures. Which  
is why the records are almost identical.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 26 Nov 2008 12:24:18 -0500

> is why the records are almost identical.

I acknowledge that you answered one of the two questions I raised. I 
abstain from participating any further in this discussion, because I 
don't want to delve into the security scheme and the corresponding key 
management principles.

Regards,

-- 

- Thierry Moreau

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