Subject: [pkix] Please clarify when and where wildcards should be matched in PKIX certificates

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 01:55:12 -0400

This issue came up on the DBOUND list.

Relevant RFCs like 5280 and 6125, allow wildcards and don't restrict
them. Some folks have taken the lack of restriction to allow matching
of *.COM, *.NET and *.ORG. It seems like a logical leap since there is
no restriction placed on them (or even '*' or '*.*').

When questioned, they state the RFCs don't prohibit them. See, for
example, "Overly permissive hostname matching" for Wget and GnuTLS
(https://lists.gnu.org/archive/html/bug-wget/2014-03/msg00093.html and
https://lists.gnupg.org/pipermail/gnutls-devel/2014-March/006833.html).
>From the GnuTLS reply:

    That's a very interesting point, but I am not sure there is an easy
    fix. GnuTLS follows RFC2818 for hostname verification, and that
    document is pretty clear on the scope of the wildcards. It mentions
    for example: "f*.com matches foo.com". Maybe we can forbid a first
    level wildcard, but is that practice documented somewhere? I don't see
    any IETF documents updating RFC2818.

The list is actually larger than those two projects, and includes
others, like Ruby, Java, .Net, Cocoa/CocoaTouch and PERL. Its quite an
impressive list of offenders. Some offenders, like Ruby, have fixed
their validators
(https://www.ruby-lang.org/en/news/2015/04/13/ruby-openssl-hostname-matching-vulnerability/).
Others have not.

In case its not obvious, no one organization or entity controls some
of the gTLDs, like *.COM, *.NET and *.ORG. It makes no sense to allow
a match on them in a CN or SAN.

The CA/Browser Forums, Baseline Requirements document does not allow
them under Section 3.2.2. But the CA/B is a different set of issuing
policies, and IETF conforming implementations don't use the CA/B.

Please address this issue in the RFCs.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 03:45:44 -0400

Below is the current language (thanks TS). It clearly allows matching
*.COM if the wildcard is in the leftmost label.

And it may allow match just "*", if that is interpreted as the
leftmost label (but not the center label or rightmost label). Stranger
things have happened....

Jeff

(6.4.3. Checking of Wildcard Certificates)

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].

---

From: Tomoyuki Sahara <[email-masked]>
Date: Fri, 5 Jun 2015 18:28:43 +0900

> leftmost label (but not the center label or rightmost label). Stranger

A site in Alexa top 10,000 presents such a certificate (but the cerfiticate
is self-singed so it should be site administrator's mistake).

Fortunately, Mozilla and libressl won't match such wildcards to any domain
because they checks if presented identifier in server's certificate has at
least 2 dots (".").

But the "two-dots" check is far from perfect:

- A number of ccTLDs have more levels (e.g. www.example.co.jp)
- It prevents new gTLDs from using wildcard certificates like "*.gtld".

It can be more strict with Public Suffix List in theory but I don't think
it is a good idea in practice.

Any ideas?

Thanks,
Tomoyuki

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 06:42:49 -0400

> it is a good idea in practice.

Tough problem in general.

(1) At the second label (with the leftmost as a wildcard), there are
three top levels to consider.

    (A) Traditional Top Level Domains (call them gTLDs). *.COM, *.NET, *.MIL,etc
    (B) Country Top Level Domains (call them ccTLDs). *.UK, *.CN, etc
    (C) Vanity Top level Domains (call them vTLDS). *.GOOLGE and friends

We can remediate (A) because its an exhaustive list. We just say NO.

We can remediate (B) because its an exhaustive list of about 250, and
we can build a list of the authorities offline. In the absence of a
declared authority or delegate, we just say NO.

I think (A) and (B) could (and should) be called out in PKIX
validation because validation is within purview of PKIX and the rules
are obvious.

I don't know how to remediate (C). How do we say, *.GOOGLE is OK if
its certified by Google but not others? When we encounter *.GOOGLE
that claims to be certified by Google, how do we know its authentic?

For (C), the RFC should document the risk in Security Considerations
(if it has no remediations or rules for validation).

(2) Other labels

DBOUND is trying to work out the details of (2) and (1)(C). They may
be trying to work out the details of (1)(A) and (1)(B), too.

We need the rules now, so there's probably no reason to wait for
DBOUND to deliver something. Plus, there's no guarantees DBOUND will
be delivering anything useful for any of these case (including (1)(A)
and (1)(B)). Finally, we already have some rules in RFC 6125, so
validation is within purview of PKIX.

Jeff

---

From: Tom Ritter <[email-masked]>
Date: Fri, 5 Jun 2015 05:09:26 -0700

> that claims to be certified by Google, how do we know its authentic?

Technically, we don't need to remediate (C), because we're trying to
support a use case no one has asked for. Or at least, not seriously.
No vanity TLD has come to Mozilla or Chrome or Microsoft and said
"Hey, we want to do *.vanity, but it doesn't work!"[0]  Just as
dotless vanity domains (http://vanity) aren't going to work[1], we can
say that TLD wildcards aren't going to work.

-tom

[0] Right?
[1] Right? That's decided, no?

---

From: "Mehner, Carl" <[email-masked]>
Date: Fri, 5 Jun 2015 15:04:03 +0000

> say that TLD wildcards aren't going to work.
Actually, Google has, and it does work (for some domains). However, Firefox broke on any host secured by a cert with a DNSNames that included "*.google" in the SAN.
https://bugzilla.mozilla.org/show_bug.cgi?id=1169149

Another relevant discussion here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1128673

> [1] Right? That's decided, no?
Right, ICANN has forbidden A records at the top level

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 5 Jun 2015 11:15:48 -0700

>  no restriction placed on them (or even '*' or '*.*').

This is not correct. RFC 5280 does not say anything about name matching
for things like wildcards, other than to explicitly and clearly state that
it does not say anything about name matching for wildcards.

4.2.1.6.  Subject Alternative Name
    Finally, the semantics of subject alternative names that include
    wildcard characters (e.g., as a placeholder for a set of names) are
    not addressed by this specification.  Applications with specific
    requirements MAY use such names, but they must define the semantics.

That's left up to application-level protocols and follow
application-specific rules. This is why you have different rules - RFC
6125 also makes this abundantly clear in Appendix B. Prior Art.

>  a match on them in a CN or SAN.

Except for Brand TLDs ( http://icannwiki.com/Brand_TLD , which you call
Vanity TLDs but which actually have a term for them already in extensive
use) or ccTLDs.

>  policies, and IETF conforming implementations don't use the CA/B.

This is also not correct.

>From 3.2.2.6 of BRs 1.3.0

"If a wildcard would fall within the label immediately to the left of a
registry&#8208;controlled† or public suffix, CAs MUST refuse issuance
unless the applicant proves its rightful control of the entire Domain
Namespace."

Note the "unless". It's entirely valid to issue a wildcard, at any label
level, provided the CA establishes the applicant is authorized. For
example, a Brand TLD can demonstrate control over a domain namespace by
1) Establishing they are the applicant to the CA
2) Providing their Registry Agreement with ICANN that details their
registration policies for said brand TLD (such as whether or not they
allow public registration)

As it stands, the Baseline Requirements are a profile of RFC 5280 for CAs
that are publicly trusted. While 5280 describes a kitchen sink of
features, many of which see limited use outside of the US Government's
PKI, the BRs exist to profile that into a set of policies that can be
securely reasoned about.

You're correct that IETF conforming implementations don't refer to the
CA/Browser Forum, but that's because the IETF isn't in the business of
specifying policy, and that's what this is. Policy.

>  Please address this issue in the RFCs.

The encoding of such, and the application matching of such, is already
documented. The policies regarding issuance and client acceptance are
matters of policy (issuance and local, respectively), and have
questionable to negligible value.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 5 Jun 2015 11:28:48 -0700

>      (C) Vanity Top level Domains (call them vTLDS). *.GOOLGE and friends

These are called Brand TLDs.

>  We can remediate (A) because its an exhaustive list. We just say NO.

Except it isn't an exhaustive list by any means, it is fluid. And you've
incorrectly lumped ".mil" in here, which is handled by the DoD Network
Information Center. .mil is a sponsored TLD fully operated by DISA/DOD
NIC, and as such, it's entirely reasonable for the DoD root CAs (which are
trusted as a matter of local policy by DoD machines, although not widely
trusted publicly) to issue *.mil, should they so wish.

>  validation because validation is within purview of PKIX and the rules

The rules aren't obvious for a second. They change and have changed over
time.

>  validation is within purview of PKIX.

That's specious logic. What you're describing is application trust policy
- "How do we determine X is authorized to say Y?" - and that's dependent
on local trust policies and configurations.

A locally installed trust anchor (which I know you're on record as being
opposed to) could totally determine that they're duly authorized to issue
for *.whatevertheywant, because that's what local policy means.

This isn't academic or theoretical - this is actively in use by
deployments today. No amount of handwringing here will fundamentally
change that.

If there is going to be something to express policy-by-default, and that
policy-by-default isn't expressed via the present Public Suffix List
(which I wouldn't advocate for a second standardizing upon as a MUST; at
best, a MAY), then it will presumably be through the activities of DBOUND.
So yes, waiting for DBOUND, and then waiting to see reception from actual
application software vendors from DBOUND, is an entirely reasonable step.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 5 Jun 2015 15:18:30 -0400

> These are called Brand TLDs.

Thanks Ryan. I was not aware they were already coined with Brand. What
I followed came from some ICANN reading, and they were referred to as
Top Level Domains in those documents.

> deployments today. No amount of handwringing here will fundamentally

OK, to be clear... the result of inaction is going to result in more
CVEs, like CVE-2015-1855.

Where the rubber meets the road, we have problems in practice. The
problems in practice point back to lack of clear direction.

Jeff

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 5 Jun 2015 14:24:27 -0700

>  problems in practice point back to lack of clear direction.

No, this isn't correct.

CVE-2015-1855 has nothing to do with the domain boundary issue. It's all t
do with behaviours documented already in 6125.

The handling of domain boundaries is one of those "defense in depth"
things that depends on your application space and your threat model. In
the event it's "publicly trusted CAs" (e.g. the now shuttered WebPKI
group), then adding a check for "not wildcard TLD" is a defense against a
CA improperly implementing the Baseline Requirements. However, it's a
defense with tradeoffs - as noted on the Bugzilla discussions pointed to
elsewhere, we don't even have a solution for browsers yet.

Other elements of CVE-2015-1855 - things like "Don't allow wildcards for
IDNA", are treated by 6125 but weren't treated by 2616 because it wasn't
even a consideration for 2616.

Further still, elements of CVE-2015-1855 such as "Only allow one wildcard
label" are a judgement decision based on what type of certificates such a
client will expect to see. In the Web PKI, you should only ever see one
wildcard, and thus it's a sensible defense in depth check to add. However,
for internal CAs, it's not at all uncommon - I know, because I got yelled
at by users when I broke them by ensuring Chrome enforced the
one-wildcard-label rule. Even Google was serving some public
"*.*.domain.com" certificates (prior to the BRs notes about wildcard),
because "it just worked".

So I do want to stress that there's an element of policy in place here.
2616 defined how to match, but not what was acceptable. 5280 didn't
describe what was acceptable, because that's a matter of policy. The CA/B
Forum's Baseline Requirements detail what is acceptable, but _only_ in the
case of publicly trusted CA certificates used for TLS (implicitly and
primarily HTTPS, but not exclusively)

Disconnects like the one in Ruby come from when an implementation deals
with the technical aspect, but without touching upon the policy aspect for
the problem space. The IETF can't and doesn't know all the potential
policies that deployments may have - but tries to leave the right hooks
for policies to apply. The other thing to note is that policies change
over time, and sometimes rapidly so - for example, the CA/B Forum allowing
wildcards in EV certs iff that cert is for a .onion domain (and, for that
matter, allowing .onion domains as a temporary exception for CAs to
issue).

Finally, things like policy documents are somehow inherently
controversial. See the TLS BIS discussions. Or see the discussions of RFC
4158, which describes common algorithms that many implementations use in
satisfying the RFC 3280/5280 goals (although, notably, not Ruby or OpenSSL
:)

I don't think it's inherently wrong to put together something about "How
should publicly trusted certificates used for TLS" be validated by
clients, but I think it'd be a mistake to consider it normative
(implementations will/should do what's right for their users and security,
regardless of what a spec says), or permanent (threats change over time).
But sure, it could be helpful.

But I don't think that's what you want.

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 6 Jun 2015 19:25:57 -0400

>>> leftmost label (but not the center label or rightmost label). Stranger

The RFCs also appear to allow a match of the empty or null string (in
the absence of wild cards), which does not make a lot of sense to me
either.

The significance here is RFC 1034 defines the null or empty string to
be the top of the tree. I don't know what damage an attacker can cause
in some implementations by exploiting it.

So maybe matching the empty or null string should be addressed too.

I can imagine an implementation finding safe harbor in the same
argument provided GnuTLS: the RFCs don't prohibit it.

Jeff