Subject: DNS Encryption

From: Duane <[email-masked]>
Date: Sat, 12 Jul 2008 10:42:08 +1000

I've been trying to get feed back on DNS encryption for months now and
nearly all the comments have related to spelling or grammar, some one
suggested writing an Internet Draft on it and I'd be more likely to get
feed back so I've done just that. Well attempted to anyway, I've never
written or submitted anything before so this is all new to me, but I'd
very much appreciate any and all feed back on the technical merits of my
proposal as I don't know if this is the best way to do it or not and no
one else seems to be able to suggest otherwise.

http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt

-- 

Best regards,
 Duane

--
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: Florian Weimer <[email-masked]>
Date: Sat, 12 Jul 2008 14:01:42 +0200

> http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt

The document lacks a clear threat model and problem statement.  As a
result, is not possible to check whether the proposed protocol actually
solves anything.

Sections 2 and 3 do not really describe the on-the-wire protocol.

CERT Glue records (section 4) won't work without changing all recursors
(and probably authoritative servers, too).  This means that this
proposal has near zero chance of deployment.

As far as I can see, the proposed protocol, if worked out in full,
solves two problems (data leaks across the hierarchy and eavesdropping
on the wire) but doesn't do anything about enumeration and information
leaks from caching resolvers.

---

From: Duane <[email-masked]>
Date: Sat, 12 Jul 2008 22:37:26 +1000

> result, is not possible to check whether the proposed protocol actually

I had several things listed but they were removed by suggestion of Paul
Vixie as he felt the conversation would be distracted by that rather
than the draft or similar proposal.

> Sections 2 and 3 do not really describe the on-the-wire protocol.

What was lacking?

> proposal has near zero chance of deployment.

With all the changes needed to facilitate DNSsec, and people still
pushing ahead trying to get it deployed I fail to see why this would be
a sticking point.

I've had a rethink on this due to hitting 512 byte boundaries today with
mutliple host keys causing issues for cache servers that don't speak
EDNS and listing the fingerprint seems to be a better idea, especially
since OpenPGP keys can be cached, there will be a small delay the first
time a key needs to be found but after that the local keyring could be used.

> leaks from caching resolvers.

There is no way this would prevent enumeration any more than SMTP-TLS
prevents spam, brute force attacks can be dealt with on the server by
tracking IPs and/or sequential requests, but this wouldn't prevent a
very clever attacker that has a large bot net that does a distributed
brute force attack in a non-sequential manner.

As for information leaking from caching resolvers, that depends on the
programmers of the software in question and how well they implement
things to prevent such leaks occurring, and/or local caching
implementing something similar for end to end encryption by passing
caches in the middle altogether, it really depends on how secure you
need to be for your application. Not everything needs to be 100% secure
all the time, although that would be nice.

Thanks for your feed back.

-- 

Best regards,
 Duane

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 14 Jul 2008 15:01:07 +0200

Duane wrote:
| I've been trying to get feed back on DNS encryption for months now and
| nearly all the comments have related to spelling or grammar, some one
| suggested writing an Internet Draft on it and I'd be more likely to get
| feed back so I've done just that. Well attempted to anyway, I've never
| written or submitted anything before so this is all new to me, but I'd
| very much appreciate any and all feed back on the technical merits of my
| proposal as I don't know if this is the best way to do it or not and no
| one else seems to be able to suggest otherwise.
|
| http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt
|

A valiant effort. I read vs -01 by the way.

Section 7 was unclear how this key is represented on the wire, it starts
out with 4 bytes then talks about 16 bytes of padding.

You also need to say how an encrypted reply is distinguished from an
error, or even noerror reply from a legacy server. I suggest using the
same header as before, but QR=1. And from the 4th byte on the encrypted
DNS reply message.

Attached CERTs in delegations need to be optional for more
deployability. If you have the OpenPGP key anyway, you can use it, even
if not passed on in the delegation. State the section (authority,
additional) for the CERT records.

I think that the TLD labels in queries recommendation, if used lower
down the tree, could see interoperability problems with current
unencrypted software. Tailoring this trick to TLDs only is bad, and gets
you into the 'list of registries for browsers' discussion.  I think you
should do the proposed label trick all the way down the DNS tree, since
you need a software upgrade to do the encryption anyways.

Having given some constructive comments, I think the technology is
interesting, but there does not seem to be interest at this time. Thus,
for a workgroup adoption the hard question is if its worth the effort
vs. anyone implementing and deploying it.

The problem I have is the low certainty of getting trustworthy
encryption. Unless you get full deployment of certificates in
delegations from parents. But is exactly what keeps DNSSEC.

The ERROR opcode for a no-encryption-supported error should be picked
out of the EDNS error space. Note that due to the zeroed ID fields, this
error is extremely easy to spoof. Fix this by filling the outer ID field
for queries and replies.

Have you given thought to the size that the openpgp keyring could
attain? This could hamper scalability, and some sort of purging of
records may be needed.

Best regards,
~   Wouter

---

From: John Dickinson <[email-masked]>
Date: Mon, 14 Jul 2008 17:32:08 +0100

> http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt

Hi,

You say "NAPTR records (RFC 2915, RFC 2916), a subset of DNS services,  
is the first of possibly many such DNS services which reveal sensitive  
information about the querying agent when requests are sent,  
regardless of any replies returned." - can you give some examples.

A few of your references need updating

RFC2440 Obsoleted by RFC4880
RFC2915 Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404
RFC2916 Obsoleted by RFC3761
RFC3280 Obsoleted by RFC5280

John
---
John Dickinson

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jul 2008 13:10:42 -0400

At 14:01 +0200 7/12/08, Florian Weimer wrote:
Probably quoting something else...
>>  http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-00.txt

This is the first message I've seen on this thread in namedroppers. 
Either I am missing mail or this is a thread jumping from somewhere 
else.  No matter, except that the URL does not go to a document.

Just reacting because a deacde of DNSSEC makes me flinch whenever I 
think of anyone attempting to, once again, tie crypto to DNS.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Duane <[email-masked]>
Date: Tue, 15 Jul 2008 12:16:49 +1000

John Dickinson wrote:

> information about the querying agent when requests are sent, regardless
> of any replies returned." - can you give some examples.

At the advice of Paul Vixie I was trying to avoid commenting on this,
however All NAPTR requests sent contain the full phone number you are
attempting to call. There has been news reports in the US of telcos
collecting the same type of information in the past.

> A few of your references need updating

Ok, will update those now, although I intentionally mentioned those for
historical reasons, not just technical.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 15 Jul 2008 12:17:24 +1000

> think of anyone attempting to, once again, tie crypto to DNS.

I'm not trying to use DNSSEC info for crypto, although with all the ENUM
stuff neustar is doing I would have thought you would have welcomed
encryption, or are you using VPNs to accomplish this?

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 15 Jul 2008 12:16:58 +1000

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 15 Jul 2008 12:23:08 +1000

> A valiant effort. I read vs -01 by the way.

I must apologise for -01 it was a little rushed, I was trying to update
it in a hurry before bed to add PKA like records into the additional
section instead of the CERT records, this prevents going over 512 bytes
in most cases that I've tested so far with 3 host names.

> out with 4 bytes then talks about 16 bytes of padding.

Sorry about that, I think I have it much more clear about the key size
and so on.

> same header as before, but QR=1. And from the 4th byte on the encrypted

I incorporated this suggestion into the next revision.

> additional) for the CERT records.

Yes that was a mistake, using key fingerprints only is sufficient.

> you need a software upgrade to do the encryption anyways.

If you do that you risk making unnecessary DNS lookups, which could be
quite a lot in the case of NAPTR records, the ITU standard for e.164
allows up to 15 digits including the country code, and if you include
the infrastructure stuff that's an extra segment, eg;

1.2.3.4.5.6.7.8.9.0.1.2.3.i.4.5.e164.arpa

So there is a trade off between efficiency and confidentiality, although
this could be optional, but I'm not entirely sure that would be wise.

> vs. anyone implementing and deploying it.

Before sending out the draft I made sure it was technically feasible by
making code to prove it could be done, I also plan to submit some
patches to others such as www.freepbx.org in the future once the details
are refined to the point that things are unlikely to change any further.

> delegations from parents. But is exactly what keeps DNSSEC.

OpenPGP is already widely used in some circles so this is one reason why
I went down this path, and there is a number of things that can easily
be leveraged such as www.cacert.org and www.gswot.org rather than trying
to build completely new infrastructure.

> error is extremely easy to spoof. Fix this by filling the outer ID field

I didn't consider the error aspect being spoofed, thanks for pointing
that out to me, I'll fix up the next revision of the draft accordingly,
yes, only the encrypted DNS packet opcode needs to be in the 3rd byte,
the rest can be in the EDNS error space, I'll add some details to
clarify that in the new revision.

> attain? This could hamper scalability, and some sort of purging of

The method of storing OpenPGP keys in DNS strips all information from
the key before adding it, the rest of the meta information needs to come
from PGP key servers, although now that I think about it I should
probably add some notes about this.

I'm hoping to have a new revision published in the next few hours
incorporating all the wonderful suggestions and feed back, I appreciate
all the comments.

-- 

Best regards,
 Duane

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Jul 2008 13:23:31 +1000

> historical reasons, not just technical.

	Just start looking up random phone numbers at random time
	intervals.  Use the numbering plans so that you can't
	distingish between the random numbers and the real numbers.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Jul 2008 23:38:11 -0400

> probably add some notes about this.

OpenPGP keys stored in CERT records can be a bare packet (just a  
public key with no metadata), a revocation signature (just enough  
information to kill an active key) or a "transferable public key",  
which is specified in 2440 (and 4880) as the full public key,  
including user IDs, self-signatures, etc.  So you have a choice  
whether you want to store the whole thing or not.

There isn't an explanation or citation for the PKA TXT record format  
in the document.  I also wonder what PKA gives you that the IPGP  
variation of CERT (which is standardized) doesn't give you?

David

---

From: Duane <[email-masked]>
Date: Tue, 15 Jul 2008 13:51:36 +1000

David Shaw wrote:

> There isn't an explanation or citation for the PKA TXT record format in
> the document.  I also wonder what PKA gives you that the IPGP variation
> of CERT (which is standardized) doesn't give you?

Again my apologise for that, I was in a rush and I should have updated
it properly before submitting a new revision, I've done that just now
and it hopefully explains everything in detail.

http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-02.txt
http://www.ietf.org/internet-drafts/draft-groth-dns-encryption-02.pdf

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 15 Jul 2008 13:53:55 +1000

> 	distingish between the random numbers and the real numbers.

White noise is ok, but we are creatures of habit, and any entity capable
of being in a position to monitor such things should be able to pull out
repetitive numbers. There may also be consequences with false positives
as well.

-- 

Best regards,
 Duane

---

From: Florian Weimer <[email-masked]>
Date: Fri, 18 Jul 2008 15:03:31 +0200

> brute force attack in a non-sequential manner.

The reason why I'm raising this is that you're tweaking a core protocol,
and I think there should be a sound rationale for that.

My impression (correct me if I'm wrong) is something like this: You want
to use DNS for non-carrier ENUM.  You note that ENUM requests and
responses may contain data assumed to be sensitive in the PSTN context.
You want to do something about it, and this is the motivation behind
your draft.

In contrast, I strongly believe that your goal is unattainable in a DNS
context because DNS is inherently leaky.

---

From: Duane <[email-masked]>
Date: Fri, 18 Jul 2008 23:07:28 +1000

> You want to do something about it, and this is the motivation behind

That's only one leak, someone else brought up another, but I won't
repeat it publicly, there is any number of reasons why people want to
hide their queries and/or responses, as others pointed out to me, I'm
not the first to attempt this.

> context because DNS is inherently leaky.

So is HTTP which is why they plug up the XSS exploits in browsers, where
as the site owners are really to blame. I don't think secrecy is
impossible at least to some degree, I think if there was a common stable
starting point for everyone that any holes that sprang leaks could be
worked on a solved over time.

-- 

Best regards,
 Duane