RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Held for Document Update (1)

RFC 6125, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", March 2011

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3090

Status: Held for Document Update
Type: Technical

Reported By: Jeff Hodges
Date Reported: 2012-01-13
Held for Document Update by: Peter Saint-Andre
Date Held: 2012-02-27

Section 6.4.3 says:

6.4.3. Checking of Wildcard Certificates

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   portion contains the wildcard character '*' as part or all of a label
   (following the description of labels and domain names in
   [DNS-CONCEPTS]).

   For information regarding the security characteristics of wildcard
   certificates, see Section 7.2.

   If a client matches the reference identifier against a presented
   identifier whose DNS domain name portion contains the wildcard
   character '*', the following rules apply:

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].

It should say:

[ no firm test suggestions just as yet, please see below ]

Notes:

RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier

section 6.4.3 does not specify how many labels must be in a wildcarded presented identifier. I.e., it leaves open the possibility that the following presented identifiers could be matched against actual domain names..

*
*.
*.com i.e. *.<fill in TLD here> e.g.: *.uk or *.co.uk
*U i.e. *<fill in portion of TLD here> e.g.: will match AU, EDU, CU

etc. etc.


If actual TLS/SSL implementations (e.g. web browsers) were to make valid matches as shown above, then someone could ostensibly obtain a cert (c.f. diginotar) for one of them and then go and MITM large swaths of domain name space.

Note that the discussion of wildcards in Section 7.2 of security considerations identifies the public suffix issue in passing, but only as one of a set of issues why the spec discourages use of wildcard certs.

Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".

Likely the approach will need to consist of a "SHOULD" declaration and some hand-waving about how "matching wildcards on presented identifiers with less than N (?) labels to the right of the wildcard has various increasing risks as N approaches zero, and that implementors should perhaps consider leveraging some of the available public suffix identification mechanisms, but that those are out of scope and have their own operational and security considerations."

PSA: This issue needs to be addressed, but doing so by means of an erratum is not the best way to go about having this conversation. Marking as "Hold For Document Update" to make sure we don't lose track of the issue. -- Peter Saint-Andre

Report New Errata