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

[Peter Saint-Andre <[e-mail]>]

On 10/12/10 10:50 PM, Martin Rex wrote:
> Matt McCutchen wrote:
>>
>> On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote:
>>> 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.
>>
>> 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).

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

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

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.

> The reason why tail-wildcards are rarely used is probably not that server
> 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,
> 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.

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/