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

From: Samuel Weiler <[email-masked]>
Date: Wed, 3 Dec 2008 02:08:06 -0500 (EST)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

First, I think this template is adequate for the purpose of an RFC5395 
assignment.

That said, the idea as presented seems very flawed.

Without addressing the merits of providing confidentiality for DNS 
data: why use public key cryptography here at all?  It seems that 
symmetric cryptography with shared keys more closely matches the need. 
Thierry makes a good point in that the DNSSEC algorithms are for 
signatures.  It happens that some can also be used for encryption, but 
that's not generally the case, and reusing the registry is of dubious 
value.

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

The draft isn't clear that the primary point of publishing the keys is 
to allow identification of which non-published keys should be used to 
decrypt the content -- that could be clarified.  As it is, I see much 
confusion arising.

And, if the primary point is just to allow identification of keys, it 
seems like there are several other ways to do this are more generally 
effective, that that result in less confusion, and perhaps that result 
less data in the DNS.

In general, key fingerprints seem more appropriate.  In the case of 
RSA, it's not necessary to publish any exponents to allow key 
identification -- the modulus (or a digest of it) is sufficient. 
That key indentification could also be embedded in the RDATA of the 
encrypted record, rather than floating around in some other RR.

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

Without more documentation, it's hard to see how choosing this format 
enables rollover.  Rollover is sometimes a very tricky thing.

All that said, the template conditions are satisfied -- the record is 
well-formed and should be allocated.  But I see enough opportunities 
for improvement in the substance that I hope you withdraw the request 
until the idea is fleshed out a bit further.

-- Sam

--
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: Thu, 4 Dec 2008 03:50:44 +0000

On Dec 3, 2008, at 07:08, Samuel Weiler wrote:

> First, I think this template is adequate for the purpose of an  
> RFC5395 assignment.

Thanks.

> symmetric cryptography with shared keys more closely matches the need.

It doesn't. Further discussion about whether symmetric or asymmetric  
keys are more fit for purpose here is irrelevant. RKEY is about a  
minimalist way to use public key crypto to encrypt DNS data,  
specifically NAPTR records. If you believe there's a need for an even  
more general-purpose all-singing all-dancing key RRtype, feel free to  
write up your own template and/or I-D.

> signatures.  It happens that some can also be used for encryption,  
> but that's not generally the case, and reusing the registry is of  
> dubious value.

Well this was done on the assumption that it was the path of least  
resistance. No doubt if the template proposed to have yet another IANA  
registry for subtyping the proposed RRtype, the WG would be pushing  
back saying that both the suggestion of an extra registry (and the  
stuff for maintaining that) and for introducing yet another form of  
subtyping were not welcome. Piggybacking on an existing protocol  
registry was hopefully more palatable to the WG than that approach.

> The draft isn't clear that the primary point of publishing the keys  
> is to allow identification of which non-published keys should be  
> used to decrypt the content -- that could be clarified.

That clarification was provided in the response to Thierry's earlier  
identical comment that was posted on Nov 26th.

> encrypted record, rather than floating around in some other RR.

Nope. Please read http://www.ietf.org/internet-drafts/draft-timms-encrypt-naptr-01.txt 
. Section 7 explains why it's impractical to use a NAPTR's RDATA for  
this.

> Without more documentation, it's hard to see how choosing this  
> format enables rollover.

It's just a key. Rollover is irrelevant. When a new key is needed, the  
old one is retired and the data gets encrypted with the new one. If  
this isn't done, the decryption fails. Which is the sole  
responsibility of whoever publishes that key and the encrypted NAPTRs  
associated with that key.

---

From: Chris Thompson <[email-masked]>
Date: 04 Dec 2008 12:00:11 +0000

>On Dec 3, 2008, at 07:08, Samuel Weiler wrote:
[... other points snipped ...]
>associated with that key.

Unless you are proposing that RKEY records always have a TTL of zero,
you have to deal with the fact that some clients will have old versions 
of them in their caches. Some sort of overlap mechanism is needed.

-- 
Chris Thompson
Email: [email-masked]

---

From: "Ondřej Surý" <[email-masked]>
Date: Thu, 4 Dec 2008 13:23:13 +0100

>>  old one is retired and the data gets encrypted with the new one. If  this
>> isn't done, the decryption fails. Which is the sole  responsibility of
>> whoever publishes that key and the encrypted NAPTRs  associated with that
>> key.
>

Or owner can publish two RKEYs and start encrypting with second key
after all caches are clear.  (similar to pre-publish method of rotating
DNSKEYs).  Or am I missing something?

Ondrej.
-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Jim Reid <[email-masked]>
Date: Thu, 4 Dec 2008 12:55:50 +0000

On Dec 4, 2008, at 12:00, Chris Thompson wrote:

> Unless you are proposing that RKEY records always have a TTL of zero

I'm not. And even if I was, how is that different from any other  
RRtype that gets advertised with a 0 second TTL?

---

From: Jim Reid <[email-masked]>
Date: Thu, 4 Dec 2008 13:19:18 +0000

> DNSKEYs).  Or am I missing something?

Yes. Implementation details that are not germane to what should be  
getting discussed here: namely the template and type code assignment.

I have already stated key rollover is not necessary. An RKEY is bound  
to a bunch of encrypted NAPTRs. Both get generated and managed as a  
single entity. [This is from an implementation perspective, not from a  
DNS protocol perspective.] If they are not co-ordinated in that way,  
bad things will happen to whoever broke that linkage. Their problem.  
Not this WG's. From a DNS protocol point of view this is no different  
from having an MX record point at a non-existent hostname.

---

From: "Ondřej Surý" <[email-masked]>
Date: Thu, 4 Dec 2008 14:51:21 +0100

MjAwOC8xMi80IEppbSBSZWlkIDxqaW1AcmZjMTAzNS5jb20+Ogo+IE9uIERlYyA0LCAyMDA4LCBhdCAxMjoyMywgT25kxZllaiBTdXLDvSB3cm90ZToKPgo+PiBPciBvd25lciBjYW4gcHVibGlzaCB0d28gUktFWXMgYW5kIHN0YXJ0IGVuY3J5cHRpbmcgd2l0aCBzZWNvbmQga2V5Cj4+IGFmdGVyIGFsbCBjYWNoZXMgYXJlIGNsZWFyLiAgKHNpbWlsYXIgdG8gcHJlLXB1Ymxpc2ggbWV0aG9kIG9mIHJvdGF0aW5nCj4+IEROU0tFWXMpLiAgT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8KPgo+IFllcy4gSW1wbGVtZW50YXRpb24gZGV0YWlscyB0aGF0IGFyZSBub3QgZ2VybWFuZSB0byB3aGF0IHNob3VsZCBiZSBnZXR0aW5nCj4gZGlzY3Vzc2VkIGhlcmU6IG5hbWVseSB0aGUgdGVtcGxhdGUgYW5kIHR5cGUgY29kZSBhc3NpZ25tZW50LgoKSSBhZ3JlZSBoZXJlLgoKPiBJIGhhdmUgYWxyZWFkeSBzdGF0ZWQga2V5IHJvbGxvdmVyIGlzIG5vdCBuZWNlc3NhcnkuIEFuIFJLRVkgaXMgYm91bmQgdG8gYQo+IGJ1bmNoIG9mIGVuY3J5cHRlZCBOQVBUUnMuIEJvdGggZ2V0IGdlbmVyYXRlZCBhbmQgbWFuYWdlZCBhcyBhIHNpbmdsZQo+IGVudGl0eS4gW1RoaXMgaXMgZnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgbm90IGZyb20gYSBETlMgcHJvdG9jb2wKPiBwZXJzcGVjdGl2ZS5dIElmIHRoZXkgYXJlIG5vdCBjby1vcmRpbmF0ZWQgaW4gdGhhdCB3YXksIGJhZCB0aGluZ3Mgd2lsbAo+IGhhcHBlbiB0byB3aG9ldmVyIGJyb2tlIHRoYXQgbGlua2FnZS4gVGhlaXIgcHJvYmxlbS4gTm90IHRoaXMgV0cncy4gRnJvbSBhCj4gRE5TIHByb3RvY29sIHBvaW50IG9mIHZpZXcgdGhpcyBpcyBubyBkaWZmZXJlbnQgZnJvbSBoYXZpbmcgYW4gTVggcmVjb3JkCj4gcG9pbnQgYXQgYSBub24tZXhpc3RlbnQgaG9zdG5hbWUuCgpJIGFsc28gYWdyZWUgaGVyZS4KCkFuZCBJIHN1cHBvcnQgdGhpcyBwcm9wb3NhbCBmb3IgUlIgVHlwZSBhc3NpZ25tZW50LgoKT25kcmVqCi0tIAogT25kcmVqIFN1cnkKIHRlY2huaWNreSByZWRpdGVsL0NoaWVmIFRlY2huaWNhbCBPZmZpY2VyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAgLS0gIC5jeiBkb21haW4gcmVnaXN0cnkKIEFtZXJpY2thIDIzLDEyMCAwMCBQcmFoYSAyLEN6ZWNoIFJlcHVibGljCiBtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6ICBodHRwOi8vbmljLmN6Lwogc2lwOm9uZHJlai5zdXJ5QG5pYy5jeiB0ZWw6KzQyMC4yMjI3NDUxMTAKIG1vYjorNDIwLjczOTAxMzY5OSAgICAgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Chris Thompson <[email-masked]>
Date: 04 Dec 2008 17:12:33 +0000

>DNSKEYs).  Or am I missing something?

No, this is probably quite adequate, together with a rubric that clients
need to try all RKEYs in the RRset, possibly weakly distinguished by 
footprint, etc. 

It's just that there is nothing about this in draft-reid-dnsext-rkey-00,
and I think there ought to be. But on further consideration, I agree
that there doesn't need to be anything about it in the template itself.

-- 
Chris Thompson
Email: [email-masked]