Subject: [TLS] RFC 2818 wildcard rationale

From: Chris Richardson <[email-masked]>
Date: Tue, 1 May 2012 21:45:58 +1000

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.

I was trying to figure out the rationale behind this, but have been
unable to do so.  I was hoping someone could enlighten me.

Suppose that:
(1): *.example.com matched a.b.example.com
(2): *.example.com matched example.com.

What security problems exist with (1) and/or (2) that are solved by
following the rules of 2818?  Anything more than preventing a single *
from matching the entire internet?

 -- Chris

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 01 May 2012 14:06:19 +0200

> from matching the entire internet?

Regarding #1, if * matched multiple labels, it would match  
www.yourbank.com.whatever.example.com, which would be a very bad thing  
since it can mislead users into thinking that they are visiting  
"www.yourbank.com".

Regarding #2, I don't think that would introduce any real badness, except  
having to edit the rulestring, which make already complex logic more  
complex, and more likely to fail an unsecure manner (there is also the  
fact that you can have "f*.example.com", which should not allow #2 to be  
generated, causing more complexity). However, adding a separate rule for  
"example.com" in the SAN field is very simple.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 May 2012 16:04:06 -0600

> since it can mislead users into thinking that they are visiting

True. But * matches only the left-most label, so a.b.example.com doesn't
match *.example.com.

Peter

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

---

From: Chris Richardson <[email-masked]>
Date: Fri, 4 May 2012 14:22:00 +1000

> www.yourbank.com.whatever.example.com, which would be a very bad thing since
> it can mislead users into thinking that they are visiting
> "www.yourbank.com".

Are there any circumstances under which an (individual/organization)
is authorized to have a certificate for *.example.com, but is not
authorized to have a certificate for
www.yourbank.com.whatever.example.com?

> complex, and more likely to fail an unsecure manner (there is also the fact
> that you can have "f*.example.com", which should not allow #2 to be

If both (1) and (2) were allowed, that would eliminate the need for
wildcards which should simplify the logic.

And out of curiousity, are there any real examples of f*.example.com
certificates?  Are there any circumstances under which that is a good
idea?

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 May 2012 19:51:14 +0200 (MEST)

> www.yourbank.com.whatever.example.com?

That is an "interesting question" (not on DANE's radar so far).

Being authorized (as being the domain owner) does not mean that every
commercial/public CA will issue a TLS server certificate for such a name.

AFAIK, at least some of the CAs will refuse to issue TLS server certs
to owners of domains that could be used for typo-squatting high-profile
sites/domains.

The issue that Yngve mentioned is about the common behaviour of
DNS resolvers to have a "default domain" or "searchlist" which they
use to complete a hostname that does not have a trailing dot before
trying to resolve that name via DNS.

> certificates?  Are there any circumstances under which that is a good

There is a huge variety of different behaviour in the installed
base with respect to wildcard matching from rfc2818 Section 3.1
server endpoint identification.

Adding more options at this point would only lead to further divergence
of the behaviour (=less predictable) in the installed base,
so I consider it a bad idea.

Limiting the options to what is easy to understand and explain,
and supported by a significant fraction of the installed base,
seems much more reasonable at this point.

-Martin