[cabfpub] Proposed new ballot on IP Addresses in SANs

Peter Bowen pzb at amzn.com
Thu Apr 21 07:07:18 MST 2016


On Apr 21, 2016, at 6:41 AM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Thu, Apr 21, 2016 at 6:30 AM, Jody Cloutier <jodycl at microsoft.com> wrote:
> As a Forum member, Google is certainly within its purview to vote no, then. Let's put it to a vote and see where it comes down. 
> 
> 
> It is truly unfortunate to see you encouraging a vote on a practice with known and quantifiable interoperability and security risks.
> 
> Interoperability risks: This violates RFC5280. This penalizes implementations that properly implement RFC5280 - such as Mozilla Firefox, which enforces that a dNSName properly conforms to the RFCs (with a limited exception for certain characters for legacy reasons, despite being forbidden by the BRs). 
> 
> Security risks: Such addressing defeats the "Technically Constrained Sub-CA" provision of the BRs, allowing an issuing CA to bypass iPAddress nameConstraints for clients which do not enforce that the reference identifier (RFC 6125 terminology) is a domain. This is the majority of TLS clients out there, whose only protections are the explicit prohibitions of this behavior in the Baseline Requirements.
> 
> While I can appreciate the need and desire to support downlevel Windows clients, I offered a clear and concrete solution that avoids these risks entirely, while meeting that need. To suggest there is no interest in addressing these, or that such risks are unimportant - which is what a ballot would effectively be, based on the information presently provided - would be a step back for the Forum, and an unfortunate statement for the endorsers.


I think you are overstating the security and interoperability risks.  Based on data form CT logs, a very large number of different CA operators have issued current (unexpired) certificates  with IP addresses in the dNSName type (not just Symantec) and there have been no obvious interoperability problems.  As you so kindly pointed out in a message a few days ago, there is going to be no confusion between an IPv4 address presented as a dotted octet string and a public domain name.  

"The term "hostname" - that is, a domain name with an A label associated - has a defined format of "the LDH rule" - for Letter, Digit, Hyphen. While other DNS records exist (for example, SRV, TXT, and CAA), and those DNS records can have their own format rules (for example, SRV makes heavy use of a leading _ precisely because it avoids the ambiguity with A records), the A/AAAA notion of "hosts" has a specific format. The LDH rule of RFC 1034 was designed to avoid ambiguity with IP addresses - for example, it required a letter in the first label, so that you couldn't have a valid DNS name of "8.8.8.8" that resolved to "8.8.4.4", which would be ambiguous and give different results than "8.8.8.8" the IP address. RFC 1123 relaxed this rule, on the basis that there would never be a valid ".8" TLD, because the IANA registration of TLDs (since outsourced to ICANN with respect to gTLDs, although IANA maintains ultimate responsibility for the root zone) would never allow a purely numeric TLD (like .8).”

Due to this, the “technically constrained Sub-CA” (TCSA) risk you suggest does not exist.  According to the TCSA rules, the list of allowed names must be included in the permittedSubtree field (that is it is whitelisting names).  IP addresses in DNSName will not match the DNSName constraints, so it would be no different than a TCSA constrained to “example.com” issuing a certificate for “www.gmail.com”.  This will effectively mean that TCSAs will not be able to take advantage of this compatibility option (unless they happen to have authority over an old-style Class A, B, or C IP range).

I’m inclined to include support this change, and am open to including it the proposed Common & Alternative Name ballot, as long as:

1) The string representation of the IP address is clearly defined and only allowed in canonical format

2) IPv4 and IPv6 addresses are both defined and allowed

Thanks,
Peter





More information about the Public mailing list