Subject: [TLS] RFC 6125

From: Scott Rea <[email-masked]>
Date: Tue, 31 Jul 2012 19:44:54 -0600

We'd like to address a few concerns with RFC 6125.  Because the relevant
discussion list is not active, we contacted the authors and TLS Chair who
instructed us to post our concerns to this list.

Our primary concern with RFC 6125 is that Wildcard certificate use is
wide-spread and has proved to be a cost-effective alternative to
multi-domain certificates.  Asking for the deprecation of wildcard
certificates undermines a lot of existing infrastructure and current
establishments.   We feel that RFC's current recommendations fail to
adequately balance the risks and convenience of an existing practice, is
based only on theoretical problems, and does not accurately reflect current
industry practices or beliefs.

We suggest the following changes to RFC 6125:

-------

Section 1.5 - Overview of Recommendations

[........Edit..................]
Move away from the issuance of so-called wildcard certificates (e.g., a
certificate containing an identifier for "*.example.com").

[........Replace with....]
Follow the established rule set for interpreting wildcard certificates
(e.g., a certificate containing an identifier for "*.example.com").

---------

Section 4.1 - Rules

[........Edit..................]
7. Unless a specification that reuses this one allows continued support for
the wildcard character '*', the DNS domain name portion of a presented
identifier SHOULD NOT contain the wildcard character, whether as the
complete left-most label within the identifier (following the description of
labels and domain names in [DNS-CONCEPTS], e.g., "*.example.com") or as a
fragment thereof (e.g., *oo.example.com, f*o.example.com, or
fo*.example.com).  A more detailed discussion of so-called "wildcard
certificates" is provided under Section 7.2.

[........Replace with....]
7. Unless a specification that reuses this one allows continued support for
the wildcard character '*', the DNS domain name portion of a presented
identifier SHOULD NOT contain the wildcard character, unless the wildcard
character is the complete left-most label within the identifier (following
the description of labels and domain names in [DNS-CONCEPTS], e.g.,
"*.example.com") and ONLY a single wildcard character is present within an
identifier. Wildcard characters should not be a fragment of a DNS domain
name or presented identifier (e.g., *oo.example.com, f*o.example.com, or
fo*.example.com).  A more detailed discussion of so-called "wildcard
certificates" is provided under Section 7.2.

------------

Section 7.2 - Wildcard Certificates

[........Edit..................]
This document states that the wildcard character '*' SHOULD NOT be included
in presented identifiers but MAY be checked by application clients (mainly
for the sake of backward compatibility with deployed infrastructure).  As a
result, the rules provided in this document are more restrictive than the
rules for many existing application technologies (such as those excerpted
under Appendix B).  Several security considerations justify tightening the
rules:

o  Wildcard certificates automatically vouch for any and all host
     names within their domain.  This can be convenient for
     administrators but also poses the risk of vouching for rogue or
     buggy hosts.  See for example [Defeating-SSL] (beginning at slide
     91) and [HTTPSbytes] (slides 38-40).

o  Specifications for existing application technologies are not clear
     or consistent about the allowable location of the wildcard
     character, such as whether it can be:

     *  only the complete left-most label (e.g., *.example.com)

     *  some fragment of the left-most label (e.g., fo*.example.com,
        f*o.example.com, or *oo.example.com)

     *  all or part of a label other than the left-most label (e.g.,
        www.*.example.com  orwww.foo*.example.com)

     *  all or part of a label that identifies a so-called "public
        suffix" (e.g., *.co.uk or *.com)

     *  included more than once in a given label (e.g.,
        f*b*r.example.com

     *  included as all or part of more than one label (e.g.,
        *.*.example.com)

     These ambiguities might introduce exploitable differences in
     identity checking behavior among client implementations and
     necessitate overly complex and inefficient identity checking
     algorithms.

o  There is no specification that defines how the wildcard character
     may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
     internationalized domain name [IDNA-PROTO]; as a result,
     implementations are strongly discouraged from including or
     attempting to check for the wildcard character embedded within the
     A-labels or U-labels of an internationalized domain name (e.g.,
     "xn--kcry6tjko*.example.org").  Note, however, that a presented
     domain name identifier MAY contain the wildcard character as long
     as that character occupies the entire left-most label position,
     where all of the remaining labels are valid NR-LDH labels,
     A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").

Notwithstanding the foregoing security considerations, specifications that
reuse this one can legitimately encourage continued support for the wildcard
character if they have good reasons to do so, such as backward compatibility
with deployed infrastructure (see, for example, [EV-CERTS]).

[........Replace with....]
This document states that the wildcard character '*' SHOULD NOT be included
in presented identifiers, except as provided for herein,  but MAY be checked
by application clients (mainly for the sake of backward compatibility with
deployed infrastructure).  As a result, the rules provided in this document
are more restrictive than the rules for many existing application
technologies (such as those excerpted under Appendix B).  Several security
considerations justify tightening the rules:

     o  Wildcard certificates are commonly used to secure host names within a
specified domain.

     o  Some specifications for existing application technologies are not
clear or consistent about the allowable location of the wildcard character,
such as whether it can be:

        *  only the complete left-most label (e.g., *.example.com)

        *  some fragment of the left-most label (e.g., fo*.example.com,
f*o.example.com, or *oo.example.com)

        *  all or part of a label other than the left-most label (e.g.,
www.*.example.com  orwww.foo*.example.com)

        *  all or part of a label that identifies a so-called "public suffix"
(e.g., *.co.uk or *.com)

        *  included more than once in a given label (e.g.,f*b*r.example.com

        *  included as all or part of more than one label (e.g.,
*.*.example.com)

     o  Although there are no specifications that defines how the wildcard
character may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
internationalized domain name [IDNA-PROTO], the commonly accepted usage is
to include the wildcard character only as the leftmost character of the
domain and to use only a single wildcard character per identifier.
Therefore, a presented domain name identifier MAY contain the wildcard
character as long as that character occupies the entire left-most label
position, where all of the remaining labels are valid NR-LDH labels,
A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").

Notwithstanding the foregoing security considerations, specifications that
reuse this one can legitimately encourage continued support for uses of the
wildcard character other than as described herein if they have good reasons
to do so, such as backward compatibility with deployed infrastructure (see,
for example, [EV-CERTS]).

--------------

Appendix B-9 - SIP (2010)

[........Edit..................]

In 2010, [SIP-CERTS] specified the following text regarding application
service identity verification in SIP:

######

7.2.  Comparing SIP Identities

When an implementation (either client or server) compares two values as SIP
domain identities:

     Implementations MUST compare only the DNS name component of each
     SIP domain identifier; an implementation MUST NOT use any scheme
     or parameters in the comparison.

     Implementations MUST compare the values as DNS names, which means
     that the comparison is case insensitive as specified by
     [DNS-CASE].  Implementations MUST handle Internationalized Domain
     Names (IDNs) in accordance with Section 7.2 of [PKIX].

     Implementations MUST match the values in their entirety:

        Implementations MUST NOT match suffixes.  For example,
        "foo.example.com" does not match "example.com".

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

           [HTTP-TLS] allows the dNSName component to contain a
           wildcard; e.g., "DNS:*.example.com".  [PKIX], while not
           disallowing this explicitly, leaves the interpretation of
           wildcards to the individual specification.  [SIP] 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.

######

[........Replace with....]

In 2010, [SIP-CERTS] specified the following text regarding application
service identity verification in SIP:

######

7.2.  Comparing SIP Identities

When an implementation (either client or server) compares two values as SIP
domain identities:

Implementations MUST compare only the DNS name component of each SIP domain
identifier; an implementation MUST NOT use any scheme or parameters in the
comparison.

Implementations MUST compare the values as DNS names, which means that the
comparison is case insensitive as specified by [DNS-CASE].
Implementations MUST handle Internationalized Domain Names (IDNs) in
accordance with Section 7.2 of [PKIX].

Implementations MUST match the values in their entirety:

Implementations MUST NOT match suffixes.  For example, "foo.example.com"
does not match "example.com".

Implementations MAY match wildcard character prefixes if the wildcard
character is the leftmost name component in the certificate.  For example,
*.example.com would match a.example.com, foo.example.com, etc., but would
not match example.com.

   [HTTP-TLS] allows the dNSName component to contain a wildcard; e.g.,
"DNS:*.example.com".  [PKIX], while not disallowing this explicitly, leaves
the interpretation of wildcards to the individual specification.
[SIP] does not provide any guidelines on the presence of wildcards in
certificates.  Through the rule above, this document recommends using its
guidelines on the presence of wildcards for SIP domains.

.......

Regards,

-- 
Scott Rea, DigiCert.