Subject: [dane] Names of mailbox records in draft-ietf-dane-smime and draft-ietf-dane-openpgpkey

From: "John Levine" <[email-masked]>
Date: 13 Mar 2015 18:23:34 -0000

I see that in dane-openpgpkey, the name on the record is

	<hash>._openpgpkey.domain

and in dane-smime, the name is:

	<hash>._smimecert.domain

These are two different names for the same mailbox.  Since they use
the same hash, wouldn't it be a better idea for both of them and any
future RRs that use hashed mailboxes to use the same name?

	<hash>._mailbox.domain

There's no confusion between the two, since they're different RR
types.  The tree walking attacks are no different, since the attacker
knows the small set of _token names that might be in use either way.

I expect we will end up with conventional kludges to deal with the
reality that systems treat mailbox names as case independent, e.g.,
publish the hash of the name as normally capitalized, but also publish
a CNAME at the hash of the name with everything in lower case.  (This
doesn't work very well for non-ASCII names.  It's a kludge, but like
all kludges, it'll work better in practice than in theory.)  With one
name, we only need to do one kludge per mailbox, rather than the
product of the number of mailboxes and the number of RR types.

R's,
John

PS: The payment record draft that showed up a few days ago uses _pmta,
but again, same mailbox, should be at the same name.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Mar 2015 15:45:21 -0400 (EDT)

> product of the number of mailboxes and the number of RR types.

I can see how two different sysadmins administer the _openpgpkey and
the _smimecert zones possibly even running on different nameservers.
Like the smime one on Microsoft and the openpgp one on Linux.

> but again, same mailbox, should be at the same name.

If we really want a "user" to have their own private "space" inside
the DNS, we should really give the user their own zone so they are
the only ones signing for it. So then <hash>._mailbox.domain should
have an NS record. That might be a good idea, but very much out of
scope here.

Paul
ps.Don't tell me you want to start running ANY queries against
    <hash>._mailbox.domain :)

---

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2015 16:05:44 -0400

> Like the smime one on Microsoft and the openpgp one on Linux.

But we've gotten along with A and MX records at the same name for 30 
years.  By this logic, every new RR type should have its own name prefix, 
just in case someone might want to manage it differently.  I hope we agree 
that's ridiculous.  There's no special processing for OPENPGPKEY or SMIMEA 
records, so there's no reason they would be handled differently by name 
servers.

If someone wants to manage OPENPGPKEY and SMIMEA records separately, why 
should the answer be any different than if they want to manage A and MX 
records separately?  Do it in your provisioning system, don't put extra 
noise in the DNS.

>   <hash>._mailbox.domain :)

Naah, my qmail is patched.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Mar 2015 13:10:21 -0700

> On Mar 13, 2015, at 11:23 AM, John Levine <[email-masked]> wrote:
> 

This could go either way. If the WG thinks that the user, or someone responsible for the user, will add and change DNS records for that user, your proposal would clearly be better because you could delegate the user to a new subzone. On the other hand, if the WG thinks that the security admin will be the one adding and changing records for a particular type of mail security, then the design we are using now is better. I lean towards the second, but can see the merit of the first now that people are thinking of using this for things other than just mail security.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Mar 2015 13:17:33 -0700

Forgot to CC the list on my reply to John. (Sorry for the duplicate, John.)

There are some problems that can only be solved by adding a level of
indirection.

However, in the reverse direction (removing a level of indirection), this
can be done trivially: DNAME.

I.e. for those places where putting both RRtypes at the same owner name is
desired, it is enough to add one DNAME record that points to the other
place in the DNS tree. (It doesn't matter much which one is "primary",
other than maybe some performance).

DNAME-aware things will use the DNAME. DNAME-unaware things will expect,
receive, and use, synthesized CNAMEs.

This scales a lot better (DNAME vs manually- or script- maintained CNAMEs).

Having DNAME then allows the case-munging CNAME-per-mailbox to also scale.

So, I do not support unifying the _labels to a single _label.

Brian

On Fri, Mar 13, 2015 at 11:23 AM, John Levine <[email-masked]> wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 Mar 2015 16:25:28 -0400 (EDT)

On Fri, 13 Mar 2015, John R Levine wrote:

> But we've gotten along with A and MX records at the same name for 30 years.

But A and MX records live within the same zone, whereas _openpgpkey.tld
currently is its own zone. It is a nice and clean separation.

For example, when I filled this up with 3000 records for
_openpgpkey.fedoraproject.org it became obvious this zone couldn't live
in the same git repository as everything else due to its sheer size. The
same might no be true for some payment record or email alias record.

We could use _mailbox, but I don't see much advantage from tying
different RRtype's at the same prefix. What is affected by this
other then a line of code somewhere in a program only few few people
will see? As you said, people still need to query for the individual
QTYPEs.

Paul

---

From: "John R Levine" <[email-masked]>
Date: 13 Mar 2015 16:48:29 -0400

> currently is its own zone. It is a nice and clean separation.

It sounds like you are you saying that every new RR type should come with 
a prefix, to provide this same nice clean separation.  If not, what's 
different about this RR type?  It's not like we've never had zones with a 
lot of leaf names before.

> same might no be true for some payment record or email alias record.

Maybe I'm spoiled, but a zone with 3000 records does not seem particularly 
large to me.  (One of my zones, admittedly an outlier, has 110,000, but it 
poses no problems for the python and mysql scripts and NSD servers I use 
to manage my DNS.  I update it every day.)

Poor provisioning tools don't strike me as a very good reason to make long 
term DNS design decisions.  That's how we ended up with everything 
overloaded onto TXT.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2015 20:54:17 -0000

> On the other hand, if
>the WG thinks that the security admin will be the one adding and changing records for
>a particular type of mail security, then the design we are using now is better.

I'm trying to imagine a situation where one security admin assigns PGP
keys, a different one assigns S/MIME keys for the same users, and they
hate each other so much that they need to use separate DNS
provisioning systems.  Then I try to imagine how those same two admins
nonetheless manage to get both sets of keys into the same MUAs.

Now I'll be quiet.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Mar 2015 14:10:29 -0700

On Fri, Mar 13, 2015 at 1:54 PM, John Levine <[email-masked]> wrote:

> provisioning systems.

You obviously haven't had the fun of big corporate environments.

They might not even know who each other are, let alone trust each other.

And, there may be anti-social-engineering reasons that they are not allowed
to trust each other.

FWIW, I doubt very much that PGP keys are assigned by a security admin.

> Then I try to imagine how those same two admins
If you have to get public keys INTO the MUA,  you are (by definition) not
using DNS.

The entire point of these proposals are for publishing and
querying/discovery via DNS.

Or are you thinking private keys? For PGP and S/MIME, I believe those
are apples & oranges. Again, it is the MUA developer's responsibility to
make them
both work, and I expect a "pull" model vs a "push" model.

Brian

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Mar 2015 17:19:56 -0500

> future RRs that use hashed mailboxes to use the same name?

I prefer the latter.

> but again, same mailbox, should be at the same name.

If they are all the same thing, they should all be using the same
domainname.  If it could make sense to separate them, then not.  But I
think these are all the same thing.

Nico
--

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Mar 2015 09:33:49 +1100

Why are we arguing about this?  We can support both seperate zones
and combined zones. Just use "_openpgpkey DNAME _mailbox" if you
want to collape the number of zones.

Mark

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

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2015 23:07:20 -0000

>want to collape the number of zones.

That would certainly work, but if there isn't actually an important
operational reason to use more than one zone for per-mailbox data, why
use more magic token names than we need to?

Now that I look at it again, I don't follow Paul W's argument about
large numbers of names in the zone.  He can have a separate zone for
his PGP keys whether it's _openpgpkey.domain or _mailbox.domain.

For people who manage their file of S/MIME and PGP key records
separately, this should usually do the trick:

 $ cat file-of-openpgpkey-records file-of-smimea-records > my-mailbox-zone

R's,
John

---

From: James Cloos <[email-masked]>
Date: Fri, 13 Mar 2015 19:25:22 -0400

>>>>> "JL" == John Levine <[email-masked]> writes:

JL> 	<hash>._mailbox.domain

I posted in the past that smime and openpgp should use the same _name
(search the archives for '_at').  I gave up when it got zero traction.

It also would be a good place to look for TLSA RRs for certs supplied
by tls clients which have mailbox-like names.

I hope you hae better luck.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 Mar 2015 07:52:02 +0000

> (search the archives for '_at').  I gave up when it got zero traction.

I don't recall seeing this proposal, perhaps it predates my membership
on this list (since ~March 2013).

I like it a lot.  The different RRtypes adequately partition the
various records, and a common prefix collates them per user.

> by tls clients which have mailbox-like names.

Including user-specific TLS certs as TLSA RRs also makes some sense.
I can imagine adding a "check_dane_access" to Postfix that is an
alternative to "check_sasl_access".  The authenticated name would
be the envelope sender, and the associated TLSA RRs enable verification
of the presented certificate chain.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 14 Mar 2015 08:00:48 +0000

On Fri, Mar 13, 2015 at 01:10:21PM -0700, Paul Hoffman wrote:

> This could go either way. If the WG thinks that the user, or
> someone responsible for the user, will add and change DNS records
> for that user, your proposal would clearly be better because you
> could delegate the user to a new subzone. On the other hand, if
> the WG thinks that the security admin will be the one adding and
> changing records for a particular type of mail security, then the
> design we are using now is better. I lean towards the second, but
> can see the merit of the first now that people are thinking of
> using this for things other than just mail security.

I think this mental model of tools that update the DNS is too naive.
It seems to assume that the tools can make decisions based only
on the requestor credentials and the owner name of the RRset to
be added.

I think it is far more likely that administrators and users will
be interacting with a middle-ware management system that enables
them to add and remove keys and *that* system will be able to
publish all the requisite records on behalf of either individual
users or administrators.

So the structure of the DNS namespace should be optimized for
clarity/simplicity, rather than a presumed set of management tools
(e.g. direct authorization to inject records via dynamic update into
a particular portion of the namespace).
 
-- 
	Viktor.

---

From: Carsten Strotmann <[email-masked]>
Date: Tue, 17 Mar 2015 07:13:11 +0100

Hi,

> knows the small set of _token names that might be in use either way.

being able to delegate subdomains for "_openpgpkey" and "_smimecert"
adds operational flexibility. Already during test implementations of the
drafts, I found it helpful to be able to delegate the two domains to a
different set of nameservers, into differnt zones with different ACLs
(and TSIG-Keys for dynamic updating owned by different people).

I see that in corporate environments PGP and S/MIME are managed by
separate teams/entities (S/MIME being the "official" supported
protocol, PGP being the "defacto" used protocol by the IT team). Having
different domains to delegate really would ease implementation in some
scenarios. The price for the added flexibility is not too high.

Carsten Strotmann

-- 
Sent with my mu4e

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 17 Mar 2015 13:13:15 +0000

On 3/13/15, 4:10 PM, "Paul Hoffman" <[email-masked]> wrote:

>This could go either way. If the WG thinks that the user, or someone
>responsible for the user, will add and change DNS records for that user,
>your proposal would clearly be better because you could delegate the user
>to a new subzone. On the other hand, if the WG thinks that the security
>admin will be the one adding and changing records for a particular type
>of mail security, then the design we are using now is better. I lean
>towards the second, but can see the merit of the first now that people
>are thinking of using this for things other than just mail security.

I would like to suggest that we need to begin considering the need for
users to directly affect the records that refer to them.  For example you
want a user to be able to manage their own public key without getting the
zone administrator involved directly.  One way to do this is to use a
system that proxies for the zone administrator, but the bottom line is
that as we move toward user specific data in the DNS we need to begin
thinking about things a little differently.

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 17 Mar 2015 13:17:13 +0000

>on the requestor credentials and the owner name of the RRset to

I agree enthusiastically.

>publish all the requisite records on behalf of either individual

This is exactly the direction I think things need to head to move
DANE adoption forward into the mainstream.

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Mar 2015 11:46:24 -0500

> thinking about things a little differently.

It'd be nice if there was a decent authorization model for DNS updates.

In practice one has to use a proxy to implement authorization for DNS
updates.

This is a topic for a different working group, but DANE brings this
problem to the foreground as administrators have to delegate authority
over TLSA RR contents to the owners of the associated end entities (in
this case: the end entities themselves).

Without a standard mechanism for delegation of authority DANE will be
difficult to use in enterprise systems (where TLSA RRs for servers may
not matter so much, but user S/MIME certs will probably matter more).  I
suspect that proprietary and/or IMAP (with extensions) email services
will end up acting as the proxies in this case.

("Obviously" one might want to store authorization information in DNS
itself, but the moment one brings user groups into the picture, things
get custom/complicated.)

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 17 Mar 2015 17:08:26 -0000

>users to directly affect the records that refer to them. ...

In many cases it would indeed be useful to let people publish their
own keys.  But I would strongly caution against designing the
publication mechanism around what seems convenient at the moment with
the DNS software people are familiar with.  That approach has led to
some rather unfortunate designs, with SPF TXT records as the poster
child.

If you want to provide a way for people to publish public keys for
their e-mail addresses, add a key publishing extension to POP and
IMAP.  MUAs already need to know the private keys, so they know the
public keys, too.  They already know how to talk to POP and IMAP
servers, they already have the user credentials to sign into those
servers, and in my experience, whoever runs the POP and IMAP servers
already knows what e-mail addresses correspond to those credentials.

Then do NOT attempt to specify how the keys get from POP or IMAP into
the DNS provisioning system and into the DNS.  There's a zillion
provisioning systems, most of which are awful, but which have to be
upgraded anyway if they're going to handle OPENPGPKEY and SMIMEA and
other new record types.

R's,
John

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 17 Mar 2015 18:56:40 +0000

While I agree that this is probably out of scope for the DANE WG it is a
Very important part of promoting DANE and seeing adoption increase outside
The expert user circles.

One of things we want to talk about next week is building tools that
address
What the group feels are necessary elements that might be missing or
Impeding adoption for DANE.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 21 Mar 2015 18:59:03 -0400

> On Mar 13, 2015, at 2:23 PM, John Levine <[email-masked]> wrote:
> 

Depends on how the systems are operated, Operator can use DNAME to make the two names be there same 
i.e _smimecert.<domain>  DNAME _openpgpkey.<domain> 

Not sure if having multiple namespaces for keying is a good idea or not. 
Olafur