Subject: Re: [dane] Storing public keys in DNS… or LDAP

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 6 Aug 2013 14:51:23 -0400

Sounds like you are proposing this.

http://www.ietf.org/rfc/rfc4386.txt

For what it is worth, I agree that using the DNS to store per-user data is
not a good approach. The DNS administration model is that it makes
assertions about network names and not individual users. Previous attempts
to put end users in the DNS have uniformly met with failure.

But that does not mean that LDAP is a useful tool. LDAP has tons of
complexity and none of it does the slightest bit of good.

While writing my RFC tool I thought about writing a spec for an Internet
bibliography service that would convert labels [RFC4386] to XML documents
describing the reference.

Then after a fairly short amount of work I realized that I could do
everything I wanted using HTTP and some simple regular expression pattern
matching. And the regexp stuff was only necessary because I wanted to reuse
the existing libraries of references at xml.resource.org.

So if you want to do per client records my suggestion would be

1) Use HTTP as the query language transport.

2) Put some form of pointer to the service in the DNS.

3) Use DNSSEC to secure the binding

It might well be that (2) is a case where NAPTR would be a good solution.
Or it might not.

On Fri, Jul 26, 2013 at 10:19 AM, Rick van Rein (OpenFortress) <
[email-masked]> wrote:

> Hello Paul Wouters,
>
> I came across your work on storing public key credentials of users in the
> DNS:
> * draft-wouters-dane-openpgp-00
> * draft-wouters-dane-otrfp-00
> As I am currently trying to achieve similar, secure end-to-end exchanges
> of public key material for secure communication, this is very interesting.
>  Thanks for the work!
>
> When I read them, I found that you made a choice that we deliberately
> abandoned as unpractical, so I thought it good to share our thoughts.  The
> background of our work is http://networkeffectalliance.org/ with which we
> aim to get more end user and technical facilities incorporated into hosting
> packages.  Doing this, we are rather keen on privacy and security, as you
> are in your drafts.
>
> We decided against the sort of options in DNS that you are describing
> because we felt that the DNS is not meant for storing individual user
> credentials.  One reason for this opinion is that DNS is ultimately treated
> public data, and no DNS admin will accept responsibility for "leaking"
> information through DNS, whereas most users will not want that kind of
> treatment with their electronically addressable contact channels.  Another
> reason is that DNS management is usually considered too sensitive to update
> for end user changes; which is why it is often in the hands of another
> (class of) operator.
>
> We are embarking in another direction, and thought this might also be
> useful for you, also because it can be used without RFC work.  Instead of
>  using DNS for user data, we are looking at LDAP (with DANE to secure it).
>  It is a very suitable mechanism for retrieval of end-user descriptive
> information, ranging from postalAddress to pgpKey descriptions.  It also
> has a well-established notion of a Global Directory that is based on
> DNS-names derived from dc=,dc= trailers to distinguishedNames, and SRV
> record lookups of LDAP service under such domains.  Given an email address,
> the username part can then be sought with (uid=…) filtering, and PGP keys
> and such can be located under that node.  I am not aware of any XMPP
> profile for LDAP, but that is as straightforward to define as it has been
> for OpenPGP, SSH and even SRP.  It is probably easier to get such an LDAP
> attribute spec standardised as an RFC or even just a XEP than your proposed
> use of DNS.
>
> The searchable structured data in LDAP can have privacy issues when used
> as a public-facing service when published without restraint; we are
> resolving that with a filtering practice (for which we are developing
> software) that can filter out considered-private attributes (or objects)
> unless their attribute values are explicitly mentioned in a query.  So,
> searching for (uid=rick) under dc=openfortress,dc=nl would deliver my
> account record with email address and SIP phone number as well as being a
> parent for key material, but searching for (uid=*) would not deliver this
> if I configured LDAP to treat uid as too private to publish in that case.
>  Another reason not to publish LDAP is that it is often used for data about
> local infra; this can be solved by separating in-house and public directory
> services.
>
> If you want to know more about this work, you can visit this site with the
> work in progress: http://rickywiki.vanrein.org/doku.php?id=globaldir
>
> Specifically note how, for OpenPGP, there is a solution that already works
> with PGP tools -- they will perform that LDAP queries to per-domain LDAP
> service. I detailed it on the subpage
> http://rickywiki.vanrein.org/doku.php?id=globaldir-5-openpgp
>
>
> I hope this is helpful!
>
>
> Cheers,
>
> Rick van Rein
> OpenFortress
> +31.53.4782239
> [email-masked]   (SMTP, XMPP, SIP)
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: John Gilmore <[email-masked]>
Date: Tue, 06 Aug 2013 18:06:30 -0700

> complexity and none of it does the slightest bit of good.

The classic Internet protocol for providing per-user data is "finger",
RFC 742 from 1977.  (Note by the way the illustrious users in the
"examples" section.)  It has been updated a few times, most recently
in RFC 1288 from 1991.  It is a Draft Standard.  Many people put their
PGP public key in their .plan file for easy remote access via finger.

Finger has two drawbacks for this purpose: It is not authenticated nor
encrypted; and it is designed to be human-readable, not
machine-readable.  But a simple finger-like protocol, authenticated
and encrypted via keys anchored in DNSSEC, might not only fill the
need to obtain keys, but also offer a secured and machine-readable
replacement for the finger protocol.

> http://www.ietf.org/rfc/rfc4386.txt

Well, no.  That just specifies a DNS RR for finding a server that
includes X.509 stuff.  It doesn't define a protocol for getting the
stuff from that server, nor is it generic to information beyond X.509.

>> * draft-wouters-dane-otrfp-00

These actually specify how to get authenticated key material from the
DNS.  (However, they don't encrypt the DNS transaction, so the 
identity of the user being communicated with is leaked to NSA and
any other wiretappers...)

	John

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2013 22:48:01 -0400

> replacement for the finger protocol.

Alas, finger ignores the MX records, and the standard client does not pass
the entire command line argument in the query (making multi-tenant hard).

This effectively means that one has to run the fingerd on the web server,
as many want "example.com" to answer the same as "www.example.com", and HTTP
doesn't do SRV lookup either.

If finger could be updated to look up a SRV RR to find the finger server,
it would be very so much easier to deploy.  Given IPv6, putting a unique IP
address per hosted domain isn't so terrible, but having
        % finger [email-masked]

send "[email-masked]" as it's query would help too.

I frankly think that having per-user data in DNS is not a horrible thing.
It is true that the DNS administrators often will not like this, but as was
pointed out in a WG session last week, many them will respond to a request
like:
        "please insert
                user.example.com IN NS ns1.user.example.com"

even when they don't understand:
     "please delegate user.example.com to ns1.user.example.com"

(yes, you can finger me for keys to check this message. John convinced me it
the utility 15 years ago.)

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Aug 2013 13:09:09 +1000

> the utility 15 years ago.)

DNS mailbox format for users is just plain wrong.  It results in
namespace collisions between users and hosts which has all sorts
of implications on delegations.  Additionally DNS name normalisation
is nowhere near similar to the normalisation used for user names
in mail servers so even if you addressed the namespace collision
there are still major problem.

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

---

From: "Rick van Rein (OpenFortress)" <[email-masked]>
Date: Wed, 7 Aug 2013 08:31:08 +0200

Hello,

>> RFC 742 from 1977.

Love it.  My first play with redundant/reliable hosting was "fingerhosting", which
achieved 99.9999% uptime due to tripple servers of 99% each :)

>> encrypted;

Yes, so it is purely there for public data.  For such data, it's better-positioned user data than DNS.

>> and it is designed to be human-readable, not
>> machine-readable.

That ought to be good for some degree of privacy ;-) but this is why so many attempts are made to structure data in DNS but why I prefer LDAP with its large set of predefined techniques and formats -- and it's openness for DIY specs that won't clash due to the use of ASN1 OIDs.

I wouldn't mind seeing http://user@domain/ step into this cavity BTW -- HTTP must be the only protocol on the planet (well, sort of) that does not support usernames, and we are using this pattern very, very often nowadays.

>  Given IPv6, putting a unique IP

This would be an operational impossibility I fear.  If people need to get an IPv6 address per user to be able to run finger, then no admin will support it.  "Just use WebFinger", I can hear them say.

WebFinger by the way, is too far up the stack IMHO -- it queries the .well-known directory on a webserver, fills in a pattern and does a query.  Sounds more like DNS stuff to me, and a good application for http://user@domain/ -- the other obvious beneficiary being OpenID.  This might call for a SRV record of some kind in the DNS -- or an NAPTR.

> the utility 15 years ago.)

Wonderful :)  If there were more like you it'd be the IPv6-added-value-showcase that could help the transport concur the World ;-)

-Rick

---

From: Paul Wouters <[email-masked]>
Date: Thu, 8 Aug 2013 15:44:49 -0400 (EDT)

> any other wiretappers...)

I would suggest we address DNS query privacy in a generic way for all
DNS, although even if you just encrypt, it might not be enough when the
adversary has so many listening points, and the user immediately uses
the DNS information for another action (eg an IM message or sending an
email)

Paul

---

From: "Rick van Rein (OpenFortress)" <[email-masked]>
Date: Thu, 8 Aug 2013 21:55:48 +0200

Ah!

> I would suggest we address DNS query privacy in a generic way for all DNS,

I feel a proposal towards DNS over TLS [1] coming up ;-)

-Rick

[1] The hard way, even… first negotiating ANON-DH, then doing a secure renegotiation to obtain the identity of the remote server, and finally retrieving the data requested.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 9 Aug 2013 15:56:00 +0100

> replacement for the finger protocol.

https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/

> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Aug 2013 15:52:02 -0400 (EDT)

> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/

To get back somewhat to the openpgpkey dns record type....

The CERT record (RFC-4398) has a type for PGP (data is key blob) and iPGP
(data is URI pointer)

http://tools.ietf.org/html/rfc4398#section-2.1

Perhaps the openpgpkey draft can be generalised and obsolete RFC4398. It
would allow storing user PKIX certificates in DNS as well pgp keys (or
URI's to these respectively)

Paul