[Cryptography] Strong DNS Names

Viktor Dukhovni cryptography at dukhovni.org
Wed Sep 7 11:19:12 EDT 2016


On Wed, Sep 07, 2016 at 10:01:21AM +0200, Phill wrote:

> I have a better idea:
> 
>    alice at example.com.MB2GK-6DUF5-YGYYL-JNY5E
> 
> There is no need for a suffix at all. The probability of an accidental
> collision here is 2^92 and we can use a variety of techniques (e.g. work
> hardening) to increase the work factor. We can even pile on more characters
> if need be.
> 
> No need for permission from ICANN either. Their US government mandate
> expires in a few months and I don�t recognize their new one.
> 
> From a deployment perspective, we can (and should) allow clients to retrieve
> policies from their trusted DNS server by simply adding a line to the
> effect that if the TLD is more than 24 characters long, interpret it as
> a UDF key fingerprint.

This can be less ad-hoc.  See page 10 of section 2.3.1 of RFC 5890:

    https://tools.ietf.org/html/rfc5890#page-10

where the diagram shows a taxonomy of DNS labels.  In particular
labels starting with "??--" are reserved, with "xn--" used for
IDNA.  Your scheme could define a new two letter code for
destination-specific in-name trust anchors.  Perhaps "ta--"?

> The new strong DNS addresses are compatible with pretty much every existing
> email client. Just route the inbound and outbound email through a proxy
> that strips off fingerprints from strong email addresses, fetches the
> policy and acts accordingly. Users can compose and read email just like
> normal. The only difference being that their email is now encrypted end
> to end (but not in client storage).

Right, this I assume because the trust-anchor fingerprint is
(unavoidably) in this case for the domain and not the end-user.
(which certainly improves email usability).

A difficulty I see is that key rotation becomes difficult to
impossible.  Is the assumption that this key is off-line, and is
only used infrequently (by the domain owner) to sign other keys
that do all the interactive work?  So it can't be changed withoout
invalidating saved addresses of this form?  (A change of TA, might
typically mean a change of domain ownership)?

> The chief security issue here is that if we are talking about alice at eop.gov
> <mailto:alice at eop.gov> or alice at microsoft.com <mailto:alice at microsoft.com>
> or the like, we want to make sure that we are talking to the implied domain
> if it matters. Which is something that enterprises can do with an
> appropriate CAA record requiring messages to that domain be supported by
> a suitably validated cert.

The CA/B forum strangled CAA in its crib, by deciding to make
implementation optional for CAs. :-(

-- 
	Viktor.


More information about the cryptography mailing list