Subject: [dane] Discussion on OPENPGP and SMIME record location

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 20 Jul 2015 05:08:58 -0400

Dear Colleagues 

This note is to stimulate discussion, on higher level design of the these two email protocol, 
discussion on local-part “name” is a separate discussion. 

Right now we have two “active” email sign/encrypt technologies, proposing to store “keying” information in DNS, 
When we want to do a lookup we have two design dimensions, 
— names 
— types 

In the name space OPENPGP and SMIME are proposing two different “zones”/names where keying info is stored this has certain advantages and disadvantages. 
Further more there have been proposals to have different “zones” for sign and encrypt for SMIME. 

Pro: 
	- easy to see if organization "supports" technology 
      - if SMIME is operated by different group than PGP then there are no organizational conflicts

Con:
     - To see if user X supports encrypted mail may require 2x lookups ( i.e. in each Technology X all local part guesses) for organizations that have users that use both PGP and SMIME
     - more DNS data to maintain and sign. 

Antidode: If an organization has to support users with both types of keys, it can publish both in one zone by using DNAME. 

In the type space we have OPENPGPKEY and SIMIMEA types proposed and the idea is that the contnents of the records specify usage rules. 
We can also do this via more types. 

We have seen arguments in the past ranging from “Lets ignore this” to “We MUST support organizational realities including split views” 

Question: 
 a) do we want to merge the zones where EMAIL keying is stored ? 

or  
 b) Do we want to reflect policies in naming? 
 c) do we want to reflect polices in types 
 d) do we want to reflect policies inside records 

or 
 f) we can not answer this, experience will have to guide us. 

Think about how you want to answer these questions and lets have a short discussion in the meeting on Monday but please start discussion on the mailing list if you feel strongly about this 

Olafur & Warren 

PS: if you have a speaking slot in the meeting, now is a good time to send in slides

---

From: Doug Montgomery <[email-masked]>
Date: Mon, 20 Jul 2015 06:00:40 -0400

a) not now (e.g. f), if both are headed to experimental.  As you note there
are ways to optimize if it turns out the type/rr conventions are the same.
  What would seem suboptimal at this time is to create the friction of
forcing a converged approach until we fully understand the usage scenarios
through experience.

b,c,d) were you only referring to the SMIME vs PGP policy?  Or other
potential secure email usage policies.  A while back, in comments on the
requirement draft, we suggested the ability to convey some expected usage
policies WRT email security.  These seemed important enablers to us in an
enterprise environment.   Not sure if you are referring to those sort of
polices, or just SMIME vs PGP policies.

f) Given that you posed the questions as a series of alternatives .... this
is the real answer.   We seem to have interested parties prototyping
running code for various components of both solutions.  Establish a
realistic, but hard, deadline to evaluate the results of the experimental
phase - making it clear that further spec work is envisioned on both
approaches before adopting on a standards track.

dougm

On Mon, Jul 20, 2015 at 5:08 AM, Olafur Gudmundsson <[email-masked]> wrote:

> In the name space OPENPGP and SMIME are proposing two different
> “zones”/names where keying info is stored this has certain advantages and
> disadvantages.
>      - To see if user X supports encrypted mail may require 2x lookups (
> i.e. in each Technology X all local part guesses) for organizations that
> have users that use both PGP and SMIME
> Antidode: If an organization has to support users with both types of keys,
> it can publish both in one zone by using DNAME.
>
> In the type space we have OPENPGPKEY and SIMIMEA types proposed and the
> idea is that the contnents of the records specify usage rules.
> We have seen arguments in the past ranging from “Lets ignore this” to “We
> MUST support organizational realities including split views”
>
> Question:
> Think about how you want to answer these questions and lets have a short
> discussion in the meeting on Monday but please start discussion on the
> mailing list if you feel strongly about this
>
> Olafur & Warren
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
DougM at Work

---

From: James Cloos <[email-masked]>
Date: Mon, 20 Jul 2015 10:41:08 -0400

They should be at the same place even though multiple lookups are likely
to be required anyway -- not everything will fully support an ANY query.

And I renew my (previously ignored) suggestion that they, along with
tlsa records for client certs where the cn or other lookup -- such as
a sip url or the like -- has an @ in it -- be under _at.

Mapping @ to _at makes it easy to remember and easy to read.

Similarrly, the function mapping the local part to a dns element also
should be the same for every record type.  Whatever that function should be.

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

---

From: "Wiley, Glen" <[email-masked]>
Date: Mon, 20 Jul 2015 14:51:55 +0000

>to be required anyway -- not everything will fully support an ANY query.

I like the idea of using a consistent encoding for anything that uses a
locator
constructed forma user name.  The use case for end user key material is
such that
multiple lookups cause far less pain than multiple lookups getting in the
way of
rendering a browser page.

>Mapping @ to _at makes it easy to remember and easy to read.

Does it make sense to add encoding for the @ since the hashes are
unreadable?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Jul 2015 15:11:01 +0000

> Mapping @ to _at makes it easy to remember and easy to read.

Mnemonic value notwithstanding, the main advantage of _at is that
that it is *short*.  So if the namespaces are unified (segregated
only by RRtype not qname), then "_at", seems like a sensible choice
of generic empty non-terminal.

In terms of query efficiency, if there are any MUAs out there that
support both OpenPGP and SMIME, and try to find either set of keys,
then a common qname that yields NXDOMAIN is likely to cached by
the iterative resolver just long enough to save a full round-trip
just to find out that neither set of keys exists.

-- 
	Viktor.

---

From: "Wiley, Glen" <[email-masked]>
Date: Mon, 20 Jul 2015 15:17:17 +0000

After reading your response it occurs to me that James was suggesting
adding _at as a label rather than encoding it in the hash - makes

more sense.

Having said that, I still question whether _at really helps much since
humans aren¹t likely to read/write the encoded user name.  Even if we
decide to not hash the user name it will need to be encoded because of
special characters.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Jul 2015 15:32:21 +0000

> adding _at as a label rather than encoding it in the hash - makes

Specifically:

    <some-local-part-encoding>._at.example.com. IN SMIMEA 3 0 0 <leaf-certificate>
    <some-local-part-encoding>._at.example.com. IN OPENPGPKEY 3 0 0 <public-keyring>

are shorter than:

    <some-local-part-encoding>._smimecert.example.com.  IN SMIMEA 3 0 0 <leaf-certificate>
    <some-local-part-encoding>._openpgpkey.example.com. IN OPENPGPKEY 3 0 0 <public-keyring>

> humans aren't likely to read/write the encoded user name.  Even if we

The advantage is for the administrator managing the zone, not the
user querying it, and shorter labels reduce the pressure (if any)
on the combined length limit of 255 for the full qname.

I can't claim that this is a compelling rationale, but it makes
sense to me.

-- 
	Viktor.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Mon, 20 Jul 2015 16:39:49 +0000

> On Jul 20, 2015, at 11:32 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

Another point: the chances that a zone may already want to use ``_at’’ for some other reasons (and thus causing a collision) are higher than the more descriptive ``_openpgpkey,’’ or ``_smimecert’’ labels.  As of now, it seems very unlikely (imho) that a zone would already be using those latter labels for something else, but I would hesitate to say the same about the former.  Not to mention, being descriptive in our labels could be advantageous for reasons I think I have seen others mention on the list.

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 20 Jul 2015 16:42:54 +0000

On Mon, Jul 20, 2015 at 04:39:49PM +0000, Osterweil, Eric wrote:

> Another point: the chances that a zone may already want to use "_at"
> for some other reasons (and thus causing a collision) are higher than the
> more descriptive "_openpgpkey," or "_smimecert" labels.

There's no "collision".  The records are disambiguated well enough
by the RRtype.  Few enough domains are using "_at", to make this
a concern.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Mon, 20 Jul 2015 12:42:30 -0400

>>>>> "WG" == Wiley, Glen <[email-masked]> writes:

>> Mapping @ to _at makes it easy to remember and easy to read.

WG> Does it make sense to add encoding for the @ since the hashes are
WG> unreadable?

Putting f(local-part) into the dns w/o some sort of separator label may
increase the size of ANY requests for the apex zone enough to require
edns or tcp, so some separator label SHOULD be used.

And what is simpler and more efficiend than makking @ to _at?

-JimC

---

From: "Osterweil, Eric" <[email-masked]>
Date: Mon, 20 Jul 2015 17:06:02 +0000

> On Jul 20, 2015, at 12:42 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> by the RRtype.  

That would depend on how the administrator of the zone plans to use their own namespace.

> Few enough domains are using "_at", to make this
> a concern.

I wonder how many is enough to warrant concern?  Ahead of that, I’m taking some measurements to see what I can observe.

Eric

---

From: James Cloos <[email-masked]>
Date: Mon, 20 Jul 2015 14:26:59 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> Mnemonic value notwithstanding, the main advantage of _at is that
VD> that it is *short*.

Yes, short was one of the motivations.

-JimC

---

From: Paul Wouters <[email-masked]>
Date: Tue, 21 Jul 2015 03:46:00 -0400 (EDT)

> a sip url or the like -- has an @ in it -- be under _at.

The use of -at. is only when you would run an ANY query. As we have seen
with qmail, using ANY queries for real data, as opposed to diagnosing
DNS, is fraught with peril. I would not want to support the use of ANY
queries, even though I see its appeal to run a single ANY query on a
single user to get all their personal information. Sending a few queries
at once in parallel is not really much slower, and I don't think any of
these personal DNS properties discovery would be that sensitive to latency.

> should be the same for every record type.  Whatever that function should be.

I guess you are suggesting everyone gets their own delegation at
base32/split._at.domain.com to put all their personal information in?

I could see some use for that, but I would say lets first see how well
OPENPGPKEY and SMIME do, and then see about creating something like this
in the future.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jul 2015 15:30:27 +0000

On Tue, Jul 21, 2015 at 03:46:00AM -0400, Paul Wouters wrote:

> The use of _at. is only when you would run an ANY query.

No, because as you note, "ANY" is unworkable.  Rather the proposed
shared (by SMIMEA, OPENPGPKEY, ...) non-terminal has the advantage
that it is shorter than the labels in either of the drafts, is more
mnemonic (where data about localparts goes) and works slightly
better with negative caching.

> OPENPGPKEY and SMIME do, and then see about creating something like this

Changing, later would be a mess.  If it makes sense do it now.

However, to be honest I still fear that for lookups of end-to-end
email crypto keys, DNS may not be the right protocol.  We discussed
the privacy leak issue yesterday, which is added to concerns about
managing large zones and complexity of fuzzy matching.

I still think that perhaps using DNSSEC to publish the transport
endpoint for a lookup service that runs over TLS, and DANE to
publish TLSA records for same deals with both the privacy problem,
and all the encoding problems.  One then defines a suitable access
protocol (say HTTPS at some .well-known URL authenticated via DANE)
and JSON request/response format.  The server operator can query
their own DNS (think HESIOD) if they like, but can also front-end
LDAP, cache results, rate-limit malfeasant clients, ...

We should perhaps also consider the interaction of end-to-end email
encryption with first-contact filtering of spam.  Many would want
the initial encryption key to be the gateway key, with the recipient
disclosing the true end-to-end keys only if he chooses to reply in
a way that does that (the lookup service would provide only a digest
of that key, and the full data of the gateway key).

Perhaps, given that the drafts are slate to go out as experimental,
someone who's motivated to pursue the approach I outlined should
publish a draft for that experimental approach, and prototype code,
and time will tell which is more applicable to real-world email.

The points we seem to be stuck on (namely how to encode email
addresses as qnames) seem rather insignificant by comparison.

I can't say I know which model would prove more successful, but I
am not yet convinced that the DNS approach is the more likely
winner.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Tue, 21 Jul 2015 12:50:41 -0400

>>>>> "PW" == Paul Wouters <[email-masked]> writes:

PW> The use of -at. is only when you would run an ANY query.

Keeping them all together has more value than that.

And I noted in my post that any is unlikely -- in general -- to support
openpgpkey/smime/tlsa.

So that clearly wasn't the motivation I noted.

PW> I guess you are suggesting everyone gets their own delegation at
PW> base32/split._at.domain.com to put all their personal information in?

Effectively, yes.

Even if the end user doesn't manage it personally, it is still easier
for those who do to have a simple, for-everything pattern to follow.

-JimC

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 21 Jul 2015 19:29:01 +0100

On 21/07/15 16:30, Viktor Dukhovni wrote:
> email crypto keys, DNS may not be the right protocol.

Also playing in this space:

https://tools.ietf.org/html/draft-moore-email-addrquery-01

- an smtp extension for doing this sort of lookup.
-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jul 2015 19:19:10 +0000

> - an smtp extension for doing this sort of lookup.

Which proxies the queries via TLS through the MSA (post authentication),
thus introducing no new privacy issues, since once the mail is
sent, the MSA sees the envelope recipients anyway.

The MSA will then proxy the request also via TLS, and ideally
authenticate the request via DANE (this leg is an MTA-to-MTA SMTP
operation).  With a bit of work, this proposal seems promising.

We also have:

    https://tools.ietf.org/html/draft-miller-saag-key-discovery-00

which at first glance is not a step in the right direction.

-- 
	Viktor.