[Cryptography] Strong DNS Names

[Natanael]

Den 7 sep 2016 11:36 skrev "Phill" <hallam at gmail.com>:
>
> A while ago, I proposed a new form of ‘strong email address’ that
combined a PGP fingerprint like identifier with an email address:
>
> MB2GK-6DUF5-YGYYL-JNY5E?alice at example.com
>
> The idea of this scheme is that MB2GK-6DUF5-YGYYL-JNY5E is the
fingerprint of a key under which a policy for sending mail to
alice at example.com is signed. That might have statements like ‘emails must
be signed’, ‘use PGP’, etc. [...]

> I have a better idea:
>
> alice at example.com.MB2GK-6DUF5-YGYYL-JNY5E [...]

I'd like to make minor modifications.

First, many systems that would be incompatible uses simple regexp of
similar in the string. That would likely (favorably) cut out the end of an
appendix using an invalid first character in the domain, such as using ;
(semicolon) as the separator, so that the system still can communicate with
it.

Although I'm not sure if too many systems would outright not allow you to
enter it (I've seen plenty examples of that, still forcing the user to edit
it out manually. But are these systems significantly more common than
systems that simply have length limits that would *also* deny it? (I'll
have to admit that this first point is more bikeshedding than anything
else, unless somebody can bring data...)

Second, shouldn't we allow for changing ciphers? As an example, Bitcoin
already uses the prefix 1 to signify an address using ECDSA secp256k1
encoded in a particular way with double hashing. The prefix 3 signifies a
hashed script which itself can invoke secp256k1, SHA256 or any potential
future algorithm additions. More prefixes can be added if necessary. All we
need to do here is to define prefixes that identify ciphersuites.

We don't need to define more than one or require the support for more than
one default choice (we don't need a new TLS mess), the point is simply to
enable a transition without breaking compatibility if the previous choice
of cipher becomes insecure. Perhaps to be able to switch to a post quantum
cipher suite in a near future. A system seeing an address with unsupported
ciphers could suggest that the user checks for any available software
updates to potentially add support for it.

> The chief security issue here is that if we are talking about
alice at eop.gov or 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.

We can tie into DNSSEC+DANE, perhaps make it a requirement for clients
using this scheme. Not that it matters much if the message is encrypted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160907/f4548b6e/attachment.html>