1. Stefan Santesson Microsoft
SRV RR otherName
Stefan Santesson
Microsoft

2. The Concept RFC 2782 DNS Server _service._protocol.domain.com
host1.domain.com
Service Host
(host1.domain.com)
( )
Using service
Client

3. The Concept
From RFC 2742
Currently, one must either know the exact address of a server
To contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a
Single domain, to move services from host to host with little
fuss, and to designate some hosts as primary servers for a
service and others as backups.
Clients ask for a specific service/protocol for a specific
domain and get back the names of any available servers.
Example is discovery of a Kerberos KDC host but this could be used as a general mechanism for a variety of services.

4. The Threat DNS spoofing
Spoofed
DNS Server
_service._protocol.domain.com
_service._protocol.domain.com
hostX.domain.com
Hijacked Host
(hostX.domain.com)
( )
Using service
Client

5. Proposal Submitted as draft-santesson-pkix-srvrr-00.txt
Define a Subject Alt Name otherName for SRV RR query string (_service._protocol.domain).
Example: _ldap._tcp.example.com
otherName structure:
id-on-sRVRRName OBJECT IDENTIFIER ::= { id-on ? }
SRVRRName ::= UTF8String

6. Applicability Constraints
From RFC 2782: I
In general, it is expected that SRV records will be used by clients
for applications where the relevant protocol specification indicates
that clients should use the SRV record. Such specification MUST
define the symbolic name to be used in the Service field of the SRV
record as described below. It also MUST include security
considerations. Service SRV records SHOULD NOT be used in the absence
of such specification.
Any use of SRV RR for host authentication MUST NOT be in conflict with any rules specified for deployed security protocols and application/service definitions.

7. Request
Request that PKIX accept the task to define this SAN otherName so it can be referenced and used by other protocol specifications to support host authentication where applicable.

8. Path forward Correct known errors (IA5String -> UTF8String)
Submit as first pkix draft (00)
Define appropriate constraints and security considerations
Proceed as standards track
WG last call after Vancouver IETF