DNS NAPTR records are used to allow a client to discover that the
server supports TLS. An attacker could potentially modify these
records, resulting in a client using a non-secure transport when TLS
is in fact available and preferred.
This is partially mitigated by the presence of the sips URI scheme,
which is always sent only over TLS. An attacker cannot force a bid
down through deletion or modification of DNS records. In the worst
case, they can prevent communication from occurring by deleting all
records. A sips URI itself is generally exchanged within a secure
context, frequently on a business card or secure web page, or within
a SIP message which has already been secured with TLS. See RFC 3261prop
[1] for details. The sips URI is therefore preferred when security
is truly needed, but we allow TLS to be used for requests resolved by
a SIP URI to allow security that is better than no TLS at all.
The bid down attack can also be mitigated through caching. A client
which frequently contacts the same domain SHOULD cache whether or not
its NAPTR records contain SIPS in the services field. If such
records were present, but in later queries cease to appear, it is a
sign of a potential attack. In this case, the client SHOULD generate
some kind of alert or alarm, and MAY reject the request.
An additional problem is that proxies, which are intermediaries
between the users of the system, are frequently the clients that
perform the NAPTR queries. It is therefore possible for a proxy to
ignore SIPS entries even though they are present, resulting in
downgraded security. There is very little that can be done to
prevent such attacks. Clients are simply dependent on proxy servers
for call completion, and must trust that they implement the protocol
properly in order for security to be provided. Falsifying DNS
records can be done by tampering with wire traffic (in the absence of
DNSSEC), whereas compromising and commandeering a proxy server
requires a break-in, and is seen as the considerably less likely
downgrade threat.
