Drop DNS-based discovery (and vanity addresses)

[michielbdejong]

As discussed in Thursday's weekly call, I think that vanity OCM addresses are a nice-to-have if people put their vanity OCM address on their business card, memorise it, transmit it verbally, and enter it into a GUI by hand.

But despite this appeal, it also has a number of downsides:

• due to the nature of SRV records, it can only point to a server and a port, so there the discovery process still requires a file hosted on /.well-known/ocm or on /ocm-provider. It makes it easier for enterprise devops team who don't want to edit the paths of their main domain, but it still requires the EFSS to host the discovery document in those two places. That's why it's not an alternative discovery mechanism but just an additional first step, after which the .well-known discovery mechanism still works as usual. Therefore, SRV records do not replace .well-known documents; all they can do is change a [email protected] address to a shorter ("vanity") [email protected] address.
• it only works if the receiving server offers it AND the sending server is able to query it
• current landscape is 0% of potential sending OCM servers out there support it
• before a receiving user can confidently put their vanity OCM address on their business card, if they don't want cause more than 1% errors, they would have to wait for the servers of 99% of their coworkers to support SRV record discovery. So we would have to add the requirement to the spec now, then wait a long time probably (maybe 10 years?) before 99% of OCM servers out there support it, and then it would start paying off. This feels like a huge investment. It might be faster in smaller closed networks such as ScienceMesh, but there it's not useful (see below)
• vanity OCM addresses will still in some use cases have a long and not-memorable user-id part. For instance in the design of ScienceMesh, the part before the @ sign is called 'opaque id', and what is the use of being able to say your OCM address is 94aa328533a01084c40c0a6034fc899dba80b3334b85572fc048074004fc8f60@cern.ch? Then the advantage of vanity addresses is gone, and you might as well say it's 94aa328533a01084c40c0a6034fc899dba80b3334b85572fc048074004fc8f60@cernbox.cern.ch.
• The main two downsides of vanity addresses are probably the following. We have seen the immense security improvements we can make with invites. An invite flow ensures that both the sending server and the receiving server are "real" EFSS servers on which either the sending or the receiving server logged in (therefore pledging their trust) to either generate or redeem an invite. So we want users to share Invite Messages and NOT OCM addresses in their out-of-band contact messages. In the invite flow, the users never see their OCM address or that of their contact, so having vanity addresses is at best useless there, and maybe even a distraction, foot-gun or anti-pattern.
• We have limited energy, both within the OCM project itself and at vendors who we need to ask to implement spec changes and we want to spend it wisely. If we ask vendors now to implement a DNS query module, and then the next month we ask them to implement invites, we will have used up our ammunition and we risk them saying no to the second request.

We roughly agreed to this in Thursday's weekly meeting, but I would like to get a review from @labkode since the SRV lookup was sort of his "baby", and he may have some arguments for us to reconsider.

[labkode]

Hi @michielbdejong,

I think you got a very bad interpretation of what I presented about the use of SRV records in the last CS3 conference,, I never mentioned “vanity address” and to be honest, I don't know what that means from your comment above.

For the record, what I presented is available here and is very much self-explanatory:
https://indico.cern.ch/event/1332413/contributions/5749456/attachments/2817731/4919651/ocm-dns.pdf

Most (all?) companies will have email address that are human readable and rememberable, usually employees names, not something like 4aa328533a01084c40c0a6034fc899dba80b3334b85572fc048074004fc8f60@cern.ch

My presentation about using SRVs was related exclusively to use email addresses to identify users in remote EFSS.
The rationale behind is that most people will use email as their digital handle, usually that is what you write in your business card as well.

For example:
[email protected] is my mail address
My EFSS lives in cernbox.cern.ch
[email protected] simply does not exist (is that what you call vanity address?)

When typing in the share menu of ownCloud/nextCloud, you just type the email address of the person in the business card. Then, the The EFSS checks the SRV record of the hostname encoded in the mail (@cern.ch), finds the OCM endpoint and sends the invite.

To avoid the use of ./well-known, TXT records can be used, which can encode arbitrary data, like the OCM endpoint from the /.well-known

I hope this shed more light on my idea about using SRVs, happy to have a chat.

cheers

[michielbdejong]

To avoid the use of ./well-known, TXT records can be used

Right! That would be a better system then, yes. So let's agree then to drop the current phrase (as it still requires a /.well-known and is not what @labkode originally intended), and then we can create a new PR to propose DNS TXT-based discovery

[glpatcern]

For @labkode, a "Vanity Address" is just a normal email address, say [email protected] (am I right here? this is how I understood it so far!), which an EFSS does not know - where the whole point of bridging the gap between cern.ch and e.g. cernbox.cern.ch.

So on one side, I understand that with the improvements in the Invite flow we may just not need any DNS-based discovery. On the other hand, if we keep it, we'd need TXT records rather than SRV records. Is that right?

If so, there are a few other references to SRV records that ought to be removed/amended on top of this change. And if we eventually decide to keep DNS-based discovery, then let's have a single PR with SRV records replaced by TXT records?

[michielbdejong]

OK let's discuss it again in today's meeting!

[michielbdejong]

Discussed in the meeting today, we agreed that indeed if we want DNS-based discovery then a TXT record to a URL path would make most sense.

But also: we're trying to make the spec as graceful as possible, and due to its nature, discovery is an all-or-nothing mechanism, so we should either drop it or make it mandatory. Keeping it as optional doesn't make much sense.

[michielbdejong]

Is anybody in favour of making it mandatory (that means both new implementations need to support it, and existing deployments will need to be forced to upgrade)? If not, then let's drop it and focus on invites?

[michielbdejong]

We voted Micke, Mahdi and me in favour of dropping it, and Giuseppe abstaining from the vote, but is OK with dropping it now, as long as we drop all mentions of DNS, and keep an issue open about it, so that we may add it back if we ever do a 2.0 version of OCM that is incompatible anyway with existing deployments.

[michielbdejong]

Hm. there is a merge conflict, I'll merge develop into it

[mickenordin]

As per the discussion this afternoon

[glpatcern]

As per discussion, and let's not forget to create an issue to track this as an interesting future feature