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 all commits
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
47 changes: 47 additions & 0 deletions extensions/dns-srv.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
title: DNS SRV records
layout: spec
copyrights:
-
name: "Simon Ser"
period: "2021"
email: "[email protected]"
---

## Introduction

IRC servers typically use a sub-domain so that IRC connections can be routed
separately from the rest of the services. For instance, an IRC network using
the domain name `example.org` may ask its users to connect to `irc.example.org`
and use DNS load balancing to spread incoming connections to multiple servers.

Unfortunately, this means that users need to make sure to connect to
`irc.example.org` instead of `example.org` as the latter won't accept IRC
connections.

Additionally, other connection details such as the port and TLS usage might
differ from one network to another.

Other services (e.g. IMAP, SMTP) have standardized DNS SRV records which can be
used to discover connection details. This specification defines DNS SRV records
for IRC.

SRV records are defined in [RFC 2782].

## Description

IRC networks conforming to this specification MUST publish an SRV record with
the "ircs" service label. The record identifies an IRC server where TLS is
initiated directly upon connection to the server.

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