[cabfpub] Proposed new ballot on IP Addresses in SANs

[Ryan Sleevi]

On Thu, Apr 21, 2016 at 7:07 AM, Peter Bowen <pzb at amzn.com> wrote:

> 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.
>

I'm afraid you've misunderstood my concern. An implementation on the client
that enforces RFC5280 here will rightfully reject such certificates, as the
labels to not conform to the LDH rule - that is, a domain name constructed
entirely of numbers is an invalid hostname, the dNSName field should only
contain valid hostnames, and such are rejected.


> 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).
>

You're right, in that I improperly specified the concern. The underlying
security risk, however, still applies - a certificate with an iPAddress
nameConstraint, but without a dNSName constraint (thus admittedly not
meeting the definition of a technically constrained sub-CA, but still being
constrained), will still be able to produce certificates which evade that
technical control and violate RFC5280.

That is, a sub-CA with a scope of
permittedSubtrees:
  IP:192.168.0.1/0.0.0.0

Will be able to issue a certificate with
commonName:8.8.8.8
subjectAltName:
  dNSName:8.8.8.8

According to the ballot as proposed. Under the existing BRs, the
certificate would have to be constructed as such:
commonName:8.8.8.8
subjectAltName:
  iPAddress:8.8.8.8

Under the current form, the iPAddress subjectAltName will be properly
constrained to the nameConstraints of the issuing CA, as per RFC 5280.
Under the proposed form, the absence of the iPAddress subjectAltName means
that the permittedSubtrees of the sub-CA is ignored; a client that then
does a textual match against the commonName (e.g. as the majority do) will
now improperly accept it as valid according to RFC 5280, despite violating
the expressed policies. Applications would need to be updated to apply
additional checks, outside of RFC5280 (and thus difficult to implement in
common validation libraries that conform to RFC5280), to ensure that before
they accept such a commonName, they constrain it to the iPAddress
permittedSubtrees (if it's "IP shaped").

The key difference here is that such a 'hostile' certificate would be fully
conforming to the BRs, as presently worded (although I'd appreciate if I
missed something). While one might argue that such a policy is good for
defense in depth (e.g. avoiding BR-violating certs), it's difficult to
argue intentionally introducing this vulnerability.

One might change the proposal, to require that if an IP is present in the
dNSName SAN, then it MUST ALSO be present in an iPAddress SAN. That is, a
BR conforming cert would have to encode as:

commonName:8.8.8.8
subjectAltName:
  dNSName:8.8.8.8
  iPAddress:8.8.8.8

There, a conforming RFC5280 compliant implementation will properly reject
the certificate as violating the name constraints. While an 'evil subCA'
could issue a certificate

commonName:8.8.8.8
[subjectAltName omitted]

Which would trigger the evasion behaviour described above, such a
certificate is "clearly" non-conforming to the BRs.

And of course, there's no guarantee that the solution I proposed above -
one to protect users - would actually be deployable in practice and not
trigger bugs in other clients. Which is why the idea of "let's just violate
the BRs" is so deeply discouragingly problematic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160421/0b78ca10/attachment-0003.html>