On Wed, 1 Apr 2015, Nico Williams wrote:
(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.)
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.
Yes, in addition to not being able to tell an outage from an attack like
DNS with "indeterminate" or "bogus".
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)
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).
Those zones are the only ones that matter if you want to replace a PGP
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.
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.
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.....
In the MUA.
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.
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.
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
As for MTAs: they wouldn't be doing these lookups (unless you want your
MTA to auto-encrypt to your correspondents when it can).
Exactly why I wrote: https://github.com/letoams/openpgpkey-milter
Any mail domain that chooses simply not to implement any dynamic mailbox
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.
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.
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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
