Re: [certid] Fwd: secdir review of

[Martin Rex <[e-mail]>]

Personally, I do _not_ see a problem with wildcard certs.
And neither with partial/substring wildcard matching defined in rfc-2818.

They're perfectly sensible, but should only be employed with caution
after understanding and carefully weighing the full implications of
the intended usage scenario.

I do see a huge problem with the constant bending of the details
of server name matching.  The proverb says: if you bend it too often
it'll break.

What we currently have is a mess, and applying any further changes,
such as dropping partial wildcard matches while retaining full wildcard
matches and app-specific ignore-wildcard is going to make the mess
bigger and is IMHO a bad idea.

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.


One should be looking at the bigger picture, what does changing
the spec mean for the (consistency) accross the installed base?

Start with the history of how server-name matching developed:

1.  matching hostnames to CN-ID

2.  allowing (full) wildcards in CN-ID

3.  matching hostnames to DNS-ID in addition to CN-ID

4. (rfc-2818) recommending DNS-ID, specifying IP-ID, deprecating CN-ID,
   recommending only "most specific" CN-ID matching,
   asking to ignore CN-ID when DNS-ID or IP-ID is present
   specifying partial wildcard match, 

5. TLS server name indication (SNI) explicit non-support of IP-ID
   within SNI, but leaving IP-ID matching based on rfc-2818 perfectly valid.
   unreasonably specifying hostname in SNI with UTF8-encoding,
   instead of IA5-String punicode

6. (draft-saintandre-tls-server-id-check)
   prohibiting partial wildcard match??
   suggesting app-specific wildcard-matching enabling.


Now look at how the work of actually matching has been shared between
the calling application above TLS and the TLS client implementation.

Many TLS implementations offer a convenience/utility function to
application callers of the TLS client to perform the server endpoint
identification for them, sometimes as a default "added value".

There is an API call in the TLS client implementation where the
application caller can pass the target hostname of the server
as an argument, and the TLS client implementation does all the
rest.  Depending on the API architecture (service-API or callback)
this may be a call prior to the handshake or the call the starts
the handshake (like the target_name parameter of InitializeSecurityContext
for the Microsoft SChannel SSP).  

But there are also client apps that have been doing the server endpoint
identification all by themselves, exactly as it is has always been and
still is suggested by the TLS spec, last sentence of section 1 of
every TLS spec (2246,4346,5246):

                                the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

Where the TLS client implementation offered to perform the matching,
and the calling client application on top of TLS used that service,
passing down the target hostname, the migration from CN-ID matching
to the scheme described by rfc-2818 is easy, straigtforward and
transparent to the application.   When the client TLS implementation
wants the target hostname prior the TLS handshake or at the beginning
of the handshake (not as a callback when the servers certificate
is received), the TLS client application can conveniently provide
implementing client-side TLS session caching (Note however, that
for adequate client-side cache management the client application
should really include the Port/service behind the hostname from
the URL instead of blindly assuming that server-side TLS session
caches are unconditionally shared across all service endpoints of a host.)


>From what I can see, the most recent fine-tuning proposals are
likely difficult to add into existing deployments where the
client application conveniently relies on the convenience function
supplied by the TLS client implementation in matching the server
endpoint identity, client apps may face a lot of work (which
significantly reduces the chances that its adopted by the
installed base).  Keep in mind that often, TLS implementations
and calling client applications are independently maintained,

If your app is built on top of Microsoft Schannel and relies on
what that does about server endpoint identification based on the
target_name passed to InitializeSecurityContext() to the Schannel SSP,
then your app may have little choices.  The exact matching is
whatever Microsoft has shipped.

Special requirements, such as
  - "for this server, I want no rfc-2818 partial wildcard matching"
  - "for the other server over there, I need rfc-2818 partial wildard
     matching for in order not to break a productive usage scenario"
  - "and for that server I want no wildcard matching at all, because
    the app-spec says so (keep in mind that the TLS client implementation
    does neither know nor care what app protocol is used inside).
  - "and for the server over there I want no CN-ID fallback when there
     no DNS-IDs in the server cert"
  - "and here's yet another server where I would prefer SRV-ID matching,
    to DNS-ID matching (but I have no clue how to request this...)"


IMHO, any backwards-incompatible changes to server endpoint identification
with regards to rfc-2818 ought to come with a very convincing rationale,
or they are likely to make things worse ... much worse from what we
currently have.

-Martin

Henry B. Hotz wrote:
> 
> On Sep 15, 2010, at 6:08 PM, Martin Rex wrote:
> > 
> >> -- Page 19, sec 4.4.3, last graf:
> >>   A specification that references the rules defined in this document
> >>   can specify that the wildcard character is not allowed in
> >>   certificates used by the relevant application protocol or community
> >>   of interest.
> > 
> > To me this sounds awkward.  It implies that either the CA has a flawed CPS
> > can not appropriately deal with wildcard reference identifiers in certs,
> > or is in general not trustworthy or that the wildcard-scheme too dangerous
> > (=too difficult to handle safely) for server admins.
> 
> <rant>
> I believe wildcards are a misfeature, because a wildcard cert doesn't
> identify the server well enough that it should be trusted.  I believe
> that "Best Practice" is to never use the feature, and for clients to
> raise flags if presented with it.
> 
> Of course "Current" practice is to make maximal use of the feature because:
> 
> 1)  nobody understands how to make the names match in real deployments.
> 
> 2)  the CA's pricing model makes it cheaper to buy a wildcard cert
>     than the full collection of multiple-alias certs you really need.
> </rant>
> 
> Getting back to the point:  I think it's perfectly appropriate for a
> Practice document to restrict when and how much you use a Standard feature.