Subject: Re: [dane] encoding mail addresses in the DNS

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 10:26:15 +0100

A nit on this topic (with no hats). I never liked the sha224 thing
being used for this. If some form of hash is needed I'd much prefer
if sha256 was used and then truncated. Morally, sha224 is also a
truncated sha256, but it is not bitwise the same. So sha224 is
generally treated as an entirely separate algorithm by APIs.

Since sha256 is our current fav. hash function, there's code for
that everywhere. And since sha224 is never or almost never used
we normally don't need that, so sha224 might not be available on
all platforms. (And could be deprecated in future even if it's
present now - getting rid of unused code being a good thing.)

But the real win here with a truncated sha256 is for people who
have to have their code audited e.g. for CC purposes - having to
have the sha224 code present for anything could cause them to
incur pointless costs when doing such audits - e.g. if the auditor
says: "Hey, please prove to me that you don't do any security
sensitive things with sha224." This is the same logic that causes
us to not want to use md5 even for non-security functions.

So, if hashing anything here, please stick with sha256 and truncate
the output if you need it shorter.

Thanks,
S.

PS: Yes, I know John's draft doesn't do hashing, but since we're
on the topic again, I thought I'd stick in my oar:-)

On 01/04/15 02:17, John Levine wrote:
>> An alternative is to go back to the original base32 encoding, which
>> is lossless, and thus can allow the remote DNS server (a special-purpose
>> DNS lookup engine serving a zone with per-user information) to
>> decode the local-part and perform whatever fuzzy matching may be
>> appropriate.
>>
>> The lossless encoding can support longer names by breaking them up
>> into multiple labels.
>>
>> This allows static DNS to be published where desired, and custom
>> code to produce dynamic results when appropriate.
> 
> I wrote up a draft summarizing the ways one might do mailbox
> name lookups in the DNS with something close to the local-part
> rules that MTAs have:
> 
> http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/
> 
> There's two reversible encodings, including a worked out version of
> base32 that handles full 64 character local-parts, preserves the
> lexical order of local-parts, and makes signed dynamic zones at least
> somewhat possible, an implementation of regular expression matching
> that I think is cool, but probably doesn't scale adequately for large
> mail systems, and a straightforward way to securely identify a web
> lookup service.
> 
> As far as I can tell, the base32 approach handles everything that
> hashing does, is no harder to use if you want to publish a static set
> of names, but still offers the possibility for large mail systems to
> serve stuff on the fly.  Take a look.  I can send you a tiny python
> script that turns local-parts into the base32 names if you want.
> 
> R's,
> John
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 
>

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 10:57:06 -0400

> the output if you need it shorter.

For reasons discussed at great length, I don't think any sort of hash is a 
good idea here.  Do you see any problems with the base32 encoding?

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 17:05:48 +0100

On 01/04/15 15:57, John R Levine wrote:
> For reasons discussed at great length, I don't think any sort of hash is
> a good idea here.  Do you see any problems with the base32 encoding?

I'm neutral, but just took the opportunity to get back up
on my own hobby horse:-)

S

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 12:15:45 -0400 (EDT)

> good idea here.  Do you see any problems with the base32 encoding?

The current mechanism for lookup can only return exact matches.

The application creating the query already has access to the unhashed
name. So whatever future protocol extension is used, the application
can use the unhashed name with that future extension.

Applications using base32 would still need to have an exact match to
return anything in DNS - so I do not understand the use of base32 and
another confusing empty non-terminal dot in DNS.

I do not understand the advantage of base32 in the QNAME.

Paul

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 11:20:53 -0500

John,

I'm OK with sections 4.1 and 6 from your I-D, provided that MUAs that
implement either MUST implement both.  This leaves the choice to mail
domains, and it addresses the scalability issues discussed.

I would add that the URI RRs for section 6 should be signed, that
clients must validate them with DNSSEC, that the URIs must be HTTPS
URIs, and that the authority of each such URI SHOULD (MUST?) have TLSA
RRs.

Nico
--

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 12:23:45 -0400

> I do not understand the advantage of base32 in the QNAME.

As Viktor pointed out, the advantage is that the server can easily recover 
the local-part from the query, which makes it possible for a specialized 
server to do whatever it does and generate a response dynamically.  You 
can't do that with hashes.

I've written DNS servers that generate responses on the fly from a 
database where it does application-specific lookups and transformations. 
It's surprisingly easy.  They don't do DNSSEC yet but I'm planning to take 
a whack at that later this year.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 12:26:12 -0400

> domains, and it addresses the scalability issues discussed.

You'll notice that my draft says its intended status is experimental.  We 
really need some experience with this stuff before we try to cast it in 
stone.  I know of at least two projects to do SMIMEA support in an MUA, so 
with any luck we can find out how it works reasonably soon.

> URIs, and that the authority of each such URI SHOULD (MUST?) have TLSA

Well, sure.

Regards,

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 11:36:40 -0500

> with any luck we can find out how it works reasonably soon.

It can be experimental if you like, but if we don't require MUA
support for both of these methods we'll be stuck later.  We must at
least recommend it.  I don't think publishing as experimental absolves
us of addressing that problem now, nor does it mean that we can't have
normative or quasi-normaitve language in the document.

>> URIs, and that the authority of each such URI SHOULD (MUST?) have TLSA

I know it's obvious, but it has to be stated.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 09:43:33 -0700

On Apr 1, 2015, at 9:23 AM, John R Levine <[email-masked]> wrote:
> As Viktor pointed out, the advantage is that the server can easily recover the local-part from the query, which makes it possible for a specialized server to do whatever it does and generate a response dynamically.  You can't do that with hashes.
> 
> I've written DNS servers that generate responses on the fly from a database where it does application-specific lookups and transformations. It's surprisingly easy.  They don't do DNSSEC yet but I'm planning to take a whack at that later this year.

This sounds like a new protocol that changes the nature of the DNS. That's fine, but it certainly does not belong in DANE, and probably not in DNSOP.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 12:46:49 -0400 (EDT)

On Wed, 1 Apr 2015, John R Levine wrote:

> server to do whatever it does and generate a response dynamically.  You can't 
> do that with hashes.

Which might make sense for SMTP servers or whatever new protocol servers
you come up with, but not for DNS QNAMEs.

> I've written DNS servers that generate responses on the fly from a database 
> where it does application-specific lookups and transformations. It's 
> surprisingly easy.  They don't do DNSSEC yet but I'm planning to take a whack 
> at that later this year.

And you will be re-creating user/zone enumeration walking if you would.

And you would violate the rule that only mail servers apparently may
interpret mailbox names, and not secondary name servers. Unless you add
a whole bunch of other requirements to this document, like DNS servers
need to synchronise mailbox names and DNS servers must require online
DNSSEC signing.

Anything more complicated than a simple query-response, does not belong
in the DNS. Once you are not in the DNS, your application can use the
original LHS without any encoding and use whateve non-DNS protocol
extension you come up with.

Paul

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 11:49:29 -0500

> This sounds like a new protocol that changes the nature of the DNS. That's fine, but it certainly does not belong in DANE, and probably not in DNSOP.

DNS servers exist which serve dynamically-generated data, and DNS
servers exist which serve signed (on the fly) dynamically-generated
RRsets with non-existence proofs.  IIUC PowerDNS is one example.

Nico
--

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 12:51:44 -0400

> This sounds like a new protocol that changes the nature of the DNS. 
> That's fine, but it certainly does not belong in DANE, and probably not 
> in DNSOP.

Not at all.  The queries and reponses are exactly the same as with any 
other DNS operations.  Only the internal implementation of the DNS server 
is different.

I've been sending dynamically generated responses to queries to 
contacts.abuse.net for the better part of a decade with no interop 
problems I'm aware of, so it can't be that new or exotic.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 12:53:57 -0400 (EDT)

> RRsets with non-existence proofs.  IIUC PowerDNS is one example.

And requiring the private DNS key is available on all name servers
for online signing really adds a huge amount of risk to the server
in case of compromise - an attacker could make up OPENPGPKEY records.

Paul

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 12:53:59 -0500

> in case of compromise - an attacker could make up OPENPGPKEY records.

Any dynamic lookup will have this problem.  The pointer-to-server
approach has the same problem, only at an HTTPS server instead of at a
DNS server.  The scope of compromise can be limited in both cases (since
the online keys in the DNS case could be for just the SMIME/OPENPGP
sub-zones).

John L.'s regexp DFA concept doesn't have any such problems, but I think
it'd be rather slow for MUAs...

Any mail domain that chooses simply not to implement any dynamic mailbox
name canonicalization can fob off all normalization problems onto users.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 13:13:41 -0500

> http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/

The All Names Valid approach has a problem: we're looking for S/MIME or
OPENPGP public keys, so that's what needs to be found.  For any public
key algorithms where not every possible bit string is a possible public
key, and where clients can figure that out, the server would have to
generate distinct plausible public keys, otherwise clients could still
enumerate the set of plausible mailboxes.

I would still prefer to require MUAs to implement the DNS
(base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup.
Whether mail domains choose to implement static or dynamic DNS lookups,
or the pointer-to-HTTPS-server, should be up to them.

That said, I really don't mind living with users having to type in
peers' e-mail addresses correctly.  Forcing users to either have
easy-to-enter email addresses on their business cards (and/or QR codes)
or publish all reasonable variants of their e-mail addresses, seems
perfectly reasonable -if annoying, for the +list use case- to me.  The
choice should be the mail domain admins'.

Nico
--

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2015 14:35:36 -0400

> enumerate the set of plausible mailboxes.

That would require 2^512 lookups, which I hope we agree is too slow. 
Every possible name returns an answer, the vast majority of which have a 
null key.  Since there's no NXDOMAINs, there's no pointers to tell you 
where the next non-null key is.  If you're worried about people guessing 
addresses through dictionary attacks, they do that now, there's no way to 
prevent that without also preventing legitimate lookups, although you can 
greatly mitigate the damage by rate limiting when you see a lot of 
failures.

> or the pointer-to-HTTPS-server, should be up to them.

I don't feel strongly about whether base32 or pointer-to-https is better, 
but history tells us that if you have two services that are supposed to be 
the same, they never are.  That's why we need to do experiments to see 
what's workable in practice so we can pick one that we know servers can 
implmenent and users can use.

> peers' e-mail addresses correctly.

I just don't see that agreeing with reality.  Particularly with non-ASCII 
names, there's way too many ways to type what looks like the same thing.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 16:44:24 -0400 (EDT)

On Wed, 1 Apr 2015, Nico Williams wrote:

> Any dynamic lookup will have this problem.

Not a non-dns based lookup that has no private DNSKEY ?

>  The pointer-to-server
> DNS server.

Yes, in addition to not being able to tell an outage from an attack like
DNS with "indeterminate" or "bogus".

> The scope of compromise can be limited in both cases (since

Those zones are the only ones that matter if you want to replace a PGP
key? I don't understand your point.

> John L.'s regexp DFA concept doesn't have any such problems,

I guess I still don't understand where this matching engine that returns
variable answers actually lives.....

> but I think it'd be rather slow for MUAs...

Slow for MUA's and MTA's don't really matter that much. Some people
greylist for an hour.

> name canonicalization can fob off all normalization problems onto users.

Agreed, but I still don't understand how using base32 in DNS helps that
draft at all. The QNAME either matches or not. You cannot return a DNS
record that does not match the QNAME/QTYPE.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 16:53:26 -0400 (EDT)

> names, there's way too many ways to type what looks like the same thing.

This is not a problem that is fixable in any way.

I do not know how to type in any letter in any script that is not on my
keyboard. My keyboard has no Arabic, Chinese, French, Korean or German
characters on it. I have no chance whatsoever to ever be able to type
any of that in. I'm sure people with an Arabic keyboard can't enter
Traditional Chinese either, so this is a problem for 100% of internet
users. If that's the only thing on your business card, the world cannot
email you. At best, they will type as best they can into google, and
hope it will find a page with the correct email address on it for cut
and paste and hope it works.

This has absoutely nothing to do with encryption. I can't solve this
problem and I'm not going to try and solve that problem.

Paul

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 16:16:37 -0500

> Not a non-dns based lookup that has no private DNSKEY ?

(Recall that we have a label suitable for doing a zone cut such that the
SMIME and OPENPGP mappings are in their own zone, with its own signing
keys.  I expect operators to make that zone cut, and the I-D should
recommend it, when the mappings are dynamic and require on-line private
keys.)

In both cases there are private keys which are used to protect just the
mailbox->public key mappings and nothing else.  The scope of compromise
is the same in both cases.

> DNS with "indeterminate" or "bogus".

DNS has that too (timeouts, SERVFAIL).

> key? I don't understand your point.

You can't use compromise of a live-signed dynamic zone to compromise a
parent or sibling zone that is not signed with the same keys.

> variable answers actually lives.....

In the MUA.

> Slow for MUA's and MTA's don't really matter that much. Some people

MUA UI latency matters a great deal.

As for MTAs: they wouldn't be doing these lookups (unless you want your
MTA to auto-encrypt to your correspondents when it can).

> record that does not match the QNAME/QTYPE.

If we don't care to do anything other than exact matching then hashing
works, but so does base32 encoding.

A loss-less encoding makes it easier to deal with on the operator/
publisher side.

Nico
--

---

From: James Cloos <[email-masked]>
Date: Wed, 01 Apr 2015 17:45:16 -0400

[replying to semi-random post in the thread]

I think the real problem is the idea of using OPENPGPCERT as a discovery
mechanism.

It doesn't need to be.

It works much better as just an additional trust path.

For openpgp, an hkps query followed by a dane lookup on each uid in the
returned keyset will work much better.

Or webfinger followed by dane.

With TLSA offering a trust path for the https.

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

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 17:55:43 -0400 (EDT)

> recommend it, when the mappings are dynamic and require on-line private

Yes, but if anything, the document should recommend not to use online
DNSSEC signing for _openpgpkey zones. It would be a prime attack vector.
By using offline signing, no one can ever forge an OPENPGPKEY even if
they own the DNS server or the Mail server.

> DNS has that too (timeouts, SERVFAIL).

Yes, but those lead clearly to "indeterminate" and are handled as
"verification failure". And DNS is much harder to block than a mapping
server on port 12345. And does not have corner cases on what to do when
the TLSA record matches the web server but the certificate is expired,
or uses a blacklisted CA or has the wrong EKU bits or many other things
that TLS libraries will check for you even if you don't care about it.
(I know, I do X.509 in IKE and deal with crypto libraries that only have
  TLS as use case)

> parent or sibling zone that is not signed with the same keys.

huh? I don't need to compromise the parent of _openpgpkey.nohats.ca if I compromise
_openpgpkey.nohats.ca, although if I could clearly I can redelegate
_openpgpkey.nohats.ca. Although not all zones will use a zone cut for
_openpgpkey.

>> variable answers actually lives.....

The way John explains it to me, the matching engine lives in the dynamic
DNS server code - You send base32-cat("paul") as QNAME and you actually
get the answer to the QNAME of base32("wouters"). It gets even more
complicated because now to ensure you're not being lied to, you need
the NSEC(3) proof that the entry with QNAME "paul" does in fact, not
exist. So now you are looking at a DNS protocol change. Unless you do
online signing...

Furthermore this ties user accounts, SMTP and DNS servers all
together in a dynamic way and need to ensure those are all
servers are sync'ed up. I know of many people who gave up on even
just running secondary MX because of the user lookup problem and
double bounces via their secondary MX. The mail system does not have
a good track record here for small and simple redundant deployments.

And all for a use case that has not even be solved for unecrypted email,
where I attempt to type in some french, german or traditional chinese LHS
from a business card into my email client and somehow magically I end
up mailing the right email address that my keyboard does not even
support inputting.

> MUA UI latency matters a great deal.

Ok, in the corner case of you first typing the content of the email, and
only then the From: line, yes you are right, it matters :P

> MTA to auto-encrypt to your correspondents when it can).

Exactly why I wrote: https://github.com/letoams/openpgpkey-milter

> A loss-less encoding makes it easier to deal with on the operator/

And using a "." in there will increase the change of dns wire or dns
presentation format mistakes in running code. Which is one of the
reasons we opted for a hash that fits within 63 characters.
Implementation simplicity.

Paul

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2015 23:13:35 -0000

>This is not a problem that is fixable in any way.

One of the major reasons that mail servers do fuzzy matching of
local-parts is so they can deal with the multiple ways people might
type something.  It's a problem the mail world has been dealing with
for decades.  The challenge is figuring out how to port the solutions
into the DNS if we're going to publish mail addresses in the DNS.

>This has absoutely nothing to do with encryption.

Quite true, but this discussion is about mail addresses at least as
much as it's about encryption.  Recall that last week we saw a
proposal to publish payment info using the same naming scheme.

I still don't see what the objection is to base32.  If you want to
publish a static set of names on a regular DNS server, you can do
that, the same way you'd do hashed local-parts.  Or if you're up for a
more challenging programming task, you can write a DNS server that
takes the queried local-parts and uses your MTA's mailbox rules when
it responsds to DNS queries.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Wed, 1 Apr 2015 17:12:40 -0700

On Tue, Mar 31, 2015 at 6:17 PM, John Levine <[email-masked]> wrote:
>>is lossless,

> hashing does

The draf, has a "characters/octets" conflation problem, as do the
sequence of successors to RFC-822.

This likely dates back to the before-UTF and before-IDNA era, and how
the docs were updated.

What is not clear to me, reviewing the updates over time, are the following:
- when and why was the 64-length local-part introduced? (It appeared
magically in RFC 2821 4.5.3.1)
- when it changed from "64 characters" to "64 octets" in RFC 5321,
this implicitly affected UTF-2/3/4 languages - was this impact
considered? (In UTF, #characters is not automatically #octets.)
- is the 64 octet limit sufficiently universally enforced to be
considered an actual de-facto standard?
- is it really the case that UTF-2 mailboxes are <= 32 characters,
UTF-3 mailboxes <= 21 characters, and UTF-4 mailboxes <= 16
characters?

Hashing, by definition, does not care about the length of local-part,
and thus is less restrictive. In effect, it ignores that 64 character
limit. (I'm not entirely sure if that is a pro, con, or irrelevant.)

However, the _other_ issue is that the length of local-part _encoding_
implicitly limits the parent domain name length. Using 2 x 52-octet
long labels, reduces the maximum domain name length to 255-106=149
octets, minus whatever the "_mailbox" label's length is, and is
applicable to IDNA and non-IDNA domain names alike. Each A-label
encoding of a multi-level name, eats 5 octets (xn-- plus the dot). At
3 labels , this becomes 125 octets of punycode. Dividing that by 2, 3,
or 4 (for various UTF flavors) and then splitting that into 3 parts
(one per label), runs the risk of running the host name out of
characters.

So, simply from an IDNA perspective, hashing is less restrictive (105
vs e.g. 56).

Brian

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2015 01:19:27 -0000

>The draft, has a "characters/octets" conflation problem, as do the

Until RFC 6530-6532, SMTP commands were (and mostly still are) ASCII
only, and mail message headers were and are ASCII only.  When 5321
says octets, those octets hold ASCII characters.  

With internationalised mail as described in RFCs 6530-6532, there is a
new SMTP extsnsion SMTPUTF8 which allows the client and server to
agree that they allow UTF-8 in the commands and message headers as
well as ASCII, but the octet limits don't change.  In particular,
local-part is limited to 64 octets whether it contains only ASCII or
UTF-8.

>magically in RFC 2821 4.5.3.1)

It was documenting existing practice.  See below.

>considered?

There was nothing to consider -- non-ASCII wasn't valid in any SMTP
transaction so the 64 characters was 64 octets.

>considered an actual de-facto standard?

As I learned the hard way when I was experimenting with BATV (a hack
that put signatures in bounce addresses), if your local-parts are
longer than 64 octets, things break.  I think MS Exchange was one of
the strictest, and it's all over the place.

>UTF-3 mailboxes <= 21 characters, and UTF-4 mailboxes <= 16

If you are referring to multibyte UTF-8 characters, a UTF-8 string
typically has a mixture of characters whose encodings are of different
numbers of bytes.  The SMTP and mail header limit is on the UTF-8
octets, not the decoded Unicode characters.

>limit. (I'm not entirely sure if that is a pro, con, or irrelevant.)

I think it's irrelevant -- I don't think I've ever seen a local part
longer than 64.  Most are much shorter.

>applicable to IDNA and non-IDNA domain names alike.

I suppose that could be a problem, but it's one we might run into at
some point whatever we do. 

Here's a data point: I run abuse.net, a place where people register
abuse contact addresses primarily for their mail domains.  People have
registered info for over 500,000 domains during the last decade.  I
just checked, and the longest names for which anyone has ever
registered a contact are 67 characters, and they look pretty bogus:

mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3-mp3.net
realestateagentnewhomeforsalerealtysjoselistingsjoserestaurants.com
sanjoserestaurantitalianchinesejapaneseindianmexicanpizzafrench.com

People can and do register names with three or four name components,
but these are the longest overall.  Everything else is shorter, mostly
much shorter.

So it looks to me that the chances of a non-contrived mail address
having a domain approaching 140 octets is vanishingly small.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2015 04:08:56 -0000

>they own the DNS server or the Mail server.

There's some assumptions here I'd like to unpack.

One is the assumption that keys are all very valuable.  Sure, some of
them are, but some aren't.  As an extreme example, consider something
like [email-masked], addresses intended to be used a few times
and then discarded, where every address has little value and the
associated keys would't be worth much either.

Also, a rule like this doesn't help interoperation -- nobody talking
to a DNS server can tell whether it's doing online or offline signing.
DNSSEC allows online signing, it's going to continue to happen, and
it's up to the server managers to assess their security issues, of
which potential theft of DNSSEC keys is only one of many.  I'd be more
worried about users getting phished and bad guys using their
credentials to upload PGP keys, replacing the users' own in the zone
to be signed.

Most important, there's the scale issue.  Reports say that Yahoo has
over 300,000,000 active mailboxes and Gmail has over 500,000,000.  I
gather the goal here is to make publishing your key cheap and easy, so
let's posit modest success and say that 20% of Gmail users have keys.
It looks to me like a typical PGP key is about 1.5K, so that's 100M
keys at 1.5K or a zone file of about 150 gigabytes.  The largest
signed zone I'm aware of is .COM which as of yesterday is a little
under 10GB before signing.

Is it really plausible that anyone is going to generate and sign and
serve static zones more than an order of magnitude bigger than .COM?
That seems like a stretch.

On the other hand, with base32 coding and the option of online
signing, it should scale OK since the records in the zone are
generated from the user database and signed as needed.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Apr 2015 00:45:01 -0400 (EDT)

On Thu, 2 Apr 2015, John Levine wrote:

> It looks to me like a typical PGP key is about 1.5K,

That is not my experience from adding 1000+ keys from the
fedoraproject.org into the _openpgpkey zone. The keys are bigger.

> That seems like a stretch.

You do not need static zones. You just need to pull the right signed
data from further inside your network on demand. I do not know of any
DNS provider doing online signing for 1 zone on dozens or hundreds of
DNS servers. The chance of losing your private key, and worse, not even
knowing someone else has a copy of your private key, would be too high.

In your example 499,000,000 records will never be asked for and do not
need to be available on the DNS servers. The signed records do not need
to reside in "zone files". The nameservers can fetch data on demand,
without having the private key to sign their own data.

I'm sure Yahoo and Google are smart and rich enough to implement the
most insane and complicated scheme we throw at them. But there are
many other players with a lot less time and money to throw at these
problems.

My problem is not with base32, it is with your suggested split and using
a "." (or was it "\." and who knows what the difference is?)

I fear will cause interop issues. If we can do lossless encoding using
gzip then base32 or something, I would be okay with that. As long as
we stick to < 63 characters. If that means some theoretical long high
entropy email address cannot be mapped, I'm fine with that. I'm solving
a practical matter, not a philosophical one.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 05:29:14 +0000

> a "." (or was it "\." and who knows what the difference is?)

Naturally the former, as the idea would be to create two labels,
not a label with a ".".

> gzip then base32 or something.

Gzip is not very good with short strings, you'd need enough data to
warrant the overhead.  Mostly you lose:

    $ echo viktor.dukhovni | wc -c
    16
    $ echo viktor.dukhovni | gzip -c | wc -c
    36

    $ echo Gabriel.Jose.de.la.Concordia.Garcia.Marquez | wc -c
    44
    $ echo Gabriel.Jose.de.la.Concordia.Garcia.Marquez | gzip -c | wc -c
    62

If the goal is primarily not to supporting key "discovery" (security
for first contact when one is not even sure of the address), but
rather primarily key lookup for addresses known to be canonical
(thus iPhone capitalization e.g. is moot, since it will find an
address-book match I expect), then DNS not being able to find
keys for variant names is fine, and we don't need lossless encodings.

As for how people will publish their zones, we simply cant't predict
what any particular domain will do, but we can be sure everything
that can be done will be done by someone.

Cloudflare's hosting of www.ietf.org uses online signing with P-256.
Note that for non-existent names they return NODATA rather than
NXDOMAIN (and the NSEC RRs claim to have all the standard RR types
other than the one you ask for):

    $ dig +noall +comment +ans +auth +nocl +nottl +nosplit +dnssec -t tlsa vvv.ietf.org.cdn.cloudflare-dnssec.net.
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27653
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    cloudflare-dnssec.net.  SOA     ns1.cloudflare-dnssec.net. dns.cloudflare.com. 2017357885 10000 2400 604800 3600
    vvv.ietf.org.cdn.cloudflare-dnssec.net. NSEC \003.vvv.ietf.org.cdn.cloudflare-dnssec.net. A WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC HIP TYPE61 SPF

    $ dig +noall +comment +ans +auth +nocl +nosplit +dnssec -t a vvv.ietf.org.cdn.cloudflare-dnssec.net.
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59135
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    cloudflare-dnssec.net.  SOA     ns1.cloudflare-dnssec.net. dns.cloudflare.com. 2017357885 10000 2400 604800 3600
    vvv.ietf.org.cdn.cloudflare-dnssec.net. NSEC \003.vvv.ietf.org.cdn.cloudflare-dnssec.net. WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC TLSA HIP TYPE61 SPF

Power-DNS is often configured to to online signing and to return
less radically creative "narrow-mode" NSEC3 RRs, (signature of
[hash-1, hash+1] interval).

-- 
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 2 Apr 2015 10:40:49 -0400

> fedoraproject.org into the _openpgpkey zone. The keys are bigger.

I wouldn't argue -- that just makes the scaling issue worse.

> a "." (or was it "\." and who knows what the difference is?)

Oh, for heaven's sake.  It's the same dot that's between nohats and ca or 
that's between the hash and _openpgpkey in your draft.  Domain names can 
only have 63 octets per components so you write the base32 string as two 
components rather than one.  The base32 is all LDH so there's no quoting 
needed.

It's hard to imagine a DNS server that would have problems with that.

Regards,

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 2 Apr 2015 15:25:37 +0000

> or the pointer-to-HTTPS-server, should be up to them.

Following up on an earlier comment: by adding a URI field to the SMIMEA RR (and keeping the CAD for verification on the other end), zone admin/operators can add an RR at the apex of their zone, that points to another service, secure the delegation with the CAD material, and then (optionally) add per-inbox RRs (also possibly using URI pointers) in their zone.  This would also let domains experiment with oracle-like-services in a compatible way with direct key learning from mailboxes, me thinks. :)

<snip>

Eric