On Sun, Nov 16, 2014 at 09:27:58PM -0800, Watson Ladd wrote:
> So if I could summarize the problems they are:
>
> 1: keys are hard
> 2: spam is hard
> 3: discovery is hard.
>
> UI work is needed for 1. 2 I have no idea. 3 seems to have some good
> ideas floating around to solve it. Of course, in an ideal world we
> would get perfect secrecy, but that's much harder, although methods
> are floating around to do it.
So at least in terms of keys and discovery, the DANE-specific
obstacles as are I see them (feel free to contribute to the Dec 02
DANE WG interim):
1. Mapping user addresses onto DNS:
a. Email addresses use an alphabet more extensive than DNS labels.
b. Email address localparts can (infrequently) be longer than DNS labels,
and base32 or similar encodings make the problem worse.
c. Email addresses are often, but not always case insensitive.
d. DNS names are case insensitive.
e. There are for better or worse significant concerns around directory
harvesting (even with NSEC3).
f. Some folks want key lookups to work with DNAMEs, with the keys
published just once and automatically functional for all domain
name variants.
The current draft proposal lookup keys are base32 encoding of
SHA2-254 hashes of the just the user address localparts. This
addresses a/b/f and very marginally e.
However, the conflict between c and d is rather severe. Key
lookups will only succeed when the email address query is for
the canonical capitalization of the email address. If the
email address were something like:
[email protected]
and the destination domain supported case-insensitive delivery
(e.g. via LDAP in which addresses are not case-sensitive), one
might publish the same keys for each of:
[email protected]
[email protected]
[email protected]
and hope that these combinations cover all the likely variants.
2. Revocation, or where does one attach the horse to the motor car?
http://www.psmag.com/blogs/time-machine/electric-hybrid-cars-cyclists-pedestrians-traffic-safety-52337/
- DANE is an online system for publishing fresh key material.
- Ideally revocation in DANE is a matter of just removing the
relevant records from DNS, and publishing only those keys
are valid at the present time (modulo TTLs and ideally
short RRsig lifetimes).
- Since X.509 PKI certificates (OCSP notwithstanding) are typically
long-term offline attestations, carrying over the web PKI "revocation"
compensating measure is not necessarily a good idea for DANE.
- Furthermore, in current mail client S/MIME implementations
there is no semantically sound treatment of revoked or expired
certificates. Mail that arrives today should indeed avoid no
longer applicable keys (whether revoked or simply no longer
published). However mail that arrived while the key was still
valid and was successfully verified at the time, should generally
remain valid even if the key is (sufficiently) later withdrawn.
- So we are still talking past each other with completely
different models and associated requirements, some want to
put the horse before the cart, others say the cart is a motor
car.
- There needs to be a life-cycle model of key management in a
world where today's keys are published online, that defines
not only how the current keys are located, but how saved mail
is handled and whether any sort of "revocation" is required,
or whether de-publication is sufficient.
--
Viktor.
_______________________________________________
Endymail mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/endymail
