Subject: [dane] wrt How to look up KEY’s for Email addresses

From: =JeffH <[email-masked]>
Date: Wed, 25 Mar 2015 08:58:37 -0700

just a quick core-dump here to build on my comments at the mic yesterday in 
the DANE session regarding the "How to look up KEY’s for Email addresses" 
topic..

i would restate the topic as "given an email address, lookup a public key(s) 
that may be mapped to it"

some of us have been around this overall block before back in the 
mid-to-late '90s.

note that formally, an email addr is an "addr-spec":

     addr-spec       =   local-part "@" domain   [RFC5322]

the values of local-parts are typically based on "natural names", eg of 
people.  Natural names are syntactically messy and they change over time, 
thus so do typical email addr local-part values.

from my personal perspective, based on past experience, here's what I think 
would be viable for standardization from a high-level non-DANE-specific 
perspective..

###
1. given email addr of "[email-masked]"

2. find a "local-part lookup service"  at "example.org" [eg using SRV lookup 
in DNS]

3. query example.org's local-part lookup service for info (eg public key) 
mapped to "foobar"

4. this results in an answer (eg public key) or not [eg "not found" status code]
###

Thus, the Really Hard Parts -- which involve looking up info mapped to 
local-parts (and all the backend support infrastructure) that are not 
amenable to standardization (i.e. they are "site-specific") -- are buried 
behind/below the "local-part lookup service"  (this is where, classically, 
when one is mapping 'natural names' to identifiers and other attributes, 
registry and directory services are employed).

For a case-history example of the considerations, infrastructure, name & 
attribute mapping, etc. of directory service deployment -- which supports a 
local-part lookup service for a directory-enabled MTA, see..

Registry & Directory Infrastructure: A Case History
<http://kingsmountain.com/doc/StanfordRegistryAndDirectoryCaseHistory-1999-05-11.pdf>

the local-part lookup is described on slide 16.

names and identifiers characteristics are on slide 15.

backend support infrastructure: slides 12, 13, 14

overall themes/philosophies begin on slide 20

DANE wg might conceivably define how to place subject's public keys in 
secure DNS mapped to some identifier, but to me it doesn't seem that any of 
the other potentially-standardizable solution portions are appropriate for 
the DANE wg.

there have been various approaches to step 2 (above) over the years and I'm 
not up-to-speed on the attempts since about year 2000, so won't attempt 
point to any, but suggest others who are interested to research it (and not 
just within the RFC corpus)

HTH,

=JeffH

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 11:44:19 -0500

> some of us have been around this overall block before back in the

Oh yes, I remember sendmail fuzzy matching.

> from my personal perspective, based on past experience, here's what
> I think would be viable for standardization from a high-level
> non-DANE-specific perspective..
> 
> ###
> 2. find a "local-part lookup service"  at "example.org" [eg using
> SRV lookup in DNS]

And how to authenticate the service using DANE.

> 3. query example.org's local-part lookup service for info (eg public
> key) mapped to "foobar"
> 

Yes.  A lookup service.  And if we're going to do this, then there's no
much point to putting local-part -> public keys in DNS.

Problem: DNS (even with DNSPRIV) is much more light-weight than any
         service that uses TLS.

Solution: Make a light-weight lookup (idempotent) protocol.

To start we could use TLS.

(Since we're talking about a lookup protocol, there are TLS features
that are not needed, such as replay protection, session resumption, and
so on.  At minimum server authentication [via public keys published in
the DNS] and confidentiality and integrity protection are all that's
needed.)

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2015 20:06:18 -0000

>Problem: DNS (even with DNSPRIV) is much more light-weight than any

You're going to use the result to send mail messages.  Why does the
lookup need to be a lot faster than sending the mail message?

R's,
John

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Mar 2015 15:19:33 -0500

> lookup need to be a lot faster than sending the mail message?

Good point.  Never mind that.