Subject: [certid] open issue: wildcards in component fragments

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Oct 2010 15:48:44 -0600

I'm reading through the mailing list threads and working to identity the
remaining open issues. Jeff and I might post additional, focused
requests for feedback in the near future, so stay tuned. However, I
think that our working copy addresses nearly all the feedback that's
been posted during and after the IETF Last Call, so we plan to publish a
revised I-D as soon as possible.

This message covers the open issue of wildcard matching, specifically
matching of component fragments (e.g., foo*.example.com).

RFC 2818 states:

   Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Version -01 of draft-saintandre-tls-server-id-check (August 31, 2009)
had this text:

   A dNSName MAY contain the wildcard character '*' (ASCII 42).  The
   wildcard character applies only to the left-most (least significant)
   domain name component or component fragment and matches any single
   component or component fragment.  For instance, a dNSName of
   *.example.com matches foo.example.com but not bar.foo.example.com or
   example.com itself; similarly, a dNSName of baz*.example.net matches
   baz1.example.net and baz2.example.net but not qux.example.net or
   example.net itself.

Version -02 of draft-saintandre-tls-server-id-check (October 2, 2009)
had this modified text:

   Unless otherwise specified by an application protocol, the dNSName
   MAY contain one instance of the wildcard character '*'.  The wildcard
   character applies only to the left-most domain name component and
   matches any single component (thus a dNSName of *.example.com matches
   foo.example.com but not bar.foo.example.com or example.com itself).
   The wildcard character is not allowed in component fragments (thus a
   dNSName of baz*.example.net is not allowed and shall not be taken to
   match baz1.example.net and baz2.example.net).

And version -09 has similar text:

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier containing one instance of
   the wildcard character '*', but only as the left-most label of the
   domain name, e.g. *.example.com (following the definition of "label"
   from [DNS]).

   If such a wildcard identifier is presented, the wildcard MUST be used
   to match only the one position-wise corresponding label (thus
   *.example.com matches foo.example.com but not bar.foo.example.com or
   example.com).  The client MUST fail to match a presented identifier
   in which the wildcard character is contained within a label fragment
   (e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net), or in which the wildcard
   character does not comprise the left-most label in the presented
   identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net
   are allowed).

If I recall correctly, I added that the rule against matching of
component fragments in response to feedback from Alexey Melnikov, who
was reporting on discussion within the IESG, perhaps regarding
draft-ietf-sip-domain-certs (now RFC 5922), which states:

###

         Implementations MUST NOT match any form of wildcard, such as a
         leading "." or "*." with any other DNS label or sequence of
         labels.  For example, "*.example.com" matches only
         "*.example.com" but not "foo.example.com".  Similarly,
         ".example.com" matches only ".example.com", and does not match
         "foo.example.com".

            RFC 2818 [7] (HTTP over TLS) allows the dNSName component to
            contain a wildcard; e.g., "DNS:*.example.com".  RFC 5280
            [6], while not disallowing this explicitly, leaves the
            interpretation of wildcards to the individual specification.
            RFC 3261 [2] does not provide any guidelines on the presence
            of wildcards in certificates.  Through the rule above, this
            document prohibits such wildcards in certificates for SIP
            domains.

###

On the topic of wildcard matching, Martin Rex posted as follows on
September 16...

<http://www.ietf.org/mail-archive/web/certid/current/msg00337.html>

###

(e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net)

This is in clear contradiction to the wildcard matching specified
in rfc-2818 Section 3.1.  And without any rationale for this U-Turn,
that seems to be entirely inappropriate for a BCP.

In my implementation of RFC-2818 wildcard matching, I deliberately
ignore DNS names that contain more than one wildcard character,
have a wildcard character in different but the leftmost label
or have a wildcard character and less than 3 DNS labels.
But I certainly do the substring match specified in rfc-2818
and I'm not going to remove the substring match from my
implementation without a convincing rationale...

What exactly is the benefit of allowing a full wildcard match but
prohibiting a partial/substring wildcard match of the leftmost label?

###

Martin Rex also posted as follows in that same thread:

<http://www.ietf.org/mail-archive/web/certid/current/msg00345.html>

###

Partial wildcard match will allow you to use one single server cert
for a server farm behind a load-balancing NAT with hostnames such as
"www1.example.com", "www2.example.com", ... "wwwNN.,example.com"
by using the pattern "www*.example.com" that will neither match
"kdc.example.com", "ldap.example.com", nor "imap.example.com"
To me, that seems significantly more useful than only a full
wildcard match.  The current draft could be read to mean (without a
single word of rationale) that partial wildcard matching is so much more
dangerous than full wildcard matching that MUST NOT be used by anyone
anymore. If this is not removed from the draft, this will result in a
completely inconsistent behaviour within the installed based causing
headaches with no ends to end-users, admins and helpdesks--for those
servers that actively use this sensible alternative to full wildcard
certs as specified in rfc-2818.

###

What is the sense of this list regarding wildcard matching on component
fragments? Martin has made his arguments so I'm especially interested in
feedback from other folks.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: ArkanoiD <[email-masked]>
Date: Thu, 7 Oct 2010 16:57:54 +0400

Are there any such certificates "in the wild"? Do current clients support it?
If there aren't any and it is not supported anyways, let's keep status quo and do not make things more complicated than needed. For www1, www2 etc one may use extra name component and that's all.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Oct 2010 14:44:18 -0600

On 10/7/10 6:57 AM, ArkanoiD wrote:
> Are there any such certificates "in the wild"? Do current clients
> support it? If there aren't any and it is not supported anyways,
> let's keep status quo and do not make things more complicated than
> needed. For www1, www2 etc one may use extra name component and
> that's all.

What do you mean by "the status quo" -- the text in version -09 of the
server-id-check I-D (no wildcard in component fragments, like foo*) or
the text in RFC 2818 and several other specs (*oo and f*o and foo* are
fine)?

As far as I can see, allowing wildcards in component fragments makes
things more complicated than needed because a CA needs to have more
complex rules for issuance and a TLS library or application client needs
to have a more complex parsing algorithm (checking for things like
*oo.example.com and foo*.example.com and f*o.example.com instead of just
*.example.com -- it's also not clear to me from RFC 2818 if multiple
instances of the wildcard character are allowed, such that
f*b*r.example.com would be acceptable). Allowing '*' only as the
complete left-most label seems easier to me (and I've received feedback
to that effect off-list, as well).

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: ArkanoiD <[email-masked]>
Date: Fri, 8 Oct 2010 01:12:08 +0400

> the text in RFC 2818 and several other specs (*oo and f*o and foo* are

I mean current implementations and already issued certificates.

> to that effect off-list, as well).

It was my primary concern too, i definitely prefer simple and straightforward
parsers that are less likely to behave any unexpected way :-) Once we agree to implement complex parsing, someone almost certainly will just use his favourite regexp library just because it saves time (causing total havoc) ;-)

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Oct 2010 15:26:23 -0600

On 10/7/10 3:12 PM, ArkanoiD wrote:
>>> Are there any such certificates "in the wild"? Do current
>>> clients support it? If there aren't any and it is not supported
>>> anyways, let's keep status quo and do not make things more
>>> complicated than needed. For www1, www2 etc one may use extra
>>> name component and that's all.
>> 
>> What do you mean by "the status quo" -- the text in version -09 of
>> the server-id-check I-D (no wildcard in component fragments, like
>> foo*) or the text in RFC 2818 and several other specs (*oo and f*o
>> and foo* are fine)?
> 
>> As far as I can see, allowing wildcards in component fragments
>> makes things more complicated than needed because a CA needs to
>> have more complex rules for issuance and a TLS library or
>> application client needs to have a more complex parsing algorithm
>> (checking for things like *oo.example.com and foo*.example.com and
>> f*o.example.com instead of just *.example.com -- it's also not
>> clear to me from RFC 2818 if multiple instances of the wildcard
>> character are allowed, such that f*b*r.example.com would be
>> acceptable). Allowing '*' only as the complete left-most label
>> seems easier to me (and I've received feedback to that effect
>> off-list, as well).
> 
> It was my primary concern too, i definitely prefer simple and
> straightforward parsers that are less likely to behave any unexpected
> way :-) Once we agree to implement complex parsing, someone almost
> certainly will just use his favourite regexp library just because it
> saves time (causing total havoc) ;-)

Exactly.

The intended status of this document is BCP = Best Current Practice.
That "B" is in there for a reason. The question is: does allowing *oo
and f*o and foo* (and maybe even f*b*r) as wildcard fragments truly
represent a "best" current practice, or only "current" practice? It
doesn't strike me as a most excellent, effective, desirable, suitable,
appropriate, or useful practice, although I freely grant that it is in
common and general use at the present time.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Oct 2010 02:45:40 +0200 (MEST)

> > saves time (causing total havoc) ;-)

Full agreement.  

It is fine with me to cut sharp down to that functionality that
rfc-2818 described and illustrated 10 years ago. 

But I believe it is not appropriate to turn an rfc-2818 effective SHOULD
into a MUST NOT within a BCP unless there is a REALLY REALLY REALLY
good rationale for it.

I would be OK with deprecating it (SHOULD NOT).

Personally, I do not see any problems implementing exactly the
examples given in rfc-2818, but not more (i.e. single-wildcard
substring matching on the leftmost label only).

btw. "f*.com" is an rfc-2818 example that _my_ implementation of rfc-2818
matching unconditionally ignores when found in CN-ID or DNS-ID of a
server cert--I require at least 3 labels when a wildcard is used.
Should server-id-check promote "*.com" matching? (I think it should not).

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 07 Oct 2010 21:12:18 -0400

> Should server-id-check promote "*.com" matching? (I think it should not).

The document does not "promote" the interpretation of "*.com" as a
wildcard, it just declines to make a special case to forbid it.  In any
case, I don't see anything wrong with allowing such matching at the
server-id-check level.  CAs are responsible for not giving an entity a
certificate that matches names the entity does not own.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 07 Oct 2010 21:17:10 -0400

> common and general use at the present time.

Is it?  I have never seen a certificate with a wildcard that is not a
whole label on a public web site.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Oct 2010 03:41:47 +0200 (MEST)

Matt McCutchen wrote:
> I have never seen a certificate with a wildcard that is not a

The idea behind writing documents such as rfc-2818 is, that implementers
don't have to do public opinion polls an apply heuristics, but instead
follow the implementation guidelines in the document.

It is pretty obvious that rfc-2818 meant to standardize substring wildcard
matching with a single wildcard character in the leftmost dns label.

What is _not_ clear, is whether rfc-2818 meant to also allow more
than one wildcard character in a CN-ID or DNS-ID, wildcards in
more than one DNS label or wildcards in other than the leftmost label.

I believe that shipping a TLS client that matches a server cert
with CN-ID or DNS-ID equal to "*.*.com" is neither reasonable nor
responsible, and it I don't care whether a negilgent CA issued
such a certificate on purpose or whether an attacker managed
to get such a cert issued--there were two bugs published that
made this possible: OID integer wraparound and embedded NUL chars
in the Subject DName, and a significant part of the installed
base does not check server certs for revocation (MSIE on XP/2003).

(The folks on domains such as "*.co.uk" or "*.co.tw" are in a
 slightly more difficult position).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Oct 2010 04:00:08 +0200 (MEST)

> whole label on a public web site.

Btw. the use of TLS is not limited to the public internet.

I don't think that know which _public_ website uses this is meaningless.
The matching is implemented on the client anyway, not on the server.

A much more interesting question would be, what exact kind of wildcard
matching do popular TLS clients actually implement?
   - Microsoft SChannel on XP/2003, Vista/Win7 
   - Firefox 3.x
   - Google Chrome
   - Apple Safari (non-Windows)
   - Opera

We started shipping SSL with our app in 2000/2001.  Back then,
I noticed that MSIE 5.0x implemented (full-label) wildcard matching
(i.e. WinNT 4 and Win9x/ME), but SChannel in Windows 2000 and therefore
MSIE 5.0x on Windows 2000 did _NOT_ implement wildcard matching.
For internal testing, I've been using server certs with wildcard CN-IDs
since 2000, but not being aware of the wildcards substring matching
described in rfc2818 back then, I never tried that myself.

I did issue server certs for wildcard substring matching when I
implemented rfc-2818, though -- and I consider it likely that other
implementors did this as well.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Oct 2010 12:43:29 -0600

> Btw. the use of TLS is not limited to the public internet.

I don't think anyone said it is. However, it's difficult for researchers
to do much testing of sites that are closed off from the public
internet, so that's the real-world data that folks tend to mention.

Speaking of which, someone contacted Jeff and me off-list about some
research results showing that of a very large number of certificates
presented by TLS-protected websites, less than 0.01% contain wildcards
in component fragments. Given that minuscule level of deployment, I
don't see good reasons to spend more cycles on the topic.

> The matching is implemented on the client anyway, not on the server.

Yes it is, but requiring significantly more complex matching to handle
less than 0.01% of the issued certificates seems like a bad idea, i.e.,
not a *best* current practice.

> matching do popular TLS clients actually implement?

Why is that a much more interesting question?

> implementors did this as well.

That's nice, but not directly relevant to the current discussion because
the I-D that Jeff and I have worked on does not override, supersede, or
obsolete RFC 2818 or any other prior art about matching rules for
application server identity. Instead, we are attempting to abstract from
that prior art to formulate forward-looking rules that capture the best
aspects of current practice in a form that future application protocols
can reference. If someday folks in the HTTP community wish to update or
obsolete RFC 2818 by referencing this I-D, they will be free to do so --
but that is not the purpose of the work that Jeff and I have done.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Mon, 11 Oct 2010 22:31:26 +0200 (MEST)

Peter Saint-Andre wrote:
> application server identity.

I strongly disagree. the -09 wording:

   The client MUST fail to match a presented identifier
   in which the wildcard character is contained within a label fragment
   (e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net)

attempts to invalidate rfc-2818 through the use of "MUST NOT".

http://www.ietf.org/mail-archive/web/certid/current/msg00458.html

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 11 Oct 2010 15:16:32 -0600

> attempts to invalidate rfc-2818 through the use of "MUST NOT".

The next version (-10) will make it abundantly clear that this I-D does
not (and does not intend to) override, supersede, update, or obsolete
the rules for verifying server identity provided in specifications for
existing application protocols. On this point, Jeff and I have added an
applicability statement to our working copy, which we hope to release in
the next day or two once we've checked it against all the issues that
were raised during IETF Last Call.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Orton <[email-masked]>
Date: Tue, 12 Oct 2010 11:00:45 +0100

> don't see good reasons to spend more cycles on the topic.

The relative number of certs is less relevant than how widely those 
certs are used, surely.  I checked the "top 1m sites" database from:

http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/

- 382860 total sites (hostnames) returned a cert
- 94438 of total sites used a wildcard cert (24%)
- 5% of total sites use the wildcard cert with CN=*.blogger.com
   ... other blogging/mass-hosting sites similarly high usage

Only a handful (5) use the "f*.example.com" form; all those were certs 
issued by the GoDaddy and starfieldtech.com CAs.

I support Martin's arguments that the "f*.example.com" form specified in 
RFC 2818 should be supported.

Regards, Joe

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 12 Oct 2010 09:03:07 -0400

> were raised during IETF Last Call.

This seems possibly disingenuous to me.  The tls-server-id-check
document may not itself update RFC 2818, but do you really intend that
RFC 2818 never be updated in the future to use the tls-server-id-check
rules?  In view of the likelihood of such an update, it seems unhelpful
to claim now that compatibility with RFC 2818 isn't our problem.

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Oct 2010 07:05:14 -0600

> to claim now that compatibility with RFC 2818 isn't our problem.

Shall I quote the text in our working copy?

###

1.3.  Applicability and Audience

   This document does not supersede the rules for certificate issuance
   or validation provided in [PKIX], which governs any certificate-
   related topic on which this document is silent (e.g., certificate
   syntax, certificate extensions such as name constraints and extended
   key usage, and handling of certification paths).  Specifically, in
   order to ensure proper authentication, application clients need to
   verify the entire certification path, because this document addresses
   only name forms in the leaf server certificate, not any name forms in
   the chain of certificates used to validate the server certificate.

   This document also does not supersede the rules for verifying service
   identity provided in specifications for existing application
   protocols, such as those mentioned under Appendix A.  However, it is
   the intent of the authors that the best current practices described
   here can be referenced by future specifications, including updates to
   specifications for the aforementioned existing application protocols
   as collected under Appendix A, if the relevant technology communities
   agree to do so.  It is also expected that this document will be
   updated or obsoleted in the future as best practices for issuance and
   verification of PKIX certificates continue to evolve through more
   widespread implementation and deployment of TLS-protected application
   services over the Internet.

   The primary audience for this document consists of application
   protocol designers, who might reference this document instead of
   defining their own rules for the representation and verification of
   application service identity.  Secondarily, the audience consists of
   certification authorities, client developers, service providers, and
   other members of technology communities that might re-use or
   "profile" the recommendations in this document when defining
   certificate issuance policies, writing software algorithms for
   identity matching, generating certificate signing requests, etc.

###

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Oct 2010 13:56:44 -0600

> issued by the GoDaddy and starfieldtech.com CAs.

You claim that the number of certs is less relevant than how widely
those certs are used. So, how widely used are the 5 (!) out of 382860
certificates that contain wildcard component fragments? The fact that
those certificates were issued by GoDaddy and Starfield Technologies
means nothing.

> RFC 2818 should be supported.

What do you mean by "should be supported"? I see several claims that one
could make:

1. Existing software whose matching algorithms support wildcard
component fragments should stay as-is.

1a. Any new software written to perform identity matching should also
contain matching algorithms that support wildcard component fragment.

2. Existing application protocols (see Appendix A of this I-D) that
allow wildcard component fragments should not be changed.

2a. Any new application protocols developed by the IETF (or other SDOs)
should also allow wildcard component fragments.

3. Wildcard component fragments are a best current practice for both
certificate issuance and certificate validation, and therefore any BCP
produced by the IETF at this time should recommend that all application
protocols should support wildcard component fragments (thus putting at
least RFC 5922 out of compliance, since that spec doesn't even allow
complete wildcard components).

I support #1 (with the proviso that it's an implementation decision for
the relevant software developers whether they want to simplify their
matching algorithms, based on a cost-benefit analysis of code complexity
vs. a degraded user experience for less than 0.01% of issued
certificates). I think #1a depends on which application protocol the
software is designed to use (e.g., HTTP vs. SIP) -- conform to the spec
you're implementing. I think #2 is just fine (with the proviso that such
application protocols might decide to update their specs in the future
based on experience and discussion within the relevant technology
community). I disagree with #2a because I think that wildcard component
fragments are not a *best* current practice, and I disagree with #3 for
the same reason.

What are the positions of those who are arguing for supporting wildcard
component fragments, and why?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Oct 2010 01:34:21 +0200 (MEST)

> those certificates were issued by GoDaddy and Starfield Technologies

Very few commercial(!!) CAs (currently) issue wildcard certs at all.
And of those commercial CAs that offer wildcard certs, only a fraction
offers substring wildcard certs.

Just because commercial CAs don't do it, doesn't mean that a
DNS admin running his own CA would not want to do it either.

> What do you mean by "should be supported"?

That this paragraph:

should be changed.

Out of curiosity I just check the behaviour of the following browsers:

   MSIE7 on XPsp3
   MSIE7 on W2K3sp2
   MSIE8 on Win7
   Firefox 3.0.17 (XPsp2)
   Firefox 3.5.9  (W2K3sp2)

and they all appear show the exact *SAME* behaviour with respect to the
following characteristics:

 wildcard in leftmost DNS label only:
   - YES: wildcard matching for "*.bar.example.com"
   - NO:  wildcard matching for "foo.*.example.com"
    
 wildcard substring match:
   - YES: wildcard matching for "fo*.bar.example.com"
   - NO:  other patterns "*oo.bar.example.com", "f*o.bar.example.com"

For comparison, I also tried Opera 8.54 (the only one I have lying around),
and it supports wildcards in multiple DNS labels as well as in arbitrary
positions of the label, such as "f*o.ba*.example.com", "*oo.bar.example.com"

While Opera 8.54 is within the scope of rfc-2818, I'm personally more
comfortable of the behaviour exhibited by MSIE/SChannel and Firefox 3.x.

> certificates).

I would not have the slighest problem if server-id-check said that

   Clients MAY ignore hostname identifiers in certificates that
   contain a wildcard character in other than the leftmost DNS label,
   and clients MAY ignore hostname identifiers where the leftmost
   DNS label contains characters in addition to the wildcard character,
   which would require partial string matches.  Several web browsers
   have chosen a conservative approach to rfc-2818 wildcard substring
   match and support a partial wildcard only when the wildcard character
   appears at the end of the leftmost label, e.g. ""foo*.bar.example.com".

> component fragments, and why?

I consider the conservative approach of MSIE/SChannel and Firefox to
allow a tail wildcard on the leftmost DNS label, in addition to a
full wildcard, sensitive risk management combined with minimal complexity.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 12 Oct 2010 19:51:54 -0400

> full wildcard, sensitive risk management combined with minimal complexity.

As I said before, I don't think this "risk management" argument is real.
CAs are responsible for not giving an entity a certificate that matches
names the entity does not own.  Why should we believe they are any more
likely to mess up via wildcards than, e.g., by setting the basic
constraint "CA: true"?

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Oct 2010 18:34:54 -0600

> likely to mess up via wildcards than, e.g., by setting the basic

Matt, what conclusion do you draw from your statement? IMHO it might
lead to the conclusion that it doesn't matter what we put in the
left-most label -- or even the conclusion that we don't need to restrict
the location of the wildcard (e.g., foo.*.example.com or even
*.*.example.com is fine) -- as long as the CA issues a certificate that
matches a name the entity owns.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 12 Oct 2010 21:10:09 -0400

> matches a name the entity owns.

That's right from the perspective of "risk management".  All I wanted to
do was put that argument aside.  There are other arguments to consider,
e.g., "simpler" algorithms are easier to implement and more likely to be
implemented correctly, and compatibility with specifications that might
want to update to reference tls-server-id-check.

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Oct 2010 19:33:40 -0600

On 10/12/10 7:10 PM, Matt McCutchen wrote:
> do was put that argument aside. 

I see, and I agree.

> There are other arguments to consider,
> implemented correctly, 

That seems to be the operative consideration. Martin claimed that it is
a "conservative approach ... to allow a tail wildcard on the leftmost
DNS label" but RFC 2818 doesn't say anything about a "tail wildcard"
(e.g., foo*):

Yes, the example here shows a tail wildcard, but as far as I can see the
rule of allowing the wildcard character in a component fragment does not
restrict '*' to the tail -- it could just as well be a "front wildcard"
(e.g., *oo) or a "middle wildcard" (e.g., f*o). All of these increase
the complexity of the matching algorithm, for very little if any gain
that I can see.

> and compatibility with specifications that might

Well, that's not a legitimate argument because it begs the question. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Wed, 13 Oct 2010 06:50:48 +0200 (MEST)

> As I said before, I don't think this "risk management" argument is real.

The rist management argument is VERY real.

Recall the numbers:
:
: http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/
: 
: - 382860 total sites (hostnames) returned a cert
: - 94438 of total sites used a wildcard cert (24%)
: - 5% of total sites use the wildcard cert with CN=*.blogger.com
:    ... other blogging/mass-hosting sites similarly high usage
: 
: Only a handful (5) use the "f*.example.com" form; all those were certs 
: issued by the GoDaddy and starfieldtech.com CAs.

Full wildcard certs are dangerous, because they will match any host
in a domain (which makes them a much more interesting target for
credential-stealing).

I assume that a non-negligible of those servers that are currently using
full wildcards could be using tail-match wildcards instead -- something
which could reduce the risk for some of the other servers in a domain.

The reason why tail-wildcards are rarely used is probably not that server
operators do not like them or browsers would not support them,
but that there are currently not enough CAs offering them.

Now instead of killing something which would help the risk managment
of server operaters, server-id-check should describe tail-wildcards
on the leftmost DNS label as an alternative to full wildcards as a MAY.

-Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Oct 2010 11:45:27 -0600

> in a domain (which makes them a much more interesting target for

How so? If I can steal credentials such that I have access to verifying
addresses for example.com, then I can convince a CA to issue whatever
certificates I want. If the "example.com" property is valuable then the
differences between example.com, *.example.com, and foo* or *oo or
f*o.example.com are negligible. I really doubt that any thief is going
to be significantly more attracted to stealing credentials because he
knows that he can go to a CA and get *.example.com instead of "merely"
foo*.example.com and www*.example.com and so on. And if that were the
case then it would simply be a matter of CA-shopping (which the bad guys
already do).

> which could reduce the risk for some of the other servers in a domain.

If folks were really interested in risk mitigation then presumably
they'd be using things like SRV-IDs (limits the damage to a particular
service type), EKU, name constraints, locking down canonical email
addresses, etc., or at least not using wildcard certs in any way and
requesting only certificates for named application services (e.g.,
mail.example.com instead of m*.example.com or *.example.com). Character
matching on www* seems a lot less valuable than many other measures an
organization could take. Furthermore, there is no way for an application
service provider to signal to application clients that they should not
accept wildcard certificates, so the primary benefits here accrue to the
provider -- in which case they can simply define their own
organizational policies and procedures for certificate requests, and
perhaps communicate those to their favorite CAs.

Finally, figuring out which measures are most effective at mitigating
risk would require a breadth of research (analysis of various attacks
etc.) that is beyond the scope of this I-D.

> operators do not like them 

We have no way of knowing whether application service providers like
them or not, absent surveys of some kind.

> or browsers would not support them,

The logical conclusion from your line of reasoning is to forbid all
wildcard certificates, whether full-label, tail, head, torso, or
anything else, but you don't seem to want to go that far. Why not? And
why are tail wildcards so much safer than head or torso wildcards?

Note that at least two technology communities have forbidden wildcard
certificates:

1. RFC 5992 forbids wildcard certificates in the SIP community.

2. The CA/Browser Forum doesn't allow issuance of wildcard certificates
under its "Extended Valuation Certificates" profile.

So there is some precedent for forbidding wildcard certificates. Is that
a best current practice? Should this I-D state that wildcard
certificates (of whatever variety) are NOT RECOMMENDED?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/