Subject: [pkix] RFC 6125, Server Identity Check and insecure DNS lookup

From: Jeffrey Walton <[email-masked]>
Date: Sun, 1 Feb 2015 22:05:26 -0500

What does RFC 6125 mean when they say the following:

   2.4.  Server Identity Check

   o  The client MUST use the server hostname it used to open the
      connection as the value to compare against the server name as
      expressed in the server certificate.  The client MUST NOT use any
      form of the server hostname derived from an insecure remote source
      (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

Is this saying that all DNS is considered insecure, and only the
original hostname used by the client should be used for validation?

Or is it saying its OK to follow the CNAME aliases when using a
"secure" DNS, like DNSSEC?

Or is it saying something else?

---

From: [email-masked] (Martin Rex)
Date: Mon, 2 Feb 2015 13:34:54 +0100 (CET)

> "secure" DNS, like DNSSEC?

The difference here is "lack of trust" in the data contained in DNS.

The two characteristics that DNSSEC provides (according to its own
specification) is data origin authentication and data integrity protection.
But using DNSSEC does not increase the trustworthyness of the data
conveyed through DNS.

Similarily using HTTPS rather than HTTP for searching Google will provide 
only data origin authentication and data integrity protection for the
search results, but will not increase the trustworthyness of the
search results (there is no trust).

-Martin

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 21 Feb 2015 17:17:57 -0500

Thanks Martin.

> But using DNSSEC does not increase the trustworthyness of the data

Isn't this the equivalent problem issuing certificates via domain
validation from the WHOIS database? That is, the data can be sent
securely (for some definition of secure), but we're not sure the data
itself is accurate?

If they are equivalent, then why do we accept certificates based on
domain validation from the WHOIS database?

It seems to me both should be accepted, or both should be rejected.

Jeff