On Tue, Jul 21, 2015 at 03:46:00AM -0400, Paul Wouters wrote:
> >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.
>
> 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.
> 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.
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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
