Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DNS SRV records #483

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Add DNS SRV records #483

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
67a6720
Add DNS SRV records
emersion Dec 10, 2021
d529650
Require certs to be valid for original hostname
emersion Dec 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions extensions/dns-srv.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,10 @@ Example:

_ircs._tcp SRV 0 1 6697 irc.example.org.
Copy link

@lanodan lanodan Dec 29, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The record should be explicitly be for example.org, I think it would be better for the TLS explanation below.

Suggested change
_ircs._tcp SRV 0 1 6697 irc.example.org.
_ircs._tcp.example.org. SRV 0 1 6697 irc.example.org.


After discovering an IRC server via SRV records, the client MUST check that the
TLS server certificate is valid for the original hostname (`example.org` in the
example above).
Comment on lines +41 to +43
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not very practical when example.org hosts other services than the IRC network. If the private certificate of IRC server is leaked, TLS communications of other services are compromised as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the concern here. Is the claim that IRC servers have a larger attack surface for compromises than, say, the HTTP servers or load balancers that would normally serve a certificate covering example.org?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, attack surface of IRC server is much larger than of reverse proxy HTTP server.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree, but an operator who felt this way could put a TLS-terminating reverse proxy in front of their IRC server. (For example, nginx supports this with the stream directive.)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could indeed be a good solution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not very practical when example.org hosts other services than the IRC network. If the private certificate of IRC server is leaked, TLS communications of other services are compromised as well.

As explained above; if you do not enforce that the certificate is valid for the original hostname (the one the client looked up), then a trivial DNS MITM is possible, to direct the client to a hostname of the attacker's choosing, defeating the entire point of using TLS.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not very practical when example.org hosts other services than the IRC network.

It seems to be practical enough for XMPP server operators. XMPP also requires the certificate to validate against the domain from JID, not against the SRV target.

Copy link
Contributor

@kylef kylef Jan 3, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just throwing an idea up there (haven't given it much thought). Could the TLS hostname validation use the SRV hostname instead (for exampole _ircs._tcp.example.org). That way we would be restricting the certificate for only use with the irc service and not any other service running in the example.org domain (where comprimise of cert could allow it to be used for other services in the root domain).

For clarity, I am proposing that _ircs._tcp.example.org would be in the TLS SAN. (not the value of the SRV record).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While you can't have underscores in dNSName, RFC 4985 exists as an alternative. Sadly, Baseline Requirements of CA/B Forum don't allow issuance of SRVName yet, but there is a discussion to allow them.


There is no defined service label for unencrypted connections.

[RFC 2782]: https://datatracker.ietf.org/doc/html/rfc2782