Discuss mailing list

[Rouben <rouben AT rouben.net>]

Hi all,

Interesting conversation! My apologies for the wall of text and for breaking the quote-thread.

First of all, congrats on setting up the ACME service prototype, I’ll give it a whirl and report back when I get the chance.

Second, with regards to email working on OpenNIC domains (which is a prerequisite for S/MIME), I think the “parallel universe” issue boils down to the fact that we would need to pretty much start operating our own internal, OpenNIC email service that uses a standard ICANN TLD in order to talk to the rest of the world. A gateway between the parallel universes, if you will. :) 

The MTAs (mail servers) would need to maintain a database, or otherwise programmatically determine the ICANN to OpenNIC mappings of domains, so that whenever an email message with an OpenNIC email address is sent to the ICANN parallel universe, all OpenNIC email address domains are rewritten with their ICANN counterparts. Conversely when an email comes from the ICANN parallel universe to ours, the ICANN domains are rewritten as OpenNIC domains.

For example:

I send the following from my OpenNIC mail server to my ICANN domain, while CCing to another OpenNIC mailbox.

From: rouben AT rouben.geek

To: rouben AT rouben.net

Cc: example AT support.acme.libre

Subject: Hello

The OpenNIC MTA handling this email keeps the headers above intact when delivering to support.acme.libre’s mail exchanger (MX host), but rewrites the domains on the OpenNIC domains before attempting delivery to rouben.net’s MX by appending the ICANN TLD of “opennic.org” to all OpenNIC email domans:

From: rouben AT rouben.geek.opennic.org

To: rouben AT rouben.net

Cc: example AT support.acme.libre.opennic.org

Subject: Hello

I then respond to the message above from my rouben AT rouben.net mailbox, whose email servers I have no control over, and which resides in the ICANN universe (MTAs have no OpenNIC name resolution capability).

The MX for opennic.org would then need to do some header rewriting to rewrite the ICANN equivalent OpenNIC domains into their actual OpenNIC counterparts and attempt delivery to the appropriate OpenNIC MX hosts. So when the response from rouben AT rouben.net arrives to rouben AT rouben.geek and example AT support.acme.libre’s inboxes, it looks like this:

From: rouben AT rouben.net

To: rouben AT rouben.geek

Cc: example AT support.acme.libre

Subject: Re: Hello

I think the above is doable technically, albeit it has a number of issues. One being that the mail relay operating the domain rewriting service would be a potential single point of failure/centralization.

This could be mitigated by each OpenNIC email operator having their own “parallel universe gateway” as long as the domain rewriting method is consistent and relies on proper MX records. MX records are important here particularly in cases where an OpenNIC TLD operator decides to register their own ICANN “parallel universe” equivalent TLD and use that for email header rewriting. For instance if “rouben.geek” becomes “rouben.geek.ca” rather than “rouben.geek.opennic.org” the operator of .geek would need to ensure that the email routing infrastructure for .geek and .geek.ca is properly operating, *and* also accepts mail from geek.opennic.org, in case someone ends up routing through the “centralized” mail gateway using the opennic.org domain alias.

Alternatively, TXT records at each OpenNIC TLD level could be used to declare the parallel universe domain equivalents, so that any MX in the OpenNIC universe is able to rewrite to/from the OpenNIC TLD’s preferred parallel universe domain. The TXT records could then be downloaded and parsed into a simple domain rewrite table that can be used by any MTA in the OpenNIC universe.

On to S/MIME... The parallel universe mail gateway domain/operator
might also operate the CA that handles the S/MIME certs for this purpose. Each S/MIME cert would need to be issued for both emails: the ICANN version and the OpenNIC version. I believe S/MIME certs support multiple email addresses on one cert. The ICANN domain could be auto-generated and added on to the cert automatically upon cert request/renewal.

Note: this is where the centralized “opennic.org” email alias will likely fail, as it would necessitate all “custom” ICANN domain operators to also be able to issue .opennic.org S/MIME certs, or, it would require complete centralization of S/MIME cert issuance... neither scenario is ideal...

The other caveat is that we may need to stick to older versions of the S/MIME protocol that do not encrypt/sign message headers. I’m not even sure if that would work at all... but would imagine that there are legitimate scenarios where such email domain rewriting would be legitimately needed (eg. an internal corporate intranet with its own internal mail system that interfaces with the Internet). This discussion may be of interest:

https://stackoverflow.com/questions/60380150/encrypting-headers-s-mime-message-rfc822

It talks about newer S/MIME standards and how to encapsulate certain headers vs. exclude them from the encrypted/signed payload. Alas, we may be at the mercy of the individual end-users’ email clients on this one.

The interesting idea behind S/MIME is that it could be like a makeshift WebOfTrust: in that as people send each other emails, they can use their own self-signed S/MIME certs and choose their own methods of cert verification and acceptance/rejection. That kind of manual “call me up and double check each other’s cert hashes over the phone” PGP-style verification isn’t really a consequence of trying to get email to work on OpenNIC domains.

On the other hand, signing S/MIME certs with dual-universe domains (I’m really starting to like the parallel universe analogy! :)) with a trusted intermediate cert (preferably an intermediate specifically provisioned for S/MIME cert issuance), signed by a common root CA (or one of few) that most can agree on to trust, is one way to handle the web of trust issues.

What do you think?

Rouben

On Fri, May 29, 2020 at 07:34 Erich Eckner <opennic AT eckner.net> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I put the current status (as perceived by me) of the setup and discussion
on https://wiki.opennic.org/opennic/tls

Feel free to contribute by editing that page.

On Fri, 29 May 2020, Walter H. wrote:

> Hello Erich,
>
> On 29.05.2020 12:03, Erich Eckner wrote:
>> Hi Walter,
>>
>> On Fri, 29 May 2020, Walter H. wrote:
>>
>>> On 29.05.2020 09:20, Erich Eckner wrote:
>>>> On Fri, 29 May 2020, Walter H. wrote:
>>>>>>> how would you S/MIME sign an email using any OpenNIC domain as sender
>>>>>>> and not assuming that the recipient has installed anything 3rd party?
>>>>>>
>>>>>> Ah, you are talking about getting certificates to be *used* on opennic
>>>>>> domains for email? Then I misunderstood your first email, sry.
>>>>> no problem, but this should be the first step ..., before talking about
>>>>> SSL certificates on domains from a 'parallel universe' ...
>>>>
>>>> I don't see, why we need encryption/signing on a medium (email on opennic
>>>> tlds) that noone uses,
>>> for the explanation and reasons see below
>>>> because it cannot interact with the rest of the world,
>>>
>>> the same with all other things, welcome in the 'parallel universe' ;-)
>>
>> you missed my point: The parallel universe is no problem, if the user only
>> has to configure stuff, he/she controls (e.g. which dns resolver to use),
>> but not stuff, he/she does not control (his/her mail server's resolver).
>>
>>>
>>> what do you mean by automatic distribution mechnism?
>>
>> I expect to not show up somewhere in person to get my certificate (I guess,
>> the priceless CA does fulfill this requirement - my university did not).
>
> what you mean is something different; what is done at the validation process
> ..., and this depends on what must be validated, if its the identity at all,
> then you must send e.g. passport copy or show up in person but this is
> uncommon for this, then you will get a certificate with your name in the x509
> certificate subject; using such a certificate you not only show "this is my
> e-mail address", you also show, who you are;
>
> if its only the e-mail address than this goes nearly instant ..., but not as
> automatic as you know from Let's encrypt for SSL certificates; but automatic
> enough; with this you only show, whats your e-mail address and not who you
> are;
>
> by the way there is a similar difference with the SSL certificates; the sort
> that are given by Let's encrypt, only show the domain name; the ones that are
> used by e.g. banks show more;

ok, I see. I would not expect more than verifying email addresses and host
names from an opennic-CA - I do not expect any bank to seriously run on
opennic domains :-D

>
>> So let me ask you once more: How are S/MIME certificates being distributed
>> (e.g. from this CA which does it for free)? We could add this to our CA,
>> too. I see no problem with that.
> the same way as from CAs that are paid ..., there is no difference;
>> Also: I don't see, why that would be true. Why should TLS suddenly work if
>> S/MIME works?
> because then the 'parallel universe' is integratet and doesn't co exist any
> more and any problem is solved ...

ok, got it.

>>>> If it would be convenient (and still priceless), I would probably get an
>>>> S/MIME certificate, too.
>>>>
>>>> The "parallel universe" argument applies better to S/MIME than to TLS:
>>>
>>> not really, with TLS its the same;
>>
>> ok, maybe I misphrased that. What I meant, was, that the "parallel
>> universe" argument applies better to *email* than to *browsing* (and other
>> services, to which you connect directly: imap, ssh, ftp, ...).
>
> not really, only to services where the DNS names are nothing than smoke; for
> e.g. ssh this is true;
> it is wrong for both HTTP and HTTPS
>
> http://1.2.3.4/  and http://www.example.com/ give you different results, even
> then www.example.com resolves to 1.2.3.4 ...
>
> compare using OpenNIC DNS server with entering hostnames with their ip
> addresses to the local hosts file;
>
> using these resolvers is just a easier way of sharing own hosts file with
> others, nothing more ...

But "others" might include the provider of the service itself. Which is
IMHO pretty different from rsync'ing /etc/hosts files - it makes the name
kind of official.

>
>> I see your point, but you missed mine again: How do I tell my gmail
>> account, that it should happily send to help AT acme.libre?
>
> welcome again to the 'parallel universe'; it is just a few bytes in
> /etc/resolve.conf, isn't it?

Yes, but those are a few bytes which I cannot control :-)

>
>> This will never work (same "never" as above). However, it is trivial for me
>> to visit http://acme.libre.
>
> yes when modifying your hosts file or using other DNS resolvers; you wouldn't
> setup a website e.g
>
> www.bookshop.libre and expect the whole world using other DNS resolvers as
> they are used to, would you?
>
> I gues now you've the point with what is meant by 'parallel universe' ;-)
>
>>>>> I think it would be good to achieve it first on s/mime signing E-mails
>>>>> by official CA signed certificates;
>>>>
>>>> I think, this whole discussion about S/MIME certificates for opennic tlds
>>>> is purely academic, because literally noone uses opennic tlds for email.
>>>>
>>> not really, the way S/MIME works is just a little bit more individual;
>>>
>>> ...
>>
>> I don't really understand, what you want to say with that and what your
>> suggestion is for the roadmap.
> in other words, not every real problem is solveable by some digital work; and
> not every digital solutuion is useable at all;
>>
>> How would we step from S/MIME certificates of opennic domains to TLS
>> certificates of opennic domains ...
> there is no difference; think a little bit of evolution; long before http was
> invented, e-mail was working; so it is here, too;
>> To me, it sounds, like you would like to wait for the far-away (my opinion)
>> milestone of being able to send/receive email from/to opennic tlds to/from
>> the rest of the world, then get officially validated S/MIME certificates
>> for these and somehow get officially validated TLS certificates this way.
> this is correct;
>> Do you honestly expect, that at some point, gmail, letsencrypt and other
>> "big players" will resolve opennic tlds?
>
> No, I'd rather expect that these OpenNIC TLDs would be TLDs of IANA/IETF/...,
> which would then make OpenNIC obsolete; just ask yourself: "why isn't there
> any quite short TLD, that is really for free?"
>
> e.g. the TLD .free
>
> and is operated with rules that nobody can register multiple domains at once;
>
> even the TLD .name is paid;

ok, if this (e.g. wait for opennic tlds to be included in icann) is the
proposed roadmap, then I prefer running our own acme server. :-D

>> Do you really want to wait until then with pushing forward TLS certificates
>> on opennic domains?
>
> that's like waiting for Garfield become real ;-)

exactly.

> Walter
>
> p.s. might it be possible that you your mother-tongue is the same as mine
> (German)?

Indeed, it is.

regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7Q8zgACgkQCu7JB1Xa
e1pmqBAAupKQviBAjLJOG63yupZv9NAbXN0e37+VQkWFw770dUgMt34hSzC+tC6R
UF9C0JjsaMXD355fbFSPix7Fy0kwyEhaBo+gySpQI3kePPbVH+ER59NCWvi74DT3
2YwrC3MFTvg1Mb7GVvr2JpnChf2GwEGvayWu4q+3FuNvMmkYcO+NCpSYbATeWd1X
06Ra6D633PxqidpbNG8PYVskH8ijil6FJ5dwgsbJCwxvOv/05rFwlbMV2raAbd4Y
zyztemwDzC60T7oezRrcmQMN+wYKLVJuUsyM3YnXJXRVbkfg46v/P9EKr25mU+EH
XCNKeLoIAf3zxVr3ipUHZhhEVgrjlGQt54IFQdyvYhOyzX9VSmRxgg7EJwtHgtnu
+6+tA6tE2HwR0m4LizEPrXjnx7wgXvtDsRGr7qOVoAfxI6mJbB3BWagct/F3p4E5
ZVgBDO6KbSFfp5eUl/YyvgTtTHRzKwA1JT4g1EdvetjvMCS1Imy2/oWHkosAX8NB
CKf+ZfSy0VTqfABbt7y6h6pMiHUf+rSz6R7AZ+bH3k6LJA4p5Vdc09QW6b43TcUl
P76vYd3B7p72wbohgmyrEL0pjDhX4WAkX9qaTjTBGXPFJ9TGx6SLTMMWTS67+U81
dBD259cqpUSpI8YqpgWXWf0HutnwDC8Tdzu7jf5Ru75wOWq/ySU=
=KYQ6
-----END PGP SIGNATURE-----

--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org

--

Rouben