[Cryptography] Strong DNS Names

[Phillip Hallam-Baker]

OK so replying to various comments.

On the upper case thing, yes of course, its case insensitive. I was cutting
and pasting...

example.com.mb2gk-6duf5-ygyyl-jn5e

On the issue of other algorithms, in my UDF scheme, the first byte is a
version identifier that can be used to change the digest algorithm and/or
the construction. The UDF draft reserves one code for SHA-2-512 and another
for SHA-3-512. These have been intentionally chosen so that they give the
first characters M (for Merkel-Damguard) or S (for Spongeworthy).

I am currently writing an update tothe UDF spec that proposes using a
further 7 version IDs for 'work hardened' fingerprints. If the first 25
bits of your digest value are 0, then you could shorten the fingerprint
value by 5 characters and a 15 character fingerprint is sufficiently secure
for many purposes. Unfortunately there are patent encumbrances that would
have to be settled with the rights holder to use it which may not happen in
time to use it for OpenPGP.


And the digest is not just over the content of the digested message, it is
over the digest of a content type identifier (MIME type) and the digest of
the content. That makes it possible to use the same scheme for S/MIME and
OpenPGP and SSH etc. Or any new thing you want to define.

In answer to Donald, yes I am being greedy. But not as greedy as the folk
asking for $250K per TLD.

Since these are fingerprints, the chance of an accidental collision are
very very small, 2^100 for the examples I gave. And those are before
fingerprint improvement to 250 bits. I don't think there is any reasonable
chance that another DNS address would conflict by accident.

That said, the request for some sort of mechanism to distinguish the
identifiers syntactically may be useful. I did actually consider the ta--
prefix. But I want the fingerprints to look as close as possible to the
presentation in other contexts. What we could do is this:

example.com.mb2gk
​-​
-6duf5-ygyyl-jn5e

​Given that the UDF scheme has internal expansion flexibility built in, the
idea that anything that has two dashes at indexes 5 and 6 is a UDF
fingerprint seems reasonable to me.​

​Alternatively, if we were going to go that route we could make the first 2
characters the version ID giving us 26*36 = 936 possible code points.​

​So the UDF fingerprint would be m
​f--​
b2gk
​
6
​-​
duf5
​
y
​-​
gyyl
​​-
jn5e
​d​
​

example.com.m
​f--​
b2gk
​
6
​-​
duf5
​
y
​-​
gyyl
​​-
jn5e
​d​



On Thu, Sep 8, 2016 at 12:07 AM, Christian Huitema <huitema at huitema.net>
wrote:

> On Wednesday, September 7, 2016 8:19 AM, Viktor Dukhovni 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
> >> ...
> > ...
> > 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)?
>
> Yes, that's classic big problem with any scheme using fingerprints as
> identifiers. The lifetime of keys, and fingerprints, is typically shorter
> than the lifetime of identities. The classic solution is to have a degree
> of indirection. On the other hand, the lifetime of email addresses is also
> shorter than the lifetime of identities. After Alice leaves "Example Co.",
> he is likely to use a different address than "alice at example.com". In
> fact, if "Example Co." hires a new employee also called Alice, the email
> address will be recycled and will point to this new Alice's identity.
>
> So maybe bundling the address and the fingerprint in a single token is
> just OK. At least, it has a "failsafe" property. If I send encrypted mail
> to the old "alice at example.com.MB2GK-6DUF5-YGYYL-JNY5E," I know that it
> will not be readable by the new Alice.
>

​This is of course spot on. To get the maximum value from this scheme,
Alice has to have a fingerprint that is as stable as possible, potentially
something that she can keep her whole life.

And that is the requirement I have designed the Mathematical Mesh​

​to fulfill. The Mesh uses JSON encoding instead of ASN.1 and drops 90% of
the junk from PKIX/X.509. But it supports the same type of certificate
chaining that CAs use in X.509.

So the idea is that Alice has a life-long public key pair that can in
principle be kept offline and only used to sign administration keys that
are used in her devices to sign application profiles, connect devices to
her profile, etc. The only time the master key is ever needed is if Alice
has 'messed up' and it is necessary to sign a new administration key. ​

​Of course there may be cases where Alice wants more than one master
fingerprint of change her life long fingerprint. But the system is designed
on the principle of not forcing this to happen unless it is necessary.

Depending on which fingerprint is used, we can achieve different results.

Let us say that Alice and Example Inc. Both have persistent Mesh profiles.
We can create two different addresses:

alice at example.com.me--<alice fingerprint>​
alice at example.com.me--<
​Example Inc.​
fingerprint>​

​Which one I wish to use depends on the context in which I am interacting
with Alice. In some circumstances I may wish to talk to the Alice I met
personally in a previous job. In other circumstances I may wish to contact
her as an employee of Example Inc.

The message I send may end up being sent encrypted under different keys as
a result. If I am contacting Alice to tell her I have found as zero day bug
in a major operating system I may not want Example Inc. to have access to
that data. If on the other hand I am conducting a business transaction with
Example Inc and there is a contract, it is vital that Example. Inc. have
access to that contract and the discussions if Alice falls under a bus.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160908/628b0abe/attachment.html>