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 2011Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app
Errata ID: 3090
Status: Held for Document Update
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 ]
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
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