[certid] open issue: wildcards in component fragments

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

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/