[Cryptography] Strong DNS Names

[Donald Eastlake]

Hi,

On Wed, Sep 7, 2016 at 11:19 AM, Viktor Dukhovni
<cryptography at dukhovni.org> wrote:
> 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.

Seems to me to fit under IETF approval the same way .onion did,
notwithstanding that that might be controversial.

> > 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.

That's greedy. Why do you get to seize all TLDs over 24 characters for
this scheme of yours?

> 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--"?

Precisely, although I feel it might be even nicer and politically
easier to format things as
alice at example.com.MB2GK-6DUF5-YGYYL-JNY5E.??--
for some "??".

By the way, the use of all caps makes it look like your letters are
case insensitive but in any case they had better be as letter case
could change if anything DNS aware touches this. (See RFC 4343)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com