MSC1708: .well-known support for server name resolution

[richvdh]

Rendered

[richvdh]

Thanks for the quick feedback @turt2live !

[jcgruenhage]

A note on all the let's look what the rest of the world is doing: Apparently the IETF has decided that DNSSEC+DANE is not enough for SMTP, so they created MTA-MTS, which is basically the same as this proposal, getting trust from .well-known.

Source: https://datatracker.ietf.org/doc/rfc8461/

[jcgruenhage]

Since #1711 is very important and this spec change is considered a pre-requisite for it, I'll try to move forward here: I'd be in favour of matrix-sts (matrix-strict transport security), instead of this PR, based on RFC8461. The goal would not be to move the delegation out of DNS to .well-known, but to confirm it via .well-known. Does that sound like an okay option?

[richvdh]

@jcgruenhage it's certainly something worth considering. I'd need to be convinced it actually represents a material improvement over what's suggested here. I haven't been yet, and my questions would depend on how exactly you envision it working...

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[rektide]

This spec violates RFC5785 Defining Well-Known Uniform Resource Identifiers (URIs) by claiming direct use of the /.well-known uri.

According to rfc5785,

A well-known URI is a URI [RFC3986] whose path component begins with
the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
or another scheme that has explicitly been specified to use well-
known URIs.

Applications that wish to mint new well-known URIs MUST register
them, following the procedures in Section 5.1.

For example, if an application registers the name 'example', the
corresponding well-known URI on 'http://www.example.com/' would be
'http://www.example.com/.well-known/example'.

This specification should be updated to conform to acceptable use of the .well-known resource space defined by RFC5785. Instead of trying to serve Matrix's json document on /.well-known, it could perhaps instead serve on /.well-known/matrix, for example.

RFC5785 goes as far as to directly contradict the behavior MSC1708 opted for, in directly using /.well-known:

Note that this specification does not define a format or media-type
for the resource located at "/.well-known/" and clients should not
expect a resource to exist at that location.

There should be no resource available on /.well-known.

Please update this specification to more respectfully cooperate & interoperate with other well-known resources a server might have. Claiming the /.well-known resource prevents this cleanly operation with others.

/cc @richvdh

[ara4n]

@rektide i’m failing to follow. this MSC only specs behaviour for the https://<server_name>/.well-known/matrix/server path?

[jcgruenhage]

afaict, the first point is valid, that document specifies that someone from the spec core team should write an email to those people over at IETF to get their approval. It is unfortunate that this concern has only been brought forward after this proposal has only landed in production though.

[rektide]

My apologies all. @ara4n is right. I mis-read these changes. this line backs up what @ara4n is saying, that this is for a /.well-known/matrix/server resource. The references to the .well-known resource in the specification threw me off a bit; I mistakenly thought /.well-known was the resource: this is not the case. Thanks all for the help & correction.

It would be good to get this particular well-known resource registered with IANA. 🤞

[ara4n]

np. have filed a bug at #1914 for that IANA dance.

[richvdh]

For links: the order of SRV and .well-known lookups were changed by MSC1831.